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

사용자가 어떤 위치에 있는지를 가르쳐 주는 링크 리스트(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 대한민국 라이선스에 따라 이용하실 수 있습니다.

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

오늘 네이버를 열어보았습니다.



뭔가 이상했습니다.

전보다 깔끔해 진 인터페이스만이라면 고개를 끄덕거리고 말았을텐데, 화면에 열리는 느낌이 뭔가 색다른 것입니다.

"혹시나?"하고 소스를 살펴보니...

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">

일단 전에 없던 DOCTYPE선언이 눈에 띕니다.

아직 담당자분이 간이 작으신 모양인지 DTD까지는 지정을 해주지 않으셨더군요.

그리고 그 다음부터 이어지는 DIV의 향연!

-0-....

물론, 몇줄 내리지 않아 반가운 TABLE들이 보이기 시작했습니다만...

이것만으로도 쉽지 않았을 변혁이었을텐데...

굵직굵직한 변화만 보자면, 검색창을 포함한 헤드부분이 div로 편집되어 있습니다.

전체적으로 깔끔해진 레이아웃도 다음처럼 구획별로 제대로 된 DIV구성으로 되어있습니다. '단지 선만 가늘게 하고 회색 테두리 두른게 아닐까' 우려했던 부분이 말끔히 풀렸습니다.

일하는 중이라, 눈에 띄는 아쉬운 점 몇가지만 말씀드리면...

1. 검색창 윗부분의 링크(메일, 카페, 블로그, 지식iN, 쇼핑)이 이미지맵으로 처리되어 있는데... 시간이 촉박하셨는지, 아니면 이번 개혁에서 중요도가 낮았는지는 모르겠으나, 이번 변혁에 어울리지 않는다는 점은 확실하네요.

2. 더구나 어느 부분은 DIV으로 처리되어있고, 어느 부분은 DIV로도, 테이블로도 싸여있지 않고 덩그러니 나와있는 부분이 눈에 띄는데, 실수라기엔 좀 치명적입니다. 물론 include되어있는 부분을 고치면 되니 기존 방식의 유지보수는 문제없을뿐더러, 전체적인 움직임 상 곧 수정되리라 믿습니다.

3. 스크린샷에서 확인하실수 있습니다만 플래시 오브젝트가 보이지 않습니다. (물론, 이 글을 보시는 독자분들의 브라우저에서는 제대로 보이실 수 있습니다.) 이 경우는 플래시를 둘러싼 태그를 다른 태그로 바꿔보시는 것도 좋은 해결책이겠지요. DIV레이아웃을 적용할 경우에만 발생하는 여러 상황에 대해 아직 경험이 필요한 듯 합니다.

4. h1, h2 요소 지정안하기는 유행인가요. --;

5. 절약이 가능한 마크업이 꽤 보입니다... HTML자체의 마크업만이 아니고, 저 마크업들을 위해 CSS에서도 불필요한 코드가 들어가 있겠지요...

그래도, 웹표준 준수라는 측면에서 다음과 비교되어 항상 마음이 편치 않았을 네이버의 작은 변신이라 재미있어졌습니다. 네이버도... 사내에 "웹표준 사업부"가 따로 있을 정도지요? 맘먹고 한번 변신하면 무서울거같은데...

다음의 Naked Day가 큰 자극이 되었음이 분명합니다!

잠깐, 변신 끝이라고요? --;

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

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

<이 카테고리의 글을 읽지 않으셔도 W3C의 검증 테스트는 통과하실 수 있으며, 웹표준에 부합하는 작품을 만드실 수 있음을 밝힙니다.>

W3C의 검증 테스트를 통과하기는 쉽습니다. "요령"이라는 것일까요.

대학교에 합격하기 위해 많은 사람들이 공부를 하지만, 대학교 안에서 자기 스스로 열심히 공부를 하여 학문의 수준을 높이는 사람들은 5%라고 하면 너무 심할까요...

하고 싶은 이야기는, W3C의 검증 테스트에 만족해서는 안된다는 것입니다.

한 예로, W3C의 검증 테스트는 h1요소가 없어도 통과할 수 있습니다.

이 얼마나 엄청난 오류입니까?

책에 제목이 없는데 출판이 된다니요?

이러한 생각을 염두에 둔다면, 웹표준이라는거, 사실 당연한 것을 말하고 있는 것입니다.

우선 저는 웹표준을 위해, 물리적 마크업의 제거라는 개념을 설명해 드리고 싶습니다.

물리적 마크업은 논리적 마크업에 반하는 개념으로, 문서의 구조와는 관계없이 문서의 물리적인 부분을 담당하는 마크업을 말합니다. 쉽게 말하면 장식적인 부분입니다.

물리적 마크업은 현재 웹표준에서는 비추천, 또는 CSS에 의한 설정으로 추천되고 있습니다. 하지만, 전세계 대부분의 코딩이 아직 물리적 마크업에서 자유롭지 못합니다. 습관화되어있기 때문이겠지요.

간단한 물리적 마크업부터 살펴볼까요?

강조

위의 단어는 어떻게 마크업하십니까?

<b>태그를 사용하시는 분도 있고, <strong>태그를 사용하시는 분도 있고, CSS에서 font-weight에서 조절하시는 분도 있으실겁니다. 웹표준적인 의미로 말하면, 문맥에서 의미적으로 중요한 의미를 가지는 단어라면 <strong>태그를 써주어야 합니다. 하지만, 단순히 굵은 글씨로 표현하고 싶은 경우라면 CSS에서 조절해 주시는 것이 정답이겠지요.

모두 아시듯 <b>, <i>, <u>, <s> 또는  <strike>속성은 모두 물리적 마크업 속성으로 비추천되는 코드들입니다. 각각의 코드는 이렇게 바꾸어 CSS에 적용해 봅시다.

<b>               font-weight : bold;

<i>                font-style : italic;

<u>                text-decoration : underline;

<s>, <strike>   text-decoration : line-through;

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

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

웹표준과 함께 주목받는 단어 중 하나가 웹접근성이라는 단어가 아닐까 싶습니다. 웹접근성이야 사실 웹이 태어난 그 옛날부터 존재해 왔을 것이고, 최근에 주목받는 의미로 생각하자면 "웹접근성 향상"이 더 정확한 표현이 되겠지요.

참고로 저도 뉴스그룹에 가입하여 많은 정보를 얻고 있는 한국 웹접근성의 기사를 인용하기는 했지만, 이는 한국 웹접근성 그룹의 본질을 왜곡할 의도는 전혀 없으며, 저 역시 웹접근성 향상을 위한 노력을 소홀히 해서는 안된다는 입장임을 강하게 밝힙니다.

한국 웹접근성 그룹(http://kwag.net/)의 정의를 빌리자면

웹 접근성은 장애인들도 웹을 사용할 수 있도록 하는 것입니다. ...(중략)... 웹에 접근하는 데 영향을 미치는 요인은 시각, 청각, 지각, 신체, 신경질환, 언어 장애와 같은 신체적 장애뿐 아니라, 고사양 하드웨어, 고비용 소프트웨어를 사용하지 못하는 사회 경제적 여건까지를 포함합니다. ...(중략)... 웹은 교육, 고용, 정부, 경제, 건강, 오락 등 삶의 여러 측면에서 더욱 중요한 수단이 되고 있습니다. 이 점이 바로 웹이 장애인에게 동일한 접근과 동일한 기회을 제공해야 하는 본질적인 이유입니다. 접근 가능한 웹은 장애인의 활발한 사회 참여를 가능하게 하기 때문입니다. ...(후략)...

웹에 접근하는데 대해 영향을 미치는 요소들에 대해 열거하고 있지만, 그 초점은 "장애인"에 맞춰져 있지 않나 하는 생각이 드는군요. 한국 웹접근성 그룹의 정의를 100% 반영한다면 웹접근성 향상을 위한 최소 조건중의 하나는 장애인(여러 자료를 볼 때 특히 시각장애인이라고 생각되어집니다.)의 웹 열람을 위한 특수한 기술을 익혀야한다는 것으로 오해되어질 위험도 있습니다.

하지만 저는 "사회 경제적 여건"에 글의 초점을 맞춰보고 싶습니다.

아직까지 윈도우즈 98과 그에 따른 기본 웹브라우저인 Internet Explorer5.X를 사용하고 있는 지방의 각급 학교만 생각해도, 웹접근성에 대한 방향은 구체적으로 세워질 수 있을 것 같습니다. 배제할수는 없지만, 웹접근성 향상의 큰 목표에는 장애인의 웹 열람 이외에도 의외로 가까운 곳에 있습니다.

관련정보를 제일 빠르게 파악할 수 있게 해 주는 것이 초창기 웹브라우저가 지향했던(또는 지향할 수 밖에 없었던) 텍스트의 의미있는 나열(Hn 태그들을 떠올려 주십시오)임을 생각하면, (혹시 '회원가입'이라고 생각하시는 분 계시진 않겠지요?)지금의 Semantic Web은 매우 이상적입니다. 특히, 정보 전달을 위해 구조적 의미를 찾아볼 수 없는 막대한 양의 Table태그들을 읽어들여야 했던 최근의 웹사이트들과는 진정한 의미의 웹접근성에서 그 수준을 달리합니다.

또한, 단순히 img 태그에 alt 태그를 넣어 두는 것 만으로 웹접근성 향상에 대한 대비를 끝마쳤다고 하는 안일한 생각을 비판합니다. 그렇다면, 사회경제적 여건 때문에 이미지를 다운로드하기 힘든 환경에 있는 사용자들은 웹사이트 디자이너들이 고맙게 집어넣어준 텍스트를 읽는 것 만으로 만족해야 하는걸까요? 똑같은 이미지(웹용이라면 JPEG, GIF형식)형식이라도 압축률이나 색상수에 의해, 똑같은 색상수라도 칼라의 배치에 의해(이 부분은 허락되는 기회에 자세히 설명하겠습니다) 이미지의 용량은 놀랄만큼 줄어듭니다. 최악의 상황에서 이미지를 볼 수 없는 사용자들에게 이미지를 보여주기 위해 노력하는 것이야말로 웹 접근성 향상을 위해 노력하는 것이 아닐런지요.

오히려 alt요소는 SEO적인 의미가 더 큽니다. alt로 입력되는 단어들의 대부분이 관련 이미지를 묘사하는 것이 아닌 이미지의 주제를 나타내는 단어가 압도적으로 많다는 것이 하나의 증거입니다. 만약 alt가 웹접근성 향상을 위한 수단으로 사용된다면, 당연히 alt요소는 이미지에 대한 구체적인 묘사를 포함하고 있어야 합니다.

매우 단편적으로 생각해 보았고, 그 와중에 (인용을 할 수 있는 정리되고 공신력있는 자료가 찾기 힘들었던 관계로) 한국 웹접근성 그룹의 글을 인용하였지만, 아직도 많은 논란이 있고, 기술의 발전에 의해 아직도 많은 방법들이 시도되고 있는 분야인 만큼, 웹 접근성 향상에 대해서는 아직 어떤 방법이 최고라고 말할 단계는 아닌 것 같습니다. 역시나 공부에 공부를 거듭해야 되겠지요...

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

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