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 대한민국 라이선스에 따라 이용하실 수 있습니다.

이어, SEO와 시각장애인을 위한 접근성 대책에 대한 부분을 소개하겠습니다.

6. SEO에 최적화
메타태그의 입력방법, 헤드부분 처리는 물론, 본문의 각 요소에도 SEO처리를 해 놓았습니다. 이것도 Semantic으로 반은 먹고 들어갔습니다. 아픈 기억으로 입력방법이나 헤드처리요령 등은 설명하지 않겠습니다.

사실 검색엔진이라고 부르기엔 뭐한 네이버가 국내 검색시장을 대표하는 마당에선 제일 충실한 SEO대책은 네이버에 광고를 올리는 것이겠지만요.

7. 시각 장애인을 위한 접근성 대책
제가 사실 스크린 리더기를 사용할 기회가 없어서 이 부분은 확언을 못드리겠습니다. 하지만 웹에서 얻은 지식으로 accesskey 라던지 title의 사용을 최적화해 보았습니다. 시각장애자분들이라도 적어도 링크는 제대로 누르시지 않을까 생각합니다.

또 access단축키를 생각하면서도, 입으로 스틱을 물고 사용하시는 분들의 입장에서 어떤 키 배열이 좋을까 생각해보니, 단축키가 ALT키와 함께 쓰인다는 점에 착안해 스킨을 바꾸는 accesskey는 ALT와 가까운 곳에 있는 Z, X, C, V로 해보았습니다. 로고와 연결된 accesskey는 아마 대부분의 웹페이지가 단축키를 숫자 0이나 1로 설정해 놓지 않았을까 생각하여 익숙하신대로 쓰는게 제일 편하지 않을까 하는 마음에 1로 설정해 보았습니다. 저에게 메일을 보낼 수 있는 키는 7입니다. 행운의 7! (경험상 이래도 메일은 안오더라구요)

기획을 할 때 장애인용 키보드에 대한 자료를 찾아보았지만, 한국어로 된 자료가 많이 없었기에, 어쩔수 없이 일반 키보드를 기준으로 했습니다.

8. Semantic 구현
100% 완벽하다고는 할 수 없지만, 이전까지 제가 참고했던 어떤 웹페이지보다 더욱 Semantic에 가깝게 작업했습니다. id와 class가 의미를 가지도록 하는데 집중하였고, 이미지 파일의 이름도 용량의 범위 내에서 의미를 가지도록 신경을 써 보았습니다.

http://wis1674.dothome.co.kr/

이 사이트를 제작하면서 느낀 것이지만, 작업의 순서가 바뀌었습니다.

일단 XHTML코딩을 하고, 그 다음 디자인을 하였습니다.
이 순서의 변화가 무엇을 의미하는지 아시리라 믿습니다.

예전의 웹공정, 특히 테이블 레이아웃에서는 디자인이 나오고 나서야 코딩이 진행되었습니다. 물론 프로그래밍은 코딩이 끝난 뒤가 되니 웹제작에 시간이 걸리게 마련이었지요.

하지만, 코딩이 우선이 되면, 코딩과 디자인을 동시에 들어갈 수 있게 됩니다. 기획단계에서 레이아웃과 요소들을 결정하면, 그 다음은 퍼블리셔와 디자이너가 동시에 작업을 진행할 수 있다는 이야기가 되겠지요. 작업에 대한 패러다임까지 발전적으로 변화합니다.

다음 글부터는 XHTML제작과 CSS제작에 대해 간단히 적어보겠습니다.

읽으시느라 수고하셨습니다!!!

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

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

100% 만족하지는 않지만, 입으로만 떠드는 것을 탐탁치 않게 여기는 저이기에, 글은 이정도면 쓸만큼 써둔 것 같고, 실제로 웹표준에 입각한 사이트를 만들어보자고 해서 만든 것이 이 사이트입니다. 사이트에 명시는 해 두었지만, 절대 W3C의 밸리데이션 통과를 목적으로 만들지 않았습니다.

http://wis1674.dothome.co.kr/

일단 이 사이트 설계시의 기준 (기획이라고 하는 말이 어울리겠군요.)을 말씀드리겠습니다.

1. XHTML1.1 과 CSS 3.0기준에 맞추어 제작
실무에서는 에러방지를 위해 제일 유연성이 풍부한 HTML4.01 transitional을 쓰지만, 이 사이트는 목적 자체가 포트폴리오니만큼 제가 아는 한 "최신의 기술"을 사용하고 싶었습니다. 언제까지 최신의 기술일지는 모르겠지만... XHTML의 밸리데이션이야 분석기가 DTD를 자동으로 판별해 주니 알기 쉽지만, CSS 3.0? 지금 2.1도 안나와있는데 무슨? 하시는 분들을 위해 알려드리면, CSS 검증페이지에 가면 옵션으로 검증모드를 선택할 수 있게 되어있습니다. 여기서 원하는 검증 모드를 선택하시면 선택된 모드로 검증이 됩니다.

XHTML의 경우는 ol, ul, blockquote, fieldset, table 등등 고루 사용했습니다. Semantic에 신경쓰다보니 당연히 그렇게 되더라구요.

또한 CSS도 그냥 대충 요소를 집어넣지 않고, 모질라에서 권장하는 순서대로 적어 넣었습니다. Naver UI 팀 지침 참고 퍼포먼스에 차이가 있는지 어떤지는 모르겠지만, 있다고 해도 과연 느껴질 수준인지는 모르겠지만, 설마 순서가 괜히 있는것은 아니겠지 싶어서 말이지요.

2. UTF-8 사용
제가 외국에 살고 있어서인지는 몰라도, 여러 외국어를 한꺼번에 쓸 경우가 종종 있습니다. 영어도 되지않을뿐더러, 행여 외국의 웹에 들어가보아도, 한글을 쓸 수가 없어서 영어로 적을수 밖에 없었던 아픈 기억을 되살리면서 작업했습니다. 결정적인 이유 중의 하나는, 제가 쓰는 드림위버8이 일본어판이기 때문에 한글이 깨져서 보입니다. 그래서 utf-8모드가 아니면 한글이 제대로 나오지 않았던 이유도 있습니다.

3. 자바스크립트를 이용하여 페이지를 갱신하지 않고 외부CSS 교환
CSS를 교환하는 사이트가 꽤 되는걸로 알고 있습니다. 대표적으로 zengarden이 있지요. 하지만 CSS를 교환하기 위해서는 페이지를 갱신해야 했습니다. 이 부분을 자바스크립트를 사용하여 갱신없이 파일을 교환하도록 했습니다. "아! AJAX틱하다"하고 멋대로 생각해 버렸습니다만...
참고로 이 자바스크립트는 순수한 저의 작품은 아닙니다.

4. 1999년 9월 26일 이후 발표된 모든 브라우저에서 동일한 외관을 보장
저 날짜의 근거는 인터넷 익스플로러 5.0 버전이 네이버 자료실에 올라간 날짜를 기준으로 한 것입니다. 참고로 제가 크로스브라우징에 사용한 브라우저는

Internet Explorer 5
Internet Explorer 5.5
Internet Explorer 6
Internet Explorer 7
Firefox 2
Opera 9
Safari Beta 3 for Windows
Netscape 8
Netscape 9
Avant
Flock

이렇게 되겠습니다.
AVANT와 FLOCK이 생소하신 분들도 있으시겠지만, AVANT는 IE의 렌더링 엔진을, FLOCK은 Firefox의 렌더링 엔진을 각각 사용하고 있습니다.

이렇게 다양한 브라우저에서 테스트를 하다보니 CSS Hack이 조금 들어갔습니다. 하지만 그에 대한 주석은 생략했습니다. 일하면서 안좋은 기억이 있어서...

5. Clear Font 사용
구글 스킨(기본 스킨)을 제외한 모든 스킨은 Cleartype Font 를 사용했습니다.

한글 : 맑은 고딕체
일본어 : 명료체
영어 : Segoe UI

이유는 단지 개인적으로 예쁘게 보이기 때문에. 그리고 앞으로 비스타가 널리 보급되면 그만큼 클리어타입이 친숙하게 될텐데, 그 때를 대비해서 분위기를 미리 파악해보는 것도 좋지 않나 하는 생각에서 입니다.

다음 글에서 계속...

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

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

세월도 조금 지난 듯, 웹표준을 지켜야 된다는 글들도 이젠 어렵지 않게 보이고, 어떻게 하면 웹표준을 지킬수 있는지에 대한 글도 꽤 많이 보입니다. 웹표준이라는 단어가 이제는 개념적인 차원에 머물지 않고 실용적으로 다가오고 있음을 실감할 수 있습니다.

그렇습니다. web2.0처럼 개념적으로도, 수익모델적인 측면에서도 추상적인 의미에 머무르는 단어가 있는 반면, 웹표준은 실제 사업모델에서 고급이면서도 경제적인 웹 퍼포먼스를 보여주기 위한 도구로서 적극적으로 사용되고 있다는 뜻이겠지요.

하지만, 실제 웹표준을 표방하고 있는 사이트를 살펴보면, 사실은 HTML 또는 XHTML과 CSS만을 사용한 사이트가 대부분이라는 사실에 조금 실망하게 됩니다. (게다가 이런 사이트들은 W3C의 밸리데이션 통과마크를 꼭 걸어놓습니다. 아마 그것이 의무사항이라고 생각하고 있는지도 모르겠지만, 이부분은 W3C의 홍보부족이 아닌가 싶네요. 역으로 과다홍보일수도 있죠. 어쨌든.)

물론 XHTML과 CSS를 사용했다는 사실만으로도 매우 장족의 발전이고, 이러한 코딩이 익숙해질수록 웹표준에 상당히 가깝게 다가간다는 사실은 부정할 수 없습니다. 하지만, 매일매일 쏟아지고 있는 웹표준과 관계된 웹문서나 서점에 진열된 책의 수준과 비교해보면, 역시 아직은 웹표준이 개념적인 측면에 머물고 있지는 않은가 생각하게 됩니다.

일단 웹표준은 Semantic에 입각해야합니다. 밸리데이션 따위, 부차적인 목적이 되어도 좋습니다. 접근성도 일단 접어둡시다. Semantic만 해결하신다면, 모두 거저 얻으실 수 있습니다.
 
Hn요소가 순서대로 들어가 있는지, 사이트맵을 나타내는 웹페이지의 이름은 sitemap.html인지, 그 사이트에 링크가 걸린 이미지 버튼의 이름은 sitemap.gif인지, 각 div의 id명은 의미를 가지고 있는지, 다 생각하면서 해야합니다.

로고에 H1요소를 쓰는 것은 알고 있지만 글자를 넣어버리면 처리가 불가능해지기 때문에 글자대신 이미지를 넣어버린다던지 아예 H1요소를 빼버린 (정말... 눈물이 날 지경입니다.) 사이트, 사이트맵의 이름은 꼭 gnb05.gif 또는 top-btn05.gif인 사이트, div의 id나 class명은 어김없이 숫자나 알파벳을 순서대로 나열한 사이트...

단지 XHTML밸리데이션 통과가 목적이라면, 공부는 충분합니다. 밸리데이션 통과 마크를 얻으셨지 않습니까?

웹표준이란, 기초적인 XHTML 문법과 CSS 문법만 적어놓은 책에서는 절대로! 얻으실 수 없습니다.

또한, 웹표준과 함께 부가적으로 얻을 수 있는 여러 장점, 특히 웹접근성과 관련된 장점을 살리지 못한다는 것이 매우 유감이지요.

예를 들면 스크린 리더에서 무리없이 읽어줄 수 있는 구조인가, 입에 전용 스틱을 물고 키보드를 치시는 장애인들도 단축키를 이용하여 마우스없이 메뉴를 선택할 수 있는 구조인가, 탭을 사용하여 순차적으로 데이터를 입력할 수 있는 구조인가... 웹표준이라는 주제에 대해 생각하기 이전에는 당연히 전문가의 손길이 닿지 않으면 안되었던 이런 부분들 조차, 웹표준에 입각한 코딩이라면 어느 정도는 대책이 가능하다는 것입니다.

물론 매우 기초적인 장벽도 있습니다. 크로스브라우징이 바로 그것인데요, 인터넷익스플로러 의존도가 높은 편인 우리나라에서는 아주 최근에 문제의 심각성을 인식하고 (비스타님 감사합니다) 대책을 세워나가는 분야입니다.

인터넷익스플로러만 믿고 여기까지 왔는데(정확히 말하면 인터넷 익스플로러 6 이 되겠지만) 파이어폭스나 오페라는 그렇다치고 인터넷익스플로러 7마저 형을 배반하는 바람에 익스플로러 6과 7이 무엇이 다른지도 모르는 불쌍한 소비자들만 인터넷 뱅킹을 못하게 되는 상황이 되어버린 것 아닙니까?

서론이 길었습니다만, 저조차도 이론만 늘어놓는 것은 아니다 싶어서 (사실은 다른 목적을 가지고) 사이트를 한번 만들어 보았습니다.

http://wis1674.dothome.co.kr

다음 글에서 설명을 올리겠습니다.

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

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