개발자님 제발 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의 차이만이라도 알고 있다면) 문법 오류를 최소한으로 줄일 수 있을것 같다.

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

내용의 선형성, 표현의 비선형성

리좀

들뇌즈와 기타리가 하이퍼텍스를 리좀(중심이 없는 뿌리)에 비유한 것처럼 웹은 비선형적인 매체이다. 개별적인 페이지를 마디로 보고, 각각의 마디는 링크로 이어지면서 웹을 만들어간다. 링크의 소통은 선형적이지 않고 비선형적이다. 사용자는 어떤 링크를 따라가든지 자유다. 제한적인 프로세스에 의한 선형적인 링크가 없지는 않느나, 넓은 웹을 항해하면서 언제나 클릭의 선택은 사용자의 몫이기 때문이다. 하지만 웹의 근간이 되는 HTML문서가 과연 선형적인가 하는 의문을 가져본다. 아니 HTML문서는 선형적이어야 하지 않나 생각해본다.

과거에 Table 앨리먼트를 이용해서 코딩을 할 때는 디자인소스를 바라보는 시각과 동일한 방식으로 HTML문서를 작성했다. 고쳐 말해서 디자인에서의 헤더와 풋터, 컨텐츠 영역의 위치를 그대로 받아들여 코딩을 한다는 개념인데 이는 웹접근성을 고려한다면 크게 잘못된 것이라고 생각한다.

HTML문서와 스타일시트의 분리는 단순히 스킨 개념의 편리성을 위한 것은 아닐 것이다. 표현과 내용의 분리는 내용이 표현이 종속되지 않는다는 것인데 이는 한번 작성된 내용이 중복되어 생산되지 않으면서도 다양한 플랫폼과 브라우저에서 내용전달의 차별을 두지 않도록 하는 것이다. 즉, PC용 브라우저와 PDA용 브라우저간에 표현(디자인)은 다르나, 그 내용은 동일해야 한다는 것을 의미한다.

이러한 표현과 내용의 분리를 위해서는 과거의 코딩스타일을 깰 필요가 있다고 본다. 나 역시 그러하지만 대부분의 웹퍼블리셔와 디자이너들이 Table 앨리먼트를 이용한 레이아웃 잡기를 하고 있는데 이는 결과적으로 HTML문서의 비선형성을 만들어낸다. (웹은 본래 비성형적인 매체이지 않은가? 라는 질문이 있을수 있는데 이는 다시 정리해서 적겠다) 나는 HTML문서는 선형적이어야 한다고 생각한다. HTML문서의 선형성은 내용의 선형성을 말하는데 HTML이 인터넷에서 이용되는 문서의 표준이라고 할 때, 아주 특별한 경우(하이퍼텍스트 문학이나 웹아트)가 아니라면 선형적인 특징을 가져야 하고, 가져야 한다고 본다.

세세한 항목을 나열하지는 않겠으나 일반적인 웹사이트를 생각해 볼 때, 구조상으로 화면에 드러나지 않는 각종 정보(메타정보)가 기록되고, 제목과 록고, 공지사항과 뉴스, 주요 컨텐츠, 저작권 표시, 광고 등의 순서로 코딩되어야 한다는 것이다. 그래서 HTML문서가 표현내용(스타일시트)을 포함하지 않았을 때 페이지의 내용이 중요도에 따라 순서대로 나열되어야 한다. 이는 웹에 올라온 HTML문서가 CSS를 불러오지 못하거나, CSS를 지원하지 않는 브라우저를 사용하는 사용자나, CSS를 불러와도 확인할 수 없는 시각장애자등을 위한 기본적인 배려이자 웹접근성을 고려한 웹퍼블리셔의 기본이어야 한다.

그리고 다수의 웹유저들에게 보여질 표현정보를 스타일시트로 온전하게 분리하여 작성한다면, 선형적인 HTML문서를 디자인과 동일하게 재디자인할 수 있게 된다.


2006/10/14 - [하이퍼텍스트문학] - 하이퍼텍스트 문학의 비선형성 연구

웹퍼블리싱은 퍼즐맞추기다.

오늘 미투에서 퍼즐을 맞추시는 분과 댓글을 주고 받다가 문득 내가 하고 있는 웹퍼블리싱도 퍼즐같다라는 느낌이 들었다. 천피스나 오천피스쯤 되는 조각들을 네모 반듯한 프레임에 하나씩 맞추어 간는 것. 각각의 모양은 틀리고, 또한 비슷하다. 네 귀퉁이 중에 어디서부터 시작해도 괜찮고, 한 가운데서부터 시작해도 된다. 퍼즐을 시작하고 맞추어 가는 과정에는 규칙이 없다. 자신만의 생각과 스타일로 완성을 해나가는 것. 그것이 퍼즐의 묘미일것 같다. 하지만 결과는 정해져 있다. 프레임을 가득 채워야 하고, 그것은 정해진 이미지를 보여주어야 한다는 것이다.

웹퍼블리싱은 웹사이트를 HTML언어로 디자인을 짜맞추는 작업이다. 퍼즐에 각각의 모양을 갖춘 피스들이 있다면 내게는 A, IMG, DIV와 같은 미리 정의된 앨리먼트들이 주어져 있다. 퍼즐이 네 귀퉁이를 가진 네모 반듯한 프레임이듯 내게 역시 네 귀퉁이를 가진  브라우저와 모니터가 주어져 있다. 나는 HTML앨리먼트들을 요리 조리 고민하며 화면에 끼워 맞춘다. 헤더를 먼저 시작하기도 하고, 풋터를 먼저 시작하기도 한다. 컨텐츠부분을 미리 맞추어 놓을수도 있다. 하지만 언제나 완성된 모습은 디자이너가 그려 놓은 이미지와 동일해야 한다.

내 손이 앨리먼트를 만지작 거리며 화면을 채워나가는 과정이 어색하지 않은 이유는 오랜시간 내가 이 공부를 해온 탓도 있겠지만 어린시절 동생과 함께 머리를 맞대며 그림조각을 찾아 맞추던 추억에서 아주 멀리 벗어나 있지만은 않기 때문일까 하는 생각을 해본다.

웹표준화 작업에 따른 용어의 혼란

말과 글이라는게 참 어렵고, 중요한 것이라서 어떻게 불리고, 어떻게 씌여지느냐에 따라 성격이 달라지는것 같습니다. 그리고 본래 용어가 없는 것이 행동이나 결과로 나타나면서 새롭게 만들어지기도 하고, 용어가 발생하고 의미를 부여받으면서 성격이 굳어지기도 합니다. 최근에 웹표준화 작업이 빈번해지면서 과거와 현재의 용어가 충돌하는 모습을 종종 보게 되는것 같습니다.

1. 코딩과 퍼블리싱

우리같은 사람들이 하는 일을 가르켜 대부분이 '코딩'이라고 하죠. 하지만 자바든 C든 코드를 작성하는 작업 역시 '코딩'이거든요. 그래서 개발자분들과 대화할땐 '코딩'이라는 용어때문에 혼란을 빚기도 합니다. 다행히 요즘은 '퍼블리싱'이라는 용어를 쓰면서 그 의미를 새롭게 정의하고 있죠.

2. (HTML)코더와 웹퍼블리셔

업무 자체를 부르던 용어는 그 직종의 이름이 됩니다. 코딩을 한다라고 말 했을때 우린 '(HTML)코더'였고, 퍼블리싱 작업을 한다고 하는 지금은 '웹퍼블리셔'입니다. ('나는 웹퍼블리셔입니다' 참고) 사실 둘의 차이는 없습니다. 하지만 용어의 차이가 가져다 주는 느낌은 아주 다릅니다. '코더'일 때 우린 디자이너와 개발자 사이에서 자리도 제대로 잡지 못하고, 때론 멸시를 받아가면서 한낱 '알바'에 불과한 일을 하고 있다고 생각해야 했습니다. 하지만 지금은 당당하게 '웹퍼블리셔'임을 밝히며, 우리가 하는 일에 자부심을 가지기 시작했습니다. 디자이너와 개발자도 함부로 하지 못합니다.

3. TABLE코딩과 DIV코딩

표준화 작업과 관련해서 'DIV코딩'이라는 정체 불명의 용어도 생겨났습니다. 그리고 과거의 비표준화 코딩을 'TABLE코딩'이라고 부르게 되더군요. 어찌보면 맞습니다. 표준화 코딩시에 가장 많이 등장하는 태그가 아무래도 'DIV'이고, 과거의 방식에서는 'TABLE'이 가장 많이 나왔죠. 다시 말해 디자인을 구조화시키는 작업에서 그 레이아웃을 잡는데 있어 핵심이 되는 태그가 'TABLE'에서 'DIV'로 바뀐점을 시사합니다. 그래서 꼭 틀린 의미로 보이지는 않더군요. 다만, 'DIV코딩'이 마치 'TABLE'태그를 완벽하게 대체한다는 의미로 오해될 수도 있는것 같습니다. 이건 아니겠죠. 표준화 코딩에서 'TABLE'태그 역시 사용 가능한 태그이고, 표를 만들어야할 자리에 궂이 'DIV'로 어려움을 사서 할 이유는 없으니까요.

현장에서 일을 하고 있는 퍼블리셔들은 누구보다 이러한 용어의 혼란을 잘 알고 있을겁니다. 지금 이 순간에도 "아무개씨 코딩좀 부탁해요", '요즘은 코더 구하기가 어려워", "코딩 잘 되가?" 라는 말들을 듣고 있는 분들이 계실겁니다. 비교가 되지는 않지만 일본이 독도를 다케시마라고 부르는 것을 우리는 참지 못하죠. 누군가 우리를 그저 코더라고만 부른다면 괜히 화가 날지도 모릅니다. 표준화 코딩이라고 하지 않고, DIV코딩이라고 하면 그 사람의 무지함에 치를 떨수도 있습니다. 하지만 어디까지나 과도기적인 현상이라고 생각합니다. 우리들 조차도 스스로를 '웹퍼블리셔'라고 말하지 않는 사람이 아직도 많고, '퍼블리싱'보다는 '코딩'이라는 용어가 더 편하게 느껴지기도 합니다. TABLE코딩이든 DIV코딩이든 나 스스로 이해하고, 작업을 진행시킬 수 있기도 합니다. 차차 나아지리라 봅니다. 직종을 가르키는 용어가 이미 널리 알려지기 시작했다는건 그래서 참 다행인겁니다. 웹표준화라는 용어도 많이 알려져 있구요. 개인적으로 '퍼블리싱'과 '코딩'중에는 '코딩'이 좀 더 편하더군요. 프로그래밍도 흔히 '개발'이라고 짧은 용어로 많이 쓰죠. 다만, 세번째 TABLE코딩과 DIV코딩의 문제는 신중하게 반응해 봐야겠습니다. 누군가 "DIV코딩해 주세요"라고 한다면, "아 표준화코딩이요?"라고 되물어 줍시다. 그렇게 자연스럽게 용어를 바꿔 나가면, 인식과 의미가 변해가지 않을까요.