개발자님 제발 HTML을 깨트리지 말아주세요

이 글은 서버사이드 개발자님들께서 웹퍼블리셔로부터 받은 HTML문서를 작업하는데 있어서 최소한으로 알아주셨으면 하는 내용을 정리한 것입니다. 일부분 상세히 적지 않고(버전별 요소와 속성의 사용 유무 등) 최대한 쉽게 작성하는데 목적을 두었기 때문에 실 작업시에는 웹퍼블리셔와의 커뮤니케이션과 좀 더 정확한 스펙 문서를 참고해 주시기를 부탁드리겠습니다.

웹표준화와 관련하여 웹퍼블리셔는 정확한 Doctype 선언으로부터 마크업을 시작한다. 그리고 올바른 마크업(well-formed) 검증(validate)으로 작업을 마치게 된다. 하지만 많은 경우 사이트가 오픈했을 때 validate를 통과가 어렵다. 이는 서버사이드 개발자들이 웹퍼블리셔로부터 받은 (X)HTML 문서를 수정(개발을 입히는 작업)하면서 올바르지 않은 요소와 속성을 사용하기 때문인 경우가 많다.

서버사이드 언어인 ASP나 PHP, JSP 등은 문법오류에 대한 관용이 적기 때문에 즉각적으로 에러를 보여준다. 하지만 (X)HTML은 브라우저에 따라 관용적으로 처리되거나, 용납되는 경우가 많아 올바르지 않은 마크업을 하고도 화면이 정상적으로 보이는 경우가 많다. 하지만 이렇게 완성된 사이트는 결코 웹표준 사이트라고 볼 수 없거니와, 웹접근성 또한 보장받을 수 없게 된다.

XHTML 스펙을 살펴보면 잘못된 요소와 속성의 사용을 알 수 있지만 대부분의 경우 서버사이드 개발자들은 과거에 익혔던 HTML 문법만을 기억하고 있으며(그다마 올바르지 않은 문법) 새로운 XHTML에 대한 차이를 잘 알지 못한다.

다음은 W3C의 HTML / XHTML 스펙 문서 목록이다.

• HTML 4.01 Specification
• XHTML™ 1.0 The Extensible HyperText Markup Language (Second Edition)
• XHTML™ 1.1 - Module-based XHTML - Second Edition
  

다음은 XHTML 기준으로 개발자 역시 함께 알아야 하는 내용들이다.

• HTML 문서의 Doctype이 무엇인지 확인한다.
  
  
  HTML 4.01과 XHTML 1.0 에는 각각 'Strict(가장 엄격)', 'Transitional(전환형)', 'Frameset(프레임셋형)' 세가지 타입이 있다. XHTML 1.1은 'Strict'만을 지원하며, 표기는 XHTML 1.1로만 합니다.
  
  Doctype에 따라 사용 가능한 요소와 속성이 구분되며, CSS에도 영향을 미친다.
  
  
• Doctype 선언 위에 출력되는 요소나 문자열이 없도록 한다.
  
  
  DTD는 HTML 문서의 최상단에 선언되어야 한다. 그렇지 않을 경우 일부 브라우저(IE 등)에서 비표준모드(Quirks mode)로 작동하게 된다. 일부 스타일이 제대로 적용되지 못하는 문제가 종종 발생한다.
  
  
• XHTML일 경우 모든 요소와 속성은 소문자로 작성하며, alt와 title 속성을 제외하고 가능한 모든 속성에는 값을 넣어(대부분 넣지 않아도 에러가 나지는 않으나 alt와 title 속성을 제외하면 특별한 이유 없이 빈 값을 넣는 경우는 드믈다)준다. 또한, 모든 속성값은 반드시 인용부호로 둘러싼다.
  
  
  validate의 에러를 가장 많이 내는 주범이다.
  
• XHTML일 경우 모든 요소는 반드시 닫아주어야 한다. 특히 <head>..</head>사이의 <meta> 요소 작성시 반드시 닫아주자! 또한, 요소의 위치관계를 정확하게 한다.
  
  <p>내용</p> , <br />, <img src="..." />, <meta ... />, <link rel=".." ... />
  
  (x) <a href="..."><span>링크</a></span>
  (o) <a href="..."><span>링크</span></a>
  
  
• XHTML 1.1일 경우 <a>, <map>, <form>, <img> 요소에서 name 속성이 폐지되어 사용할 수 없다.
  
  
  id 속성만을 사용한다. 하지만 <form>내 <input> 등 요소에서는 name 속성을 사용할 수 있다.
  
  
• MIME Type이 'application/xhtml+xml'일 경우 script와 style 요소는 '<!--'과 '-->'를 '<![CDATA['와 ']]>'로 대체한다. 단, 'text/html'일 경우는 과거처럼 주석 방식을 사용한다.
  
  
  CDATA는 script와 style 내 '<', '>', '&'와 같은 문자를 이스케이프 시키지 않고 그대로 사용할 수 있도록 한다. 또한, Doctype에 관계없이 script요소와 style요소를 </head>와 <body>사이에 삽입하는 경우는 없어야 한다. 되도록 script와 style은 외부 문서로 빼는 것이 좋다.
  
  
• XHTML 1.1일 경우 다음의 요소들은 사용할 수 없다.
  
  
  <applet>, <basefont>, <center>, <dir>, <font>, <frame>, <frameset>, <iframe>, <isindex>, <menu>, <noframes>, <s>, <strike>, <u>
  
  특히 , <font>와 <center>, <iframe> 요소는 개발자들이 무분별하게 사용하는 대표 요소인데 Doctype에 따라 사용을 신중히 해야할 필요가 있다. <font>와 <center> 요소는 CSS로 정의할 수 있으며, <iframe>요소는 <object>요소로 대체된다.
  
  
• XHTML 1.1일 경우 다음의 속성들은 사용할 수 없다. (일부 속성은 XHTML 1.0 Strict 에서도 지원되지 않기 때문에 주의 바랍니다.)
  
  
  <*> lnag
  <a> name, target
  <area> traget
  <body> background, bgcolor, text, link, vlink, alink
  <br> clear
  <caption> align
  <div> align
  <form> name, target
  <h1~h6> align
  <hr> align, noshade, size, width
  <img> align, border, hspace, vspace
  <input> align
  <legend>align
  <li> type, value
  <link> target
  <map> name
  <object> align, border, hsapce, vspace
  <ol> compact, start, type
  <p> align
  <pre> width
  <strict> language
  <table> align, bgcolor
  <td> bgcolor, height, nowrap, width
  <th> bgcolor, height, nowrap, width
  <tr> bgcolor
  <ul> compact, type
  
  
• 가급적 요소에 직접 스타일(inline style)을 정의하지 않는다.
  
  
  <div style="...">
  단, <input>과 <img> 요소 등 개발시 변동이 잦은 요소들에 한해서 inline style로 width와 height를 지정하는 것은 괜찮다고 생각한다. 하지만 저속 인터넷 접속 환경에서는 느린 로딩으로 인해 이미지 요소들이 레이아웃을 잡지 못해 들쑥날쑥하게 전체레이아웃을 깨뜨리는 현상이 발생하기도 하므로 이에 대한 고려가 선행되어야 할 것이다.
  
  
  
• 요소와 속성내 모든 문자열을 PCDATA(분석 처리된 문자데이터)로 작성한다.
  
  
  <p>LOVE & GHOST</p> ☞ <p>LOVE &amp;amp; GHOST</p>
  <a href="../../list.php?id=bomnun&val=2">링크</a> ☞ <a href="../../list.php?id=bomnun&amp;val=2">링크</a>
  
  * <style>과 <script>요소에서는 <![CDATA[ ... ]]>를 사용해서 문자열을 파싱하지 않고 그대로 사용할 수 있다.
  
  
  
• XHTML일 경우 속성은 약술할 수 없다.
  
  
  <input type="radio" checked /> ☞ <input type="radio" checked="checked" />
  
  
  
• Encoding Charset이 무엇인지 확인한다.
  
  
  HTML 문서는 utf-8인데, 파일 인코딩은 euc-kr인 경우가 종종 있고, 이 경우 한글이 깨져 보이는 가장 큰 이유가 된다. 또한, CSS나 JS 역시 인코딩이 다를 경우 제대로 작동되지 않기도 한다.
  

세세히 따지면 좀 더 있겠지만 대부분 위의 경우에 해당될 것 같다. 그리고 상위 4개 붉은색으로 표시한 것들이 validate를 통과하지 못하는 대부분의 이유가 된다. 서버사이드 개발자들이 위의 내용을 숙지만 하고 있다면(최소한 DTD의 차이만이라도 알고 있다면) 문법 오류를 최소한으로 줄일 수 있을것 같다.

이 글은 솔직히 서버사이드 개발자들을 '낚기' 위한 글입니다. 위의 내용은 이미 수차례 비슷한 주제의 블로그나 사이트를 통해서 널리 알려져 있는 내용입니다. 결국 복사된 내용의 재탕(웹표준교과서의 내용을 정리했음)이라는 것이지만 그럼에도 불구하고 서버사이드 개발자분들이 한번만이라도 관심 있게 읽어주기를 바라는 마음에 포스팅을 하게 되었습니다.

개발자들이여 당신의 상사가 바보같다고 느껴진다면 이 책을 선물하라

소프트웨어 누가 이렇게 개떡같이 만든 거야 상세보기

데이비드 S. 플랫 지음 | 인사이트 펴냄

소프트웨어 사용이 어려운 이유는? 『소프트웨어 누가 이렇게 개떡같이 만든 거야』는 왜 사용자가 소프트웨어를 사용하기가 어려운지에 대해 이야기한다. 소프트웨어를 어렵게 느끼는 이유는 무엇인지, 누구 때문에 이러한 일들이 발생하는지, 과연 잘 만들어진 소프트웨어는 어떠한 것인지에 대해 재미있고 직관적으로 풀이한다. 잘못된 소프트웨어를 만드는 개발자들의 방식과 사용자들이 생각하는 방법을 대조적으로 알기

저는 웹퍼블리셔입니다. XHTML으로 마크업을 하고 CSS를 가지고 웹디자이너가 건네준 디자인을 브라우저 화면에 재디자인합니다. 그리고 JavaScript로 약간의 재주를 부리기도 합니다.

최근에 웹2.0이라는 경제적 용어가 이슈가 되고, 뒤를 이어서 웹접근성과 웹표준화에 대한 이슈가 커지고 있습니다. 하지만 아직도 많은 수의 클라이언트(기업의 우두머리들)와 웹사이트를 대신해서 만들어주는(웹에이젼시) 기업 내의 거의 모든 사람들은 이를 외면하거나 애써 피하려고만 합니다. 오직 웹퍼블리셔들만이 쫑알쫑알 떠들어 대는 듯한 느낌이 강합니다. 그나마 그것도 소수의 웹퍼블리셔들만이 말입니다.

최근에 저는 사내에서 적극적(?)으로 웹표준 홍보를 하고 있습니다. 웹디자이너들에게 사용자들이 폰트를 크게 키워서 볼 수 있다는 것을 인식시키고, 유연한 레이아웃을 부탁합니다. 바로가기 셀렉트 박스 옆에 버튼을 달아두면 시각장애인도 이용할 수 있을것이다라는 이야기도 합니다. 플래셔에게는 플래시의 대체 텍스트 기능이 들어 있음을 알려줍니다.(저는 플래시를 전혀 모릅니다. 하지만 웹에서 검색을 통해서 알아냈고, 그 사실을 항상 플래시를 다루는 사람들에게 알려주고 있는 겁니다! 이게 뭡니까!) 기획자와는 아주 긴 시간 논쟁을 벌여야 합니다. 그들의 스토리보드를 뜯어고쳐야 하고, 개발 프로세스를 개선할 것을 요구합니다. 그들에게 장차법을 소개하고, 다양한 브라우저를 보여줍니다. 그리고 우리 회사가 만들었던 그 많은 사이트들을 하나씩 보여줍니다. 그들은 당황해 합니다. 그러나 어떻게 해야 할지 모릅니다. 그저 클라이언트가 좋아만 하면 그만이다 말합니다. 20대를 위한 사이트는 20대만 들어오면 되고, 비주얼이 강한 사이트는 시각 장애인이 와도 볼게 없으니 무시해도 된다라는 논리. 청각 장애인을 위해서 간단한 사이트를 하나 더 만들면 되지 않겠냐는 논리. 회원가입 양식에 온갖 항목을 집어놓고 단 하나의 에러도 표시해주지 않아서 다시 처음부터 가입하게 만드는 개발자의 센스. 우리에게 사용자란 무엇인지? 사용자를 위한 사용성이란 무엇인지? 한번 진지하게 고민해봐야 하지 않을까요.

웹표준과 웹접근성에 대한 이슈는 이 책이 지적하는 사용자에 대한 사용성과 아주 밀접한 관계를 가지고 있습니다. 바보같은 개발자들은 자신들의 관점으로 사용성을 판단한다. 맞는 말인것 같습니다. 저도 제가 코딩한 마크업 문서의 오류를 확실하게 찾아내지 못합니다. 제가 작업한 스크립트가 사용자에게 편리함을 준다고 착각할 때가 아주 많습니다. 저 역시 한 명의 사용자라고 생각하기 때문입니다. 하지만 개발자는 어디까지나 개발자입니다. 완벽하게 사용자일 수 없습니다. 온전하게 컴퓨터를 제대로 알지 못하는 사용자 말입니다. 시시때때로 경고창과 말도 안되는 에러 메세지를 띄워서 사용자에게 선택을 강요하는 것은 개발자가 생각하는 사용자에 대한 사용성일 뿐입니다. 사용자들은 그것들을 원하지도 않고, 오히려 불편해 한다는 사실을 이 책은 적나라하게 보여주고 있습니다.

제가 생각하는 한국의 웹은 아주 심각할 정도의 개발자들의 웹입니다. 온통 신기하고 제멋대로인 웹이 지천에 널려 있습니다. 사용자들은 이 불편한 웹을 매번 새롭게 교육받으며 몇번의 시행착오를 거치며 적응해 가고 있습니다.

UI/UX를 떠들면서 우리는 항상 사용자 입장에서 생각한다라는 말을 합니다. 하지만 진정 사용자가 누구였는지를 고민하지 않았습니다.

처음 이 책의 제목을 접했을때 나는 단지 윈도우(또는 맥)의 소프트웨어를 만드는 사람들에게 딴지를 거는 것이겠지 싶었습니다. 하지만 저자는 윈도우와 웹을 폭넓게 껴 안으며 사용자를 무시하는 모든 개발자들을 싸잡아 '바보'로 만들었습니다.

너무나 속이 후련하고 시원합니다. 만약에 당신의 상사가- 대리나 팀장, 과장이나 부장이나 심지어 실장이나 이사라고 할지라도- 정말 바보같다고 느껴진다면 이 책을 읽어보라고 말 하시기 바랍니다. 저는 이 삼품평으로 인해 출판사가 돈을 더 벌고 저자가 비싼 음식을 먹게 할 마음은 추호에도 없습니다. 가까운 도서관에 이 책이 있다면 공짜로라도 보시기를 바랄 뿐입니다. 지인중에 누군가 이미 이 책을 사서 보았다면 빌리거나 복사라도 해서 읽어보시길 바라는 겁니다.

개발자들은 너무나 소심해서 자신을 향해 '바보'라고 욕을 해대면 화를 낼지 모릅니다. 하지만 최소한 그렇게 부끄러워할 줄 아는 개발자라면 이 책을 읽고 사용자에 대한 생각을 고칠수 있을것이라고 생각합니다.