stophobia

웹표준에 무슨 마크업의 기준이 존재하겠습니까.

기준이라는 것이, 사실은 상대적인 규칙입니다. 웹 퍼블리셔 자신이 만들어가는 기준이라고 할 수 있겠죠. 좀 더 규칙적이고 이해하기 쉬운 규칙을 찾느냐 아니냐는 전적으로 웹퍼블리셔에게 달려있겠고요.

제가 제시하고자 하는 기준은 이러한 규칙을 설정하는데 있어서 어느 정도의 틀을 제공하고자 하는 것이구요.

원문의 인용은 맨 뒤에 싣도록 하겠습니다. 제가 봐도 머리가 어지러워서...

웹페이지를 출판하는데 있어서 "구조화"라는 것은 이제까지 웹퍼블리셔들이 의식하지 못했던, 그러나 분명히 존재했던 문제들을 수면위로 끌어올립니다.

바로 "자유"인데요, 이것은 "무슨 코드를 사용할 것인가"와 관련이 있습니다. 자신이 "왜 여기에 이렇게 지정을 했는가"정도만 설명할 수 있다면 특별히 문제가 없는 정도지요.

역으로 "구속"도 있는데요, 이것은 "무슨 DTD를 사용할 것인가", "특수한 경우에 있는 유저들을 위한 CSS를 표현하기 위해서는 어떠한 방식으로 CSS를 지정할 수 있는가" 등과 관련이 있겠지요. 이건 선택의 여지가 별로 없습니다.

예전에도 이러한 고민은 존재했겠습니다만, 어지간한 고민은 대충 해결해 주었던 IE6 덕분에 그리 골치 아프지는 않았던 것 같습니다.

그럼, 어디까지가 자유고, 어디까지가 속박인가... 그에 대한 기준을 알아보고자 하는 것이지요.

사실은 이러한 기준이 IETF의 문서 RFC2119에 기술되어있습니다. 이 문서는 XHTML1.0의 사양서에도 언급된 문서입니다.
 
구분은 대충 MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, OPTIONAL 정도가 있는 것 같지만, 제 나름대로 3단계로 나누어 보았습니다. 더 아실 분은 맨 밑의 원문을 참조해 주세요...

필수(MUST) : 문법이 문서형 정의에 어긋나지 않은가?
추천(SHOULD) : 사양서에서 정해놓은 방침을 따르는가?
가능(MAY) : 구조화나 의미의 부여, 목적이나 문맥에 의한 용법에 부합하는가?

필수 : 필수 레벨은 XHTML, XML문서에 명시되고 있는 사항으로, W3C의 밸리데이션에서 페이지의 오류를 체크하는 기준이 되는 것 같습니다. 최저한의 기준, 마지노선이 되겠지요.
혹자는 밸리데이션을 받은 것 만으로 "웹표준"이라는 사람도 있지만, 그러한 정의와는 조금 다릅니다.
테이블 레이아웃도 밸리데이션받는데 아무 문제 없으니까요.

추천 : 여기서부터는 문법 이상의 것을 요구합니다. 예를 들어, "구조와 표현의 분리"라는 것도 여기서부터의 레벨입니다.
필수 레벨과의 최대 차이는, 문맥이나 목적에 따라 올바른 마크업을 사용하고 있는지, 구조에 맞는 태그를 사용하고 있는지를 생각하게 되는 레벨이지요. 프로그램으로는 이러한 타당성을 체크하는 것이 매우 어렵습니다.

가능 : 이 부분은 완벽하게 웹퍼블리셔의 자유에 맡겨진 부분입니다. 그만큼, 초보 웹퍼블리셔와 숙련된 웹퍼블리셔를 구분짓는 부분이기도 하지요.
인용문을 <q>로 마크업할 것인지, <cite>로 마크업할 것인지, 또는 강조 구문을 <em>으로 마크업할 것인지, <strong>으로 마크업할 것인지의 문제입니다. 무엇을 쓰던 상관은 없습니다. 다만, "얼마나 납득가능한 설명을 하느냐"에 달렸다고 해도 과언은 아닐겁니다.

아래는 문서의 원본을 게재해 보았습니다.
해석 여부에 따라 다양한 생각이 나게하는 문서네요...
(조금 정확한 표현을 쓰자면... 애매하다는 뜻입니다. 결국 XHTML사양서를 잘 읽으시오! 정도로 요약이 됩니다.)

Network Working Group                                         S. Bradner
Request for Comments: 2119                            Harvard University
BCP: 14                                                       March 1997
Category: Best Current Practice

        Key words for use in RFCs to Indicate Requirement Levels

Status of this Memo

   This document specifies an Internet Best Current Practices for the
   Internet Community, and requests discussion and suggestions for
   improvements.  Distribution of this memo is unlimited.

Abstract

   In many standards track documents several words are used to signify
   the requirements in the specification.  These words are often
   capitalized.  This document defines these words as they should be
   interpreted in IETF documents.  Authors who follow these guidelines
   should incorporate this phrase near the beginning of their document:

      The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
      NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and
      "OPTIONAL" in this document are to be interpreted as described in
      RFC 2119.

   Note that the force of these words is modified by the requirement
   level of the document in which they are used.

1. MUST   This word, or the terms "REQUIRED" or "SHALL", mean that the
   definition is an absolute requirement of the specification.

2. MUST NOT   This phrase, or the phrase "SHALL NOT", mean that the
   definition is an absolute prohibition of the specification.

3. SHOULD   This word, or the adjective "RECOMMENDED", mean that there
   may exist valid reasons in particular circumstances to ignore a
   particular item, but the full implications must be understood and
   carefully weighed before choosing a different course.

4. SHOULD NOT   This phrase, or the phrase "NOT RECOMMENDED" mean that
   there may exist valid reasons in particular circumstances when the
   particular behavior is acceptable or even useful, but the full
   implications should be understood and the case carefully weighed
   before implementing any behavior described with this label.

5. MAY   This word, or the adjective "OPTIONAL", mean that an item is
   truly optional.  One vendor may choose to include the item because a
   particular marketplace requires it or because the vendor feels that
   it enhances the product while another vendor may omit the same item.
   An implementation which does not include a particular option MUST be
   prepared to interoperate with another implementation which does
   include the option, though perhaps with reduced functionality. In the
   same vein an implementation which does include a particular option
   MUST be prepared to interoperate with another implementation which
   does not include the option (except, of course, for the feature the
   option provides.)

6. Guidance in the use of these Imperatives

   Imperatives of the type defined in this memo must be used with care
   and sparingly.  In particular, they MUST only be used where it is
   actually required for interoperation or to limit behavior which has
   potential for causing harm (e.g., limiting retransmisssions)  For
   example, they must not be used to try to impose a particular method
   on implementors where the method is not required for
   interoperability.

7. Security Considerations

   These terms are frequently used to specify behavior with security
   implications.  The effects on security of not implementing a MUST or
   SHOULD, or doing something the specification says MUST NOT or SHOULD
   NOT be done may be very subtle. Document authors should take the time
   to elaborate the security implications of not following
   recommendations or requirements as most implementors will not have
   had the benefit of the experience and discussion that produced the
   specification.

8. Acknowledgments

   The definitions of these terms are an amalgam of definitions taken
   from a number of RFCs.  In addition, suggestions have been
   incorporated from a number of people including Robert Ullmann, Thomas
   Narten, Neal McBurnett, and Robert Elz.

9. Author's Address

Scott Bradner
      Harvard University
      1350 Mass. Ave.
      Cambridge, MA 02138

      phone - +1 617 495 3864

      email - sob@harvard.edu

---

Copyright (C) The Internet Society (March 1997).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

앞의 글에서 DIV의 존재에 대해서까지 고찰했습니다만, 문제는 "최대한의 구조화"입니다.

사이트를 구조적으로 만들기 위해서는 의미에 맞는 마크업도 중요하지만, 마크업에 부여하는 ID, CLASS명도 중요하다고 생각합니다.

조금 빗나간 이야기지만, ID명, CLASS명 합쳐보면, 심한 경우는 코드와 비슷할 정도로 많은 바이트를 차지하는 경우도 있습니다.

그런 의미에서 보면, 이런 것도 웹표준을 위해 신경써야하지 않나 생각합니다.

일단 기본적으로 논리구조를 살펴봅시다. 논리구조를 올바로 파악하지 않고 있다면 올바른 ID명, CLASS명을 붙이기도 힘들어지니까요.

1. 종래의 이름 vs 제안

종래의 이름	제안
ID:header   CLASS:description              information              gloval_nav ID:body   CLASS:contents                 hot_topics                 hot_products               sidebar                 sub_nav                 banners ID:footer   CLASS:credit               privacy	ID:site   CLASS:description              information              navigation ID:page   CLASS:recent                 information                 products               related                 navigation                 services ID:publication   CLASS:credit               privacy

2. 보다 구조를 의식한 CLASS이름을 붙이자!

구체적으로, 위에 나타난 예와 같이 CLASS이름을 상층에서 하층으로 늘어놓았을 때, 논리적인 일관성이 유지되도록 합니다. 하나의 기준으로, CLASS이름을 자연문(일반적인 문장)으로 바꿔보고, 부자연스럽지는 않은지 체크해 봅니다.

예를 들어, #header .description 에 들어갈 내용은, 감히 추측해 보건대, "사이트에 관한 설명"이 기술되어 있지 않을까요? 어찌되었던 "헤더에 관한 설명"이 들어가 있지는 않으리라 생각합니다.

이런 생각으로 하나하나 살펴보면

site - description: 사이트 전체에 대한 - 설명문
site - information: 사이트 전체에 대한 - 정보
site - navigation: 사이트 전체에 대한 - 안내
page - navigation: 페이지 고유의 - 안내
page - recent - information: 페이지 고유의 - 최신 - 정보
page - recent - products: 페이지 고유의 - 최신 - 제품
related - services: 관련된 - 서비스

header나 (main)contents, body, footer 등은, Web 페이지를 작성할 때에 많이 사용되는 id, class명입니다만, 보통 "header"의 공간에는 사이트 공통의 메타레벨 콘텐츠가, 또 "body"의 공간에는 그 페이지 고유의 오리지날 컨텐츠가 포함되는 경우가 많다는데에 착안하여, 사이트 공통의 정보와 페이지 고유의 정보를 구별하는 의미로, header 부분을 "site", body(혹은 (main)contents) 부분을 "page"라는 이름으로 해 보았습니다.
만약 "페이지 고유의 최신 정보"라는 문맥이 마음에 들지 않으시면, ourCompany - recent - product(우리 회사의 최신 제품)등으로 하는 방법도 있습니다.

각각의 상황이나 목적에 어울리도록, 적절하게 논리 구조를 추상화한 이름을 붙여 보면 좋을 것같습니다.

3. 논리적으로 동급의 경우에는 의식적으로 같은 class명을 붙인다.

#header .global_nav -> #site .navigation
#body .local_nav -> #page .navigation

CSS에서는 글로벌 네비게이션과 로컬 네비게이션을 구별하고 싶을 때 셀렉터의 기술만으로도 간단하게 처리할 수 있습니다. 이 쪽이 각 네비게이션을 구별하거나 동일화할 때, 어느쪽에서든지 사용할 수 있기 때문에, 더욱 유연성이 있다고 생각할 수 있습니다.

4. 종래의 이름도 상관은 없습니다만...

실제 많은 웹페이지를 출판하시는 웹퍼블리셔들이 구조를 무시한 외관 위주, 또는 습관적으로 마크업을 해 버리는 경우가 많습니다. 심지어는 어느 홈페이지던간에 구별없이 "템플레이트"라는 물건을 만들어 ID와 CLASS를 "생각할 시간을 절약"하는 경우도 있는 것 같습니다.

하지만, 더욱 구조를 생각하는 마크업을 하려 하신다면, 조금 더 생각해 보셔도 그리 시간이 아깝지 않은 문제라고 생각합니다.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

예전에 HOONEY님의 블로그에서 파이어폭스의 default CSS 에 대한 글을 읽었습니다만,

웹 브라우저마다 각각 default CSS가 존재합니다. cascade한 CSS의 특성상, 제작자가 작성한 CSS도 브라우저의 디폴트 CSS의 영향을 받습니다. 웹 사이트가 브라우저마다 조금씩 다르게(경우에 따라 심각하게) 표현되는 이유가 바로 default CSS 때문입니다.

라는 글을 읽고 흥미를 가지고 있던 중, 여기저기서 정보를 얻어 정리해 보았습니다.

AccessifyForum.com이라는 곳에서는 list of browsers' default CSS 이라는 이슈도 있군요.

locations of default stylesheets
브라우저	운영체제	모드	관련 파일 경로
(W3C CSS 2.1 CR)		HTML4	http://www.w3.org/TR/CSS21/sample.html
파이어폭스	윈도우즈	HTML4	C:\Program Files\Mozilla Firefox\res\html.css
		Quirks	C:\Program Files\Mozilla Firefox\res\quirks.css
	맥	HTML4	/Applications/Firefox.app/Contents/MacOS/res/html.css
		Quirks	/Applications/Firefox.app/Contents/MacOS/res/quirks.css
IE6	윈도우즈		DLL
IE7	윈도우즈		?
IE5	맥		?
오페라	윈도우즈, 맥		?
사파리	맥	HTML4	/sw/share/apps/khtml/css/html4.css
		Quirks	/sw/share/apps/khtml/css/html4.css
	윈도우즈	HTML4	?
		Quirks	?

흠... 뭐 별 영양가는 없지만...

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

사용자가 어떤 위치에 있는지를 가르쳐 주는 링크 리스트(home>news>entertainment 처럼 컨텐츠 위에 오는 부분. 저는 클래스명으로 linkway라고 써서 사용하고 있습니다만)는 어떻게 작성해서 사용하고 계시나요?

링크리스트의 논리, 구조면에서 보기 위해, (X)HTML 마크업의 예를 몇 개 들어 보았습니다. CSS 이야기까지 하면 길어지므로, 이번은(X)HTML 마크 업만 이야기하죠.

1. 계층형 구조(tree structure)
구조화를 중시한다면 a요소에 rel/rev속성을 더해 링크의 관계성을 명시해야 합니다.

a요소의 rel속성 (참고 : O'Reilly HTML 리퍼런스 원문)
현재의 요소와 링크와의 관계를 정의합니다. 포워드 링크라고도 합니다. href속성으로 주소를 지정하는 링크와는 다르기 때문에 주의가 필요합니다. HTML4권고에서는 몇개의 링크 타입을 정의하고 있지만, 값의 적용 방법은 브라우저에 따라 다릅니다. 이 속성은 주로 LINK요소로서 기능하고 있지만, 링크로서 기능하고 있는 A요소를 다음 또는 전의 일련의 문서를 가리키는 고정 내비게이션바의 버튼에 지정하는 등, 이것 이외의 기능을 가진 가능성이 충분히 있습니다. REL속성을 적용하려면, 이 요소에 HREF속성도 같이 설정할 필요가 있습니다.

예시:
<a href="chapter3.html" rel="next chapter">chapter 3</a>

a요소의 rev속성 (참고 : O'Reilly HTML 리퍼런스 원문)
리버스 링크의 관계. REL속성과 같이, REV속성의 기능을 브라우저에 따라 다르게 정의할 수 있습니다. 특히, 브라우저가 HTML4사양에서 사용 가능한 여러가지 링크 타입을 해석해서 처리하는 방법은 브라우저에 따라 다릅니다. 상호간 링크에서 서로 가리키는 두개의 문서A와 B의 경우, B의 REV값은 A의 REL속성에 지정한 2개의 문서간의 관계와 같은 것을 지정할 수 있습니다. 주로 브라우저의 A요소의 REL또는 REV속성에는 아직 실용적인 기능이 없습니다.

예시:
<a href="chapter2.html" rev="previous">chapter 2</a>

사이트 전체가 트리 구조를 이루고 있는 경우는, 링크 리스트의 계층도 알기 쉽습니다. "계층"이라고 하는 구조(시멘틱)를 중시한다는 의미에서, 다음과 같이 리스트를 상자 형식으로 만듭니다. 정확히 네비게이션 메뉴용의 리스트에서, 현재 위치와 상위 계층만을 표시하기 때문에, 불필요한 코드를 최대한 깎은 것 같은 모습이 됩니다.

<ul class="breadcrumbs">
  <li><a href="/" rel="start">톱</a>
    <ul>
      <li><a href="/category/" rev="section">카테고리</a>
        <ul>
          <li>현재 위치</li>
        </ul>
      </li>
    </ul>
  </li>
</ul>

이 마크업으로 CSS를 꾸미는 경우, 원근법처럼 계층이 현재 위치에 가까운 만큼 font-size 를 크게 하는, 이제까지의 링크리스트와는 조금 색다른 디자인을 할 수도 있습니다.

2. 리니어형 구조(sequential structure)
사이트 컨텐츠가 프리젠테이션의 슬라이드처럼 순서에 따라서 직선적으로 진행되는 선형 모델인 경우, 계층이 없는 순서에 쓰는 리스트(ol요소)가 적합합니다. 이 경우, 물론 선두 페이지로의 링크를 제시하는 것도 중요하지만, "어디에서 왔습니다" → "지금, 어디에 있습니다" → "다음엔 어디어디로 갈 수 있습니다"를 파악하기 쉽게 제시할 수 있으면 좋겠지요.

<ol class="breadcrumbs">
  <li><a href="/page1.html" rel="prev">page 1</a></li>
  <li>page 2</li>
  <li><a href="/page3.html" rel="next">Page 3</a></li>
</ol>

3. 시각 장애자 전용(for screen reader users)
스크린 리더(음성 브라우저)의 유저를 생각하면, 위의 마크업은 약간 불친절한 부분이 있습니다.(물론, 표제나 주기를 더하는 등, 보강도 가능합니다만, 마크업의 초점을 확실히 하기 위해, 위의 예에서는 이러한 보강책 부분은 일부러 생략하고 있습니다.) 그러한 유저에게, 보다 알기 쉬운 링크리스트를 제공하기 위해, 리스트가 아닌, 자연문으로 하는 방법도 있습니다.

<p class="breadcrumbs">
  <span>현재 위치는,</span><a href="/">톱</a><span>의 아래의,</span><a href="/category/">카테고리</a><span>의 아래의,</span><a href="/category/subcategory/">컨텐츠</a><span>입니다.</span>
</p>

CSS 적용을 위해, 불필요한 span요소가 들어가 있는 것과 사이트 구조의 정보 전달이 이전 형식에 비해 이해하기 어렵게 되어있다는 점이, 그다지 좋은 예라고는 할 수 없지만,

@media screen, print { p.breadcrumbs span { display: none; } }
 
으로 해 두면, 음성 브라우저에서는 자연문장으로서 읽어 내리게 할 수 있고, 브라우저의 화면이나, 인쇄 매체에 대해서는 span 요소로 싸여진 부분만 숨겨서, 링크리스트 네비게이션과 같이 보이게 할 수 있습니다.

(그래도, 외양 때문에 구조를 건드린다는 것은 좀 더 공부가 필요한 부분이군요.)

XHTML 2.0에서는...(덤)
차세대 규격인 XHTML 2.0에서는 nl 요소가 등장한다고 합니다. HTML 5에서는 nav 요소가 준비되어있군요. nl 요소에는 role이라고 하는, 요소의 "역할"을 지정하는 속성을 붙일 수 있습니다. 이 role속성의 값을 이름을 써두는 식으로도 이용할 수 있겠지요. 덧붙여XHTML 2.0에서는, 이하의 li요소의 예처럼, a요소를 이용하지 않아도, 대부분의 요소에 하이퍼 링크(href 속성)를 적용할 수 있게 됩니다.

<nl role="breadcrumbs">
  <label>현재 위치:</label>
  <li href="/">톱</li>
  <li href="/category/">카테고리</li>
  <li href="/category/subcategory/">컨텐츠</li>
</nl>

간단해 보이는 링크리스트이지만, 목적이나 상황에 따라 다양한 선택사항이 있네요.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

참고로, Adobe Dreamweaver CS3에 탑재된 O’Reilly HTML Reference에 실린 DIV태그에 대한 정의와, TABLE태그에 대한 정의를 소개해 드립니다. 두 태그 전부 HTML3.2 버전부터 적용이 가능하게 된 태그이며, 따라서 일부 웹퍼블리셔들이 오해하고 있는 “구버전 브라우저를 지원하기 위한 방편으로서의 TABLE레이아웃, 구버전 브라우저와 신버전 브라우저를 아우르는 표현을 위한 방편으로서의 DIV레이아웃”은 전혀 근거없는 주장임을 확인해 드립니다.

또한, 웹 업계의 유명 서적을 인용하긴 했지만, 이것 역시 DIV와 TABLE에 대한 수많은 정의 중의 하나에 지나지 않으며, 따라서 이러한 견해가 있다는 정도로 참고만 해주시면 감사하겠습니다. (오렐리가 말했으니 정의야! 라고 말하면 안되지요.)

DIV – The div element gives structure and context to any block-level content in a document. Unlike some other structural elements that have very specific connotations attached to them (the p element, for instance), the author is free to give meaning to each particular div element by virtue of the element’s attribute settings and nested content within the required start and end tags.
It is most convenient to use the div element as a wrapper for multielement content that is to be governed by a single style sheet rule. For example, if a block of content includes three paragraphs, rather than assign a special font style to each of the p elements, you can wrap all three p elements with a single div element whose style sheet defines the requested font style. Such a style sheet could be defined as an inline style attribute of the div element or assigned via the class or id attribute, depending on the structure of the rest of the document.
Div elements are block-level elements. If you need an arbitrary container for inline content, use the span element, instead.

(DIV 요소는 문서의 블록 레벨 컨텐츠에 구조와 문맥을 부여해 줍니다. 특정의 속성이 부속되어 있는 다른 구조 요소(P요소 등) 와는 달리, 요소의 속성 설정과 중첩되고 있는 컨텐츠를 이용해 특정의 DIV 요소에 자유롭게 의미를 갖게할 수 있습니다. 각 DIV 요소는 개시 태그와 종료 태그와의 사이에 있는 모든 컨텐츠에 대한 범용의 블록 레벨 컨테이너가 됩니다.
단일의 스타일 시트 규칙으로 제어되는 복수 요소 컨텐츠의 반복이라고 해도 DIV 요소를 사용하면 편리합니다. 예를 들어, 컨텐츠의 블록에 3개의 단락이 있는 경우, 각 P요소에 특별한 폰트 스타일을 지정하는 것이 아니라, 모든 P요소를 스타일 시트로 필요한 폰트 스타일을 정의하는 단일의 DIV 요소로 둘러쌀 수 있습니다. 이러한 스타일 시트는, 나머지의 문서의 구조에 의해서 DIV 요소의 인라인 STYLE 속성으로서 정의하는지, CLASS 속성 또는 ID속성으로부터 지정할 수 있습니다.
DIV 요소는 블록 레벨 요소입니다. 인라인 컨텐츠에 임의의 컨텐츠가 필요한 경우는, SPAN 요소를 대신에 사용합니다.)
제가 생각하기에, DIV는 특별한 의미 없이, 컨텐츠를 담아두는 상자라는 뜻으로 이해가 됩니다.

TABLE – The table element is a container for additional elements that specify the content for a table. A table consists of rows and columns of content. Other elements related to the table element are caption, col, colgroup, tbody, td, tfoot, th, thead, and tr. The purpose of the table element is to define a number of visible attributes that apply to the entire table, regardless of the number of rows or columns within it. Many of these attributes can be overridden for a given row, column, or cell. The number of rows and columns is strictly a factor of the structure of tr and td elements within the table.
Tables have been used for a relatively long time not only to organize rows and columns o f content but also to position content. With no visible borders, table rows and columns can be set to empty space. With the advent of positionable content, the table-for-positioning practice is not encouraged.
Deeply nested tables (tables within tables) can cause problems in some browsers. Navigator 4 has severe difficulty with style sheet inheritance and overall performance in complex tables (nesting beyond three level is asking for trouble). IE 5/Mac can inexplicably explode cell dimensions when scripts create or modify table-related elements. The simpler you keep your table structure, the more reliable your pages will be across browsers. Heavy editing of table structures in visual HTML authoring tools can leave hidden complexities (e.g., lots of empty cells) in your source code. Temporarily turn on a thin table border to see the exact row and column structure.

(TABLE 요소는, 테이블의 컨텐츠를 지정하는 추가 요소의 컨테이너입니다. 테이블에는, 컨텐츠의 행과 열로부터 구성됩니다. TABLE 요소에 관련하는 그 외의 요소는, CAPTION, COL, COLGROUP, TBODY, TD, TFOOT, TH, THEAD, 및 TR입니다. TABLE 요소의 목적은, 테이블내의 행이나 열의 수에 관계없이, 테이블 전체에 적용되는 표시 속성의 대부분을 정의하는 것입니다. 이러한 속성의 상당수는, 특정의 행, 열, 셀로 덧쓰기할 수 있습니다. 행과 열의 수는, 테이블내의 TR 및 TD요소의 구조에 있어서 중요한 요인입니다.
테이블은 컨텐츠의 행과 열을 정리하는 목적에만 나오지 않고, 컨텐츠의 배치에도 오랫동안 사용되어 왔습니다. 테이블의 행과 열을 보더가 없는 빈 영역으로 설정할 수 있습니다. 배치 가능한 컨텐츠가 이미 존재하기 때문에, 배치를 위해서 테이블을 사용하는 것은 추천할 수 없습니다.
깊게 중첩된 테이블(테이블내의 테이블)은, 일부 브라우저에서 문제의 원인이 되는 경우가 있습니다. Navigator4에서는, 복잡한 테이블에서의 스타일 시트 계승과 전체적인 퍼포먼스에 큰 문제가 있습니다. 중첩 레벨이 3개를 넘으면 문제가 발생합니다. MAC용 IE5에서는, 스크립트로 테이블 관련의 요소를 작성 또는 변경하면, 셀의 치수가 커지는 경우가 있습니다. 테이블의 구조가 단순하면 단순할수록, 종류가 다른 브라우저에서의 외관의 신뢰성이 높아집니다. 비주얼한 HTML 출판도구로 테이블 구조의 편집을 반복하면, 표시되지 않는 복잡한 항목(다수의 공백 셀 등)이 소스 코드에 남아 있을 가능성이 있습니다. 가끔 테이블 보더를 표시해서, 정확한 행과 열의 구조를 확인해 주세요.)
테이블에 컨텐츠를 지정할 수 있다는 것은, 단순한 수치나 타이틀의 범위를 넘어서는 자료들도 그 대상이 된다는 뜻으로 이해해도 되겠군요. 단, 컨텐츠의 배치만을 위해 사용하는 것은 추천하지 않는다라고 되어있습니다.

위 글을 읽고 “뭐하는 소리야”하고 넘어가시는 분들도 계시리라 믿습니다. 하지만, 이러한 논의가 웹표준을 좀 더 좋은 방향으로 이끌 것이라는 데에 추호의 의심이 없습니다.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

웹표준 신자들이 하루가 멀다하고 세를 늘려가는 판국에, 나름대로 웹표준의 이후를 추측하는 글을 쓰려합니다.

많이 모자란 글이지만, 이렇게 생각하는 사람도 있다는 정도만 알아주시면 감사하겠습니다.

일단, 테이블 레이아웃에 대한 이야기부터 꺼내지 않으면 안되겠습니다. 지금은 테이블 레이아웃에 대해서 얘기하면 곧바로 회사의 돈을 좀먹는 시대에 뒤떨어진 직원으로 (웹퍼블리셔의 명칭도 붙이지 못할 정도로 천대를 받지요) 낙인 찍히기 마련입니다. 왜냐? 테이블 코딩은 테이블만을 위한 코딩으로, 데이타를 종과 횡으로 배치하여 그 상관관계를 표현하기 위한 마크업이기 때문이지요. 저도 마찬가지라고 생각합니다. 그럼 약간 다른 방향으로 생각해볼까요?

HEADER, MENU, CONTENTS, FOOTER가 각각의 상관관계를 가지고 데이타로서의 값어치를 가진다면? 여기서 데이터란 수치화된 자료의 범위를 넘어, 정보의 단위로 생각을 바꾸어봅시다.
HEADER - 웹사이트를 대표하는 정보.
MENU - 웹사이트의 구조 파악을 위한 정보로서, 페이지 간의 이동 수단까지 제공.
CONTENTS - 웹사이트의 존재 목적으로 인정되는 정보.
FOOTER – 웹사이트 이용에 있어 부차적인 정보.
이러한 정보를 테이블에 담아서 제공한다…고 생각하신다면 어떠신가요? 구조적으로 말이지요… 외관은 전혀 신경쓰지 말고요. TH, TD를 구분할 수 없으니 당신은 틀렸소! 하시는 분들을 위해 예를 들자면, TH는 HEADER, TD는 웹사이트를 대표하는 정보… 이런 식으로 해석해 주시면 무리는 없을 듯 합니다.

어쨌거나 웹표준 정신에 어긋나므로 말도 안된다! 고 하시는 분들에게, 이번에는 CSS레이아웃에 대해 좀 이야기를 할까 합니다.
그림을 그려보면…

대충 이런 구조의 “블로그”가 있습니다.

어떻게 코딩해야 웹표준일까요?
일단, DIV가 4개 필요하겠군요. ID는 직관적으로 HEADER, MENU, CONTENTS, FOOTER로 해 둡시다. 그 다음, CONTENTS안에 각각 CONTENTS1, CONTENTS2, CONTENTS3의 DIV를 지정해 주면, 나머지 요소는 CLASS를 지정해 두고 CSS를 지정해 주면 크게 웹표준에 벗어나지 않은 코딩이라고 생각합니다. MENU는 항목의 나열이니까 UL마크업이 제일 어울리겠지요.

제 답변에 대해 어떻게 생각하십니까?

만약 옳소! 라고 지체없이 대답하신다면, 웹표준에 대해 열심히 공부하신 분이 틀림없으실겁니다. 하지만, 한 단계에서라도 왜? 라고 생각하셨다면 이 분은 웹표준을 알고 계실 가능성이 있습니다.

제 의문은 매우 원초적인데서 시작합니다.

“왜 DIV인가?”

“왜 DIV이지?”

“왜 DIV인거야?”

“HEADER는 이미지와 텍스트로 구성된 소개문에 불과하잖아?
MENU는 처음부터 UL로 시작해도 되쟎아? 왜 DIV지?
CONTENTS1, 2, 3는 각각의 날짜 또는 주제로 구분된 문단이 아냐? 왜 DIV로 구분해야 하는데? 또, 이들의 부모요소인 CONTENTS는 왜 DIV냐고? 순서대로 나열된 항목을 나타내는데, 왜 UL요소로 시작하지 않는거냐고?”

“의미없는 DIV가 이렇게나 많이 사용되었는데, 이것이 어떻게 웹표준이 될 수 있는거지?”

“DIV로 레이아웃을 결정할 수가 있어서? 무슨 소리야? CSS레이아웃이라며? CSS로 레이아웃을 잡을 수 있는데. 블록요소를 인라인요소로 바꾸고, 인라인요소를 블록요소로 바꾸는 것도 전부 CSS가 하는 세상인데, 왜 태그로 레이아웃을 결정하려고 하는거야? 테이블 레이아웃을 시대에 뒤떨어진 레이아웃이라고 하는 이유가 뭐였어? HTML태그에서 레이아웃을 결정해서 시대에 뒤떨어진 레이아웃이라고 했던 것 아니었어?”

꽤 오래전에 포스팅해 두었지만, 저는 언젠가 테이블 레이아웃이 웹표준이 되는 시대가 와도 전혀 이상하지 않다고 썼습니다. 첨부로 붙인 말은 테이블 레이아웃이 웹표준이 되는 시대가 온다고 해서 지금까지의 테이블 레이아웃 방식이 그대로 쓰일 가능성은 제로라고 해 두었지만요.

웹표준이 순수한 의미의 이상적인 웹표준, 시맨틱 웹이 되려면, HTML코드 안에서 순수한 정보가 차지하는 비중이 극단적으로 높아야 합니다. 지금의 웹퍼블리셔들이 ID명과 CLASS명을 짓는데 그리도 고심하는 것은, 바로 그것들조차도 순수한 정보로서 가치를 가지게 하려 함이지요.

감히 제가 바라본 진화된 웹표준은, DIV의 한계를 넘어줘야 하지 않을까 하는 생각입니다.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

그렇습니다. DIV홀릭이라고밖에 말할 수 없습니다. 최근의 웹사이트들은 DIV가 몇개 들어가 있는지로 웹사이트의 수준을 측정하는 듯 합니다. 사이트의 외관은 아직 CSS-ZEN이나 CSS MANIA의 여러 작품들과는 동떨어집니다. 뭐 좋습니다. 저도 90년대 미술학원 구성 작품 보는 듯한 소위 웹2.0방식의, CSS 사이트는 별로라고 생각하니까요.

테이블이 제 자리를 찾아가고, DHTML의 요소 중 하나이던 DIV가 레이아웃 결정에 적합한 코드로 인식됨에 따라 큰 변화가 일어났습니다. <table>이 <div>로 바뀌기 시작한 것입니다. 하지만 그것 뿐이었습니다. W3C의 문법 체크 검사기도 이 행위를 묵과했습니다. 문법만 체크해 버린 결과, 전혀 모범적이지 않은 사이트들에 W3C의 인증마크가 붙기 시작했고, 생각의 역사가 테이블 시대를 벗어나지 못한 웹디자이너들에 의해 웹사이트는 DIV로 물들기 시작했습니다. ID와 CLASS에 이름을 붙여본 적도 없는 사람들이 CSS를 이용하면서 문서의 구조는 더욱 엉망이 되어갔습니다.

DIV는 블록 레벨의 레이아웃을 결정하는 마크업입니다. 단지, 그 뿐입니다. 리스트에는 리스트를 위한, 표에는 표를 위한 마크업을 하지 않으면 안됩니다.

다행히 얼마 전, 이 문제를 날카롭게 지적한 포스팅이 있어, DIV홀릭의 치료법은 그 포스팅으로 링크를 하고, 여기서는 좀 더 발전하여, 다른 문제점들을 살펴보기로 하겠습니다. 문제점을 살펴보기만 하면, 너무나 평범한 글이 될 것이고, 저 또한 생각을 해 보고 싶기 때문에, 저 나름대로 해결책을 달아보았습니다. 다른 의견을 가지고 있으시다면 댓글로 의견을 부탁드리겠습니다.

1.       H1, H2요소가 없다.

제가 블로그를 맨 처음 시작하면서 부터 줄기차게 주장해온 부분이지만, 아직도 많은 사이트에서 건너뛰는 부분 중의 하나입니다. H1요소는 책의 제목입니다. 웹브라우저의 타이틀바에 사이트 이름 뜬다고 끝난것이 아니지요. 제목이 존재하지 않는 사이트에 구조가 존재할 턱이 없습니다. 글의 주제를 묶어 나가는 태그들이 실종되어 있으니, 그 웹사이트에 실린 정보는 단지 보기 좋게 진열된 듯 보일 뿐, 소스 열어보면 태그 안에 무더기로 쌓인 정리 안된 정보들에 불과합니다.

-          해결책 : 일단 H1요소를 무엇으로 지정하느냐 하는 원초적인 기준부터 정하지 않으면 안됩니다. H1요소가 사이트 전체를 대표하느냐, 현재 사이트를 대표하느냐로 생각해 볼 수 있겠지요. H1요소가 사이트 전체를 대표한다면 당연히 로고 또는 웹사이트명의 조합 정도가 될 수 있겠고, 현재 사이트를 대표한다면 해당 사이트의 제목 또는 주제가 되겠지요. 이 경우 로고 또는 웹사이트명은 DIV요소, 링크가 걸린 경우는 블록화된 A태그로 표현해도 무리가 없겠지요.
많은 웹퍼블리셔들이 H1요소를 지정하지 않는 이유중 하나로 생각되는 것이 그 거대한 글자가 사이트와 어지간히도 안어울리기 때문이라고 생각됩니다. 특히, 웹퍼블리셔의 역할을 겸비하고 있는 웹디자이너들의 경우, 예술적인 기준에서 외관을 심히 해치는 통짜 텍스트로는 세련된 외관을 고객에게 약속드리기 매우 힘들 것입니다. 이 경우는 text-indent등을 사용해서 의도적으로 텍스트를 외곽으로 빼는 방법을 사용할 수 있습니다. 저같은 경우는 over-flow와의 조합을 사용하기도 합니다만 개인차가 있는 것 같습니다.

2.       이미지에 ALT태그를 빈 속성으로 적용해 둔다.

여기서 이미지란 IMG태그만이 아니라, MAP 등 이미지를 배경 등 장식적인 목적이 아닌 컨텐츠로서 활용하는 요소들을 말합니다.

조금 생소하시지요? ALT태그만 적어두면 된다고 그러던데… 웹표준 교과서를 보아도, 2005년도에 나온 웹표준가이드를 봐도, 이미지에 ALT만 넣으면 된다던데…

ALT속성은 Alternative, 다시말해 “대체 기능”을 가진 요소입니다. 이미지가 안보일 경우 ”이 자리에는 원래 무슨무슨 기능을 하는 이미지가 들어갑니다”라고 알려주기 위한 기능에 지나지 않습니다. 만약, 이미지가 컨텐츠로서의 의미를 가지고 있지 않다면? ALT를 채워넣긴 넣었는데, 이 이미지가 없어도 문서를 이해하는데 전혀 불편함이 없다면? 코드 낭비지요.

-          해결책 : 이미지에 ALT속성을 지정하는 것을 필수로 해둔 것은 제 생각으로는 이제까지의 웹의 행보를 바꾸었다고 할 정도로 의미있는 일이라고 생각합니다. 단, ALT요소를 빈 속성값을 넣어가면서까지 무리하게 넣어서는 안되지요. 그럴 경우라면 당연히 CSS에서 배경으로 적용해서 사용해야 합니다.

3.       이미지는 전부 배경으로 지정해서 써야한다.

페이지를 위에서부터 아래로 쓱- 드래그를 해 내려오면 텍스트만 걸리는 사이트가 있습니다. 순간 가슴이 답답해집니다. 아… 분명 저 그림은 컨텐츠일텐데 왜 배경으로 깔려있는 것일까… 저거 배경으로 깔고나서 발은 뻗고 잤을까…

-          해결책 : 의미에 맞는 코딩을 하다보면, 의미를 가지고 있지 않다고 생각되거나 너무 많이 가지고 있다고 생각되는 것들은 그 처리방법에 대해 너무 깊게 생각하게 됩니다. 코드가 가진 본연의 기능에만 충실하면, 왜 그 자리에 그 코드를 사용했는지 설명이 가능하다면 그것으로 충분합니다. 컨텐츠라면 텍스트, 이미지 구분없이 웹사이트에 정보의 형태로 존재해야합니다. 만약 정보를 가지고 있지 않은 컨텐츠라면 장식 요소로서의 기능을 담당할 수 있도록 배치해야겠지요.

4.       DOCTYPE선언에 XHTML을 고집한다.

XHTML의 리퍼런스가 10장 내외라는 사실은 잘 알려진 사실입니다. 그렇기 때문에, 배우기 쉬운 것으로 오해할 수 있지만, 사실 대부분의 기본적인 기능은 HTML에, 핵심적인 기능은 XML에 가려져 있기 때문에, 일반적인 HTML코딩과 별 차이 없는 코딩이라던지, XML을 정통하지 않고는 XHTML의 참 맛을 알기 어렵습니다. 하지만, 전혀 XML의 기능과 관계없는 사이트에서도 종종 XHTML을 선언하여 사용하는 경우가 많습니다. 물론, HTML을 쓰던지, XHTML을 쓰던지 누가 간섭할 바도 아니고, HTML을 쓴다고 XML과는 남남이 되는 것도 아니지만, 기능적으로 충분히 HTML로 표현할 수 있는 사이트라면, 무리하게 XHTML을 사용하지 않아도 충분히 멋진 사이트를 만들 수 있습니다.

-          해결책 : XHTML을 사용하지 않은 웹에서 제일 안전한 외관을 보장해 주는 것은 HTML 4.01 Strict입니다. 그 이유는, 웹브라우저에 따라 다르게 해석할 가능성이 있는 문법 또는 표현을 절대 용서하지 않기 때문이죠. 또 미래에 탄생할 웹브라우저에서 오작동이 발생할 확률도 Transitional에 비해 적습니다. 역으로, 많은 웹브라우저에서 그나마 통일된 외형을 보장합니다. 많은 웹디자이너들이 오해하는 것 중의 하나가, XHTML=DIV Layout, HTML=Table Layout인데요, DIV도 당당히 HTML의 태그입니다.

5.       CSS를 걷어낸 상태의 외관에 신경을 쓴다.

CSS레이아웃이 대중화되면서, 과연 문서가 구조적으로 잘 짜여져 있는지 알아보는 방법으로, 역으로 CSS를 걷어낸 상태를 평가하는 방법이 있습니다. 그러다보니, 예술이라면 둘째가라면 서러워하는 웹디자이너분들은 다른 쪽으로 생각하게 됩니다. CSS가 걷어진 상태에서 보니, H1요소가 너무 크더라는 것이지요. 리스트라고 태그는 알맞게 적어뒀는데, 왼쪽에 붙는 검은 점이 너무 촌스럽더라는 겁니다. 마음에 드는 것은 모서리가 동그랗게 말린 Legend태그 뿐입니다. 결국 H1요소는 H4요소로 적당하게 강등당하고, UL, LI태그 대신에 SPAN태그 써줍니다. P태그 대신에 Legend요소로 감싸주니 CSS를 걷어내도 한편의 수채화처럼 마음에 감동을 가져다 줍니다.

-          해결책 : 절대! CSS를 걷어낸 상태의 디자인에 신경쓰지 마십시오. 그것은 디자인이 아닌 문서의 구조, 시스템입니다. 뼈만 줄줄이 나열되어 있을 뿐인데 멋이 없는 것은 당연합니다. 머리뼈가 크다고 그 자리에 손가락뼈를 가져다 놓을수는 없지 않습니까? 아무리 살을 잘 붙여놔도, 손가락뼈로 이루어진 머리에는 눈코입이 들어갈 수 없습니다. 대신, 머리뼈 바로 밑에 다리뼈가 오고, 그 다음 갈비뼈가 올 수는 없겠지요. 무슨말인가 하면, 최소한 Header - Menu - Contents – Footer 의 순서는 지켜주어야 한다는 겁니다.

6.       무리하게 용량을 줄이려고 한다.

예전 N사의 사이트 개편에 대한 포스팅을 하면서 매우 신경쓰였던 것이, 지금도 고쳐지고 있지 않은 이미지맵을 사용한 네비게이션입니다. 그 문제에 대한 가능성으로, 어떤 분이 달아주신 답글에 의하면, HTTPRequest(서버 호출)을 줄이기 위해 의도적으로 그랬을 수도 있다라는 의견이 있었습니다. 한마디로, 이미지 5개 읽을 호출 대신 한번만 읽어서 서버 호출을 줄일 수 있다라는 의견이었는데요, 그렇게 서버 호출이 신경쓰이신다면 플래시광고를 하나 빼시던지요. 웹 사용자들이 원하는 것은 자신의 컴퓨터가 서버호출을 적게 하는 것이 아니고, 알맞은 방법으로 네비게이션을 제공받는 것입니다. 그렇게 이미지 호출하는게 신경이 쓰이신다면, 웹페이지 자체를 통짜 이미지로 찍어내고, 이미지맵으로 도배를 하는건 어떠신가요?

-          웹퍼블리셔라는 직종은 특별히 여러가지를 생각해야 합니다. 문서의 구조, 의미있는 태그, CSS, 게다가 웹사이트의 용량… 특히 웹사이트의 용량이라는 것이, 웹퍼블리셔의 능력을 보여주는 또 하나의 척도로 등장함과 더불어, 말도 안되는 다이어트법(예를 들어 태그간 공백을 전부 없애서 1줄짜리 웹사이트를 완성한다던지)을 당당히 소개한 책도 등장했을 정도이니까요. (HTML태그 안의 경우, 1줄로 축소하는 것이 웹사이트의 억세스 속도를 높인다고 인정이 된 상태이고, 회사에 따라 내부에서 웹사이트를 편집할 때에는 줄바꾸기나 들여쓰기를 꼬박꼬박하고, 서버에 올릴때만 에디터를 사용해서 공백을 전부 지우는 경우도 있다고는 합니다.) 하지만, 속성값을 둘러싸는 쌍따옴표를 다 뗀다면 필수 영양소 결핍이 되겠지요. 그리고, 조금 높은 수준으로 올라가면, ID명이나 CLASS명을 알파벳 두세자로 암호처럼 지정해놓고 용량을 줄였다고 하시는 분들도 있는데, 용량은 확실히 줄었습니다. 그런데, 그거 유지보수할 때 시간 낭비하실것같지는 않으신지요?
건강하게 용량을 줄일 가능성이 있는 것으로, 일단 색지정을 들 수 있습니다. #ffffff보다, white라고 지정을 하는 것이 바이트 수가 주는군요. 좀 더 노력하면 #fff로 끝나네요.  이거가지고 얼마나 줄겠냐고요? 웹사이트에서 색지정 한번만 하고 끝나나요? 하나는 우습지만, 여러개 뭉치면 무시못할겁니다. 또, ID명과 CLASS명에 과도하게 –(하이픈)또는 _(언더바)를 집어넣는 경우도 절약의 여지가 있군요. bg_main_content_2 대신bgMainContent2는 어떠신가요? 또, 코드내에 불필요한 스페이스나 줄바꿈이 들어간 경우도 유념해서 살펴봅시다. 정작 제일 낭비가 되는 부분이 이런 부분들이니까요. 생각하자면, 웹사이트에, 빈틈이 한두군데이겠습니까...

7.       디자인상의 이유로 사이트상의 영어 문장은 전부 대문자로 작성한다.

영어에 약한 저를 포함한 많은 분들을 위해 그나마 글자를 쉽게 알아볼 수 있는 대문자로 표시해줍니다. 아… 정말 접근성 하나는 멋지구나… 하고 생각하려는 찰나, 혹시, 이 문서를 음성 브라우저로 읽는다면? 음성 브라우저는 대문자를 하나씩 끊어 읽습니다. SITE라고 입력하면 에스아이티이라고 읽어준다는 것이지요. site라고 적어야 사이트라는 발음을 들려줍니다. 그럼, 여태만든 웹사이트 전부 소문자로 바꿔야 하나요?

-          해결책 : 문장으로 읽히게 하고 싶다면 일단은 소문자로 적습니다. 약자(이니셜)나 한 문자씩 따로 읽히게 하고 싶다면 대문자로 써주면 되겠지요. 그 다음은 CSS에 맡깁니다. 모두 대문자로 표현하고 싶다면 text-transform: uppercase , 제대로 된 문장처럼 맨 처음 문자만 대문자로 표시되게 하고 싶다면? First-letter? 가 아니고… text-transform: capitalize;가 되겠지요.

요즘 쓰긴 써야겠는데 껀수는 없고, 내용없기로 소문난 대표적 낚시글인 "XX사이트 분석" 이런 글이나 쓰다가 간만에 제 색깔에 맞는 글을 써서 개인적으로 기분이 좋습니다. 정치글이나 시사글도 적고는 싶은데, 일단 웹표준 전문 블로거로 성장하고 싶은 욕심도 있고, 시류에 휩쓸리는 글을 적으면 블로그가 색깔을 잃는 것은 시간문제라는 개인적인 모토에 의해, 업데이트가 그리 활발하지 못했습니다.

 
그리고 글 쓰는 속도도 어지간히 느리다보니, 어설프게 썼다가는 데미지100의 댓글들이 달리는 블로그 세상에서 살아남기 위해, 모든 글들을 일일이 증거를 찾아보고, 못하는 영어 원서 봐가며, 쓰다보니 많게는 1,2개월 걸려야 빛을 보는 포스팅이 대부분입니다. 느린 업데이트 변명입니다만 그런 뜻에서 죄송하게 생각하고요.

곧 포스팅되는 이어지는 글도 재미있게 읽어주세요!

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

웹표준이라는 단어가 처음 나왔을 때, 웹표준이 무엇인지 대해서 많은분들이 의견을 나누셨습니다. 모든 브라우저에서 똑같이 보일 수 있는 표준이다, 파이어폭스와 오페라에서 제대로 보여야 웹표준이다, XHTML로 코딩을 해야 웹표준이다... 참 많은 의견이 오고갔던 것으로 기억합니다.

이제 어느 정도 정리된 의견이라면, 웹표준은 간단하게 말하면 Semantic적으로 만들어진 홈페이지를 뜻하는 말이 되었습니다. (바로 이 점이 제가 네이버 메인페이지를 웹표준적이지 않다고 말하는 근거입니다.)

한가지 문제가 있다면, 아직 웹표준이라는 것이 권고 상태라는 것이죠. 강제 상태가 아니라는 말입니다. 구글식으로 표현하면 베타판이라는 말입니다. 아직 많은 사람들이 웹표준에 대한 토론을 계속하고 있습니다.

웹표준은 아직 정해지지도 않았다는 말이지요!

이런 의미에서 접근하면, 파이어폭스나 오페라 또한 웹표준을 지키는 브라우저가 아닙니다. 현재까지 발표된 웹표준 권고안에 가장 접근한 출력결과를 보장하는 브라우저라는 표현이 맞습니다.

역으로, 인터넷 익스플로러는 웹표준을 지키지 않는 브라우저가 아닙니다. 이 말은 웹표준의 의미를 생각하시면 쉽게 이해가 되실 줄 믿습니다.

인터넷 익스플로러도 웹표준에 맞게 Semantic으로 코딩해주면 논리적으로 브라우저에 나타내줍니다. 인터넷 익스플로러가 웹표준을 지키지 않은 브라우저라면, CSS를 끄고 문서의 구조를 살펴보았을 때, 태그의 성격이 무시되어 출력되거나 (예 : H1요소와 H3요소의 글자 크기가 같다던지) 인라인 요소와 블록 요소가 혼재되어 나타나는 (예 : p요소로 묶인 문단이 각각 한줄의 공백으로 구분되지 않는다던지) 현상이 발생해야겠지요. 현실은 그렇지 않습니다. 파이어폭스, 오페라 등등, 웹표준의 필수 브라우저로 추앙받는 것들과 똑같은 결과를 나타냅니다.

많은 웹디자이너, 웹퍼블리셔들이 인터넷 익스플로러가 웹표준을 지키지 않는 근거로서 레이아웃이 깨지는 문제를 드는데, 웹표준 코딩 - HTML과 XHTML을 사용한 코딩 - 에서 레이아웃을 결정하는 유일한 방법은 CSS입니다. 이 CSS의 표현방법이 잘못된 것과, 그렇기 때문에 인터넷 익스플로러가 웹표준을 지키지 않았다는 것은 동문서답입니다. 차라리 인터넷 익스플로러때문에 크로스브라우징이 어렵게 되었다는 주장은 납득이 가는군요.

웹디자이너는, 웹퍼블리셔는, 웹표준을 따른다고 마음먹으셨다면, 그 순간부터 인터넷 익스플로러를 욕하면 안됩니다. 인터넷 익스플로러 때문에 웹디자인을 못하시겠다는 말은 더더욱 하시면 안됩니다. 어떤 브라우저에서도 잘 나타낼 수 있게, 하물며 그것이 저주받은 익스플로러라하더라도 외면해서는 안됩니다. 그것이 유일한 방법이라면, 핵을 사용해도 좋습니다.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

 

퀴즈 하나 내드리겠습니다. "웹 표준은 [ ] 를 차별하지 않습니다."라는 문장의 [ ] 안에 들어갈 수 없는 것은 무엇일까요?

힌트를 드리면, 특별히 대한민국의 웹 표준은 이것을 너무 차별하고 있습니다. 차별의 정도가 지나쳐 적대적이기까지 합니다.

정답 : 인터넷 익스플로러

정답을 맞추신 분이 혹시 계신지요?

웹표준에 대해 올라온 글 중에서 인터넷 익스플로러에 좋은 시선을 보내는 글이 단 하나도 없다고 하면 과언일까요?

물론 그 동안 웹관계자분들(특히 웹디자이너)께서 겪으신 고충을 생각하면 인터넷 익스플로러는 그 출생부터 저주받아 싼 존재입니다.

하지만, 웹표준이 추구하는 정신은 그러한 못난 인터넷익스플로러를 말살시키는 것이 아닙니다.

웹표준은 "어느 브라우저에서 어떤 환경에 있는 사람들도 인터넷 서비스를 사용할 수 있게 하는 것"인데, 왜 인터넷 익스플로러만 "웹표준을 지키지 않은 브라우저"라는 이유만으로 미움을 받아야 하는지요?

인터넷 익스플로러는 웹표준을 지키지 않았기 때문에 디자인이 힘들고, 그렇기 때문에 파이어폭스나 오페라같은 웹표준을 잘 지키는 브라우저를 적극적으로 사용해서 브라우저 쉐어를 어느 정도는 공평하게 나누면, 마이크로소프트도 위기의식을 가져서 웹표준화가 제대로 된 브라우저를 내놓을 것이다 라는 것이 웹표준과 관련하여 제가 읽은 블로그의 내용의 대다수였습니다.

어쩌면 이런 잘못된 생각 때문에 웹표준 전도사들이 핍박을 당하는지도 모릅니다.

인터넷 익스플로러 시리즈들도 웹표준에 접근해나가고 있고, HTML5 안건에 마이크로소프트사의 임직원이 참가한 이 시점에서, 웹표준을 지키지 않았기 때문에 인터넷 익스플로러의 사용을 억제하자는 주장은 설득력을 얻기 힘듭니다. 오히려 마이크로소프트의 독과점에 대한 반발이 더 솔직한 표현이겠지요.

그리고, 익스플로러가 불량 브라우저라는 편견은 어쩌면 국내 웹관계자들이 스스로 만든 족쇄일수도 있습니다.

제작이 쉽다는 이유로 웬만한 플러그인은 인터넷 익스플로러에서만 돌아가는 액티브X로 때우고, 디자이너들이 만든 인터넷 익스플로러에 최적화된 테이블코딩에 맞춰 프로그래머들도 TR TD 사냥에 동참하는 사이클이 계속되어온 것 아닙니까? 그 당시 기준으로 보면 인터넷 익스플로러야말로 개발하기 쉽고 디자인하기 쉬운 세계 최고의 브라우저가 아니었던지요?

기억하세요. 아직 인터넷 익스플로러는 전세계 5명중 4명이 사용하는 브라우저입니다.

그럼, 정말로 인터넷 익스플로러는 웹표준을 지키지 않는 브라우저일까요?

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

우선 여기서 밝힐 것은, 저는 웹기획자가 아니고, 순전히 웹디자이너이고 웹서핑을 좋아하는 블로거일뿐입니다. 그러니, 저의 포스팅에 영향을 받지 마시고 한번 읽으신 후 일상생활로 돌아가시면 좋겠습니다.

저는 2007년은 이러한 서비스들의 결과가 나오는 시간이라고 생각합니다. 네이버마저 CSS레이아웃으로 큰 변혁을 마치고(웹표준에 맞추었다는 말은 도저히 나오지 않네요) 스마트에디터를 이용한 여러 서비스로 정면승부를 예고한 이상, 올해 하반기와 내년초의 반응으로 내년의 전개 방향을 결정할 가능성이 큽니다. 흥미있는 것은 포토서비스와 동영상서비스 등 역사가 그리 길지 않으면서도 색깔을 가진 서비스를 출시한 것인데, 내년 상반기의 평가에 의해 이러한 서비스들이 제색깔을 버리고 스마트에디터를 사용해 색깔을 갖추는 서비스로 변모할 가능성도 있습니다. 스마트 에디터는 제 생각으로는 단지 글쓰는 기능만으로 끝나기엔 아까운 툴입니다. 내년 상반기를 넘길 가능성은 그리 많지 않습니다. 업계의 변화속도가 지금보다 더 빨리질테니까요.

또한 다음도 베타로 제공중인 웹인사이드, 애드클릭스, 오픈아이디 등의 결과가 슬슬 나올 때입니다. 하지만 다음의 경우는 네이버만큼 부담이 크진 않습니다. 이미 중요 섹션에서 웹표준을 달성했고, 많은 스텝들이 웹표준에 익숙해져있는 만큼 그에 따라 후속 사업들의 전개 개념이 상당히 유연해져 있을테니까요. 그리고 다음의 경우는 사업전개를 예측하기 어려운 것이, 네이버의 경우는 다음의 사업을 벤치마크한다는 느낌이 상당히 강한데, 다음의 경우는 오리지날에 가까운 사업을 전개하는 경우가 많다는 것입니다. 다만, 전세계적인 트렌드에 상당히 민감하게 반응하는 느낌이 강한데, 이번에 구글이 한 연구기관에 의해 평가 절하당한 충격이라던지, 야후의 위상이 서서히 원점으로 돌아오는 이 시점에서 다음이 다른 노선을 걸을 가능성도 있습니다.

또한 엠파스를 인수한 SK의 행보도 주목할만합니다. 이미 네이트온 메신저와 싸이월드 미니홈피로 안정적인 사업을 펼치고 있는 SK가 엠파스를 인수하여 웹검색쪽으로 공격적인 사업을 전개할 가능성이 매우 큽니다. 제 생각으로는 예전의 파란처럼 어설픈 서비스를 전개하여 제살마저 깎아먹는 전철을 밟지 않기를 바라는 마음뿐이지만, 열린 검색 등 예전부터 쭉 파격적이고 어찌보면 공격적이었던 엠파스의 전개 방향과 그리 크게 다를것같지는 않습니다. 아마 검색서비스만 강화하는 방향으로 나갈 것 같습니다.

2008년...

웹디자이너로서 주목할만한 것은 정식판이 출시되는 사파리에 대한 지원을 하느냐 않느냐인 것입니다. SK의 경우는 맥용 네이트온을 이미 발표하였고, 다음같은 경우는 우분투에 대해 지원을 하고 있는 관계로 이 두회사가 정책의 일관성이나 이미지 유지를 위해서라도 사파리 유저들을 껴안을 가능성은 매우 큽니다. 문제는 네이버인데, 네이버의 경우 지금까지의 경험으로 미루어볼 때 일단 내년은 사파리 유저들을 지원하지 않을듯 합니다. 내년말쯤 다음과 SK의 실적을 보고 판단을 내리겠지요.

또한 각 포탈을 중심으로 인력이동을 예상해볼 수 있습니다. 구글코리아의 한국지사 전개를 가볍게 평가하시는 분들이 있는데, 현재 IT인력들이 해외로 탈출하고 있는 이 상황에서, 각 포탈의 일부 핵심인력이 구글코리아를 비롯한 좀 더 나은 근무 환경을 제공하는 곳으로 이동하기 시작하면 그 충격은 적지 않을 것입니다.

사업의 전개에 대해서는 올해 전개되고 있는 사업을 중심으로 각 포탈이 색깔을 찾아나가는 작업이 한층 강하게 진행되리라는 예상입니다. 세계적인 트렌드를 파악해 나가는 다음과, 국내 사용자에 최적화된 서비스만을 엄선하여 전개하는 네이버, 이 양단에 끼어 전방위로 공격적인 사업을 전개하는 SK.

과연 내년의 포탈은 어떤 모습일까요?

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.