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

다음의 컬러 구성은 그다지 아이덴티티가 없습니다. 다음의 역사를 알면 납득이 가실거라 믿습니다.

다음이 지금은 컨텐츠 중심으로 방향을 전개하고 있지만, 3년전만 해도 카테고리 중심의 전개였습니다. 지금의 다음 로고에 그 흔적이 고스란히 남아있지만, 한메일, 카페, 쇼핑, 검색이 각각 노랑색, 오렌지색, 녹색, 파랑색의 컬러를 가지고 마치 4개의 회사로 나뉘어 있는 듯한 느낌으로 운영을 했습니다. (지금 다음의 디앤샵은 아직도 다음 밑에 있는 것을 싫어하는 것 같습니다.) 그러다보니 "다음"으로서의 아이덴티티는 살아나지를 않고, 유유자적 녹색 외길을 걸어온 네이버는 녹색만 보여도 "아, 네이버구나!"할만큼 아이덴티티를 확보하게 됩니다. 텔레비젼에서 녹색상자만 보여도 네이버 검색창이 연상될 정도이니 다음이 게임이 될리가 없지요.

그래서 여차저차 파랑색으로 방향을 잡으신 것 같은데, 왜 하필 파랑색인지 모르겠네요. 차라리 연한 파랑색으로 하늘의 느낌, 따뜻한 솜털같은 느낌을 주려고 했다면 모르지만, 차가운 파랑색 (채도 몇퍼센트만 더 떨어지면 2차대전 독일 병정 군복색이 됩니다)으로 어쩌시려고... 게다가 여태 밀어오던 색과 별 관계가 없죠? 차라리 파랑색을 다음쇼핑(요즘의 디앤샵)에 지정해 주고 옅은 노란색이나 하늘색으로 다른 컨텐츠들을 통일해서 지정해 주었더라면 하는 아쉬움도 있습니다.

게다가 로고부분의 스킨을 바꿀수 있게 해 두었던데, 좀체 납득이 가질 않습니다. 아이덴티티 컬러는 이미 포기한건가? 하는 생각이 듭니다.

뭐 가정은 가정으로 끝날뿐이고, 현실적으로 다음 사이트를 보면 역시 파랑색이 돋보이기에 검색바는 파랑색으로 맞춰보았습니다. 포스팅 박스는 깔끔하게 잘 정리되어 있습니다. 타이틀바는 연한 그라데이션 처리로 감각도 좋고요. 날짜 옆의 오렌지색 장식은 다음의 하이라이트 컬러에서 차용했습니다. 검색창의 무늬는 물방울을 형상화했고요. (저는 다음의 파랑을 바다로 해석했습니다. 정보가 넘치는 웹의 바다...)

그리고 카테고리 아이콘이 매우 느낌이 좋아서 사용해 보았습니다. 일단은 기능과 전혀 상관없는 배경무늬로 쓰였지만 네이버보다 센스가 좋네요.



야후로 넘어가겠습니다.

제일 눈에 띄는 변화는 폭입니다. 다른 스킨은 카테고리 부분의 폭이 좁아서 구분이 명확히 가는데, 야후는 두 폭이 거의 비슷하군요.

그리고 구글못지않은 여백을 자랑합니다. 깨끗한 느낌이 좋지만, 구글만큼 성의없다는 생각은 안드는데, 은근한 모노톤 그라데이션 배치가 효과가 좋네요. 그리고 아이콘도 활발한 느낌의 아이콘이 많아서 전체적으로 어울립니다.

단 하나 맘에 걸리는 것은 메인페이지의 스킨 기능인데, 전세계 웹의 아버지격인 야후마저 이러시면 곤란하죠. 가지고 있는 기술 레벨이 높은 것은 누구나 알고 있는데, 이렇게 마이너스 적으로 사용하실바에는 사용안하시는 것이 낫습니다. 그나마 위안이 되는 것은 야후의 움직임이 구글의 개인화 홈페이지의 성격을 띤다는 것이겠지요. 다음처럼 로고 뒷배경에 이상한 무늬가 들어가는 것도 아니고, 스킨을 교체할 경우 로고 뒷부분부터 타이틀바 등 거의 모든 요소의 분위기가 바뀐다는 점입니다.

모노톤이라 좀 질리기는 하지만, 편하게 디자인해서 성과를 얻고자 하는 것이 목표였다면 성공한 디자인 같습니다.

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

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

구글 스킨은 좀 어려운 스킨이었습니다.

일단 포탈이라 부를수 없는 성격을 가지고 있기에, 사이트의 분위기를 읽어 포탈의 느낌이 나도록 재구성해야했고, 사실 구글은 제 기준으로 "성의없는 디자인"을 가진 대표적인 사이트였기 때문에 자칫 잘못하면 "성의없는 스킨"이 되기 쉬웠으니까요.

그래도 구글의 기획자가 포탈을 만든다면 어떤 포탈을 만들까, 그리고 그 포탈을 어떻게 블로그의 스킨으로 표현할 것인가 생각해 보았습니다.

일단 전부 흰색으로! 그리고 로고는 구글틱한 서체로 만들어보았습니다.

전체적인 서체는 arial을 비롯한 기본서체로 했습니다. 구글이라면 퍼포먼스를 중시하고 있으니, 최대한 "쓸데없는 짓"을 줄였습니다. 타이틀바 등도 전부 CSS로 장식하였습니다.

달력 부분도 다른 스킨과는 틀리게 배경이미지를 사용하지 않고 최대한 심플하게 꾸며보았습니다.



네이버 스킨은 사실 제가 제일 먼저 만든 스킨입니다.

로고의 분위기와 검색바의 분위기를 일단 파악해 보았습니다. 네이버 로고인 날개모자의 색을 분석해 보면, 로고의 녹색을 받쳐주기 위해 약한 황토색에서 녹색으로 이어지는 컬러를 가지고 있는데, 그 부분을 큼직하게 표현해 보았습니다.

그리고 검색바는 녹색... 네이버 컬러의 근간이 되는 색이죠! 저는 이 녹색의 의미를 어떻게 이해해야 하는지 고민해 보았습니다.

녹색이라면 뭘까... 자연? 자연!

이 자연을 나타낸다고 하는 가정에서 납득했습니다. 네이버 컬러가 질리지 않는 이유를...

다음이 최근 밀고 있는 색인 파랑(다음컬러는 절대 아닙니다. 그 이유는 계속되는 포스팅에...)은 여름, 바다, 시원함을 상징합니다. 겨울에 절대 먹히는 색이 아니죠. 더구나 예전 월드컵 당시 다음의 검색바 컬러가 붉은 색이었던 것을 기억하시는 분이 계시지요? 아이덴티티를 지키기 굉장히 어려운 컬러입니다. 또한 보색인 오렌지색은 주목성이 높아 웹에서 매우 빈번히 쓰이는 색입니다. 배경을 무채색(검은색)으로 가정한 경우 빨간색보다 주목도가 높습니다.

하지만 녹색은 다릅니다. 일단 자연을 의미한다는 것은 관념적으로 그 안에서 일어나는 4계절의 변화를 모두 포용하는 의미를 가집니다. 즉, 어느 누구에게나 편안한 느낌을 줄 수 있다는 뜻이지요. 그리고 녹색의 보색은 핑크색입니다. 웹에서 사용빈도가 낮은 편에 속하는 색입니다. 또한 네이버의 녹색은 채도가 낮기 때문에 원색을 넣어도 극하게 대비되지 않습니다. 중요 사항을 빨강색이나 노랑색, 오렌지 색 등 원색으로 전달하고자 할 경우라도 무리없이 소화됩니다. 결국, 메인 페이지에 핑크를 사용해야 하는 극한 경우가 오기 이전에는, 아이덴티티를 지키면서 기능성에도 방해를 주지 않는 컬러 구성을 가능하게 만들 수 있다는 것이지요.

최근 네이버의 전면 개편에서 네이버가 밝아진 느낌이라는 평가가 있습니다. 밝아졌지요. 채도가 올라갔으니까요. 그 반동으로 각 컨텐츠에 쓰인 칼라가 채도가 확 내려가고 명도도 올라갔습니다. 이용자가 느끼지 못할 만큼의 변화로 분위기를 쇄신하는 컬러 기획은 정말 천재적이라고까지 말하고 싶습니다.

그런 의도로, 검색바에는 자연을 상징하는 나뭇가지 느낌의 간략한 무늬를 넣고, 각 타이틀바에도 나뭇잎을 장식해 보았습니다.

포스팅박스를 디자인하면서 느낀 부분이지만  네이버 메인 페이지는 타이틀과 본문간에 선이 없습니다. (너무 깔끔을 떠는 것은 아닌가 생각도 들었습니다만) 더구나 폰트 크기나 굵기도 같아서 자칫 구분이 안될 가능성도 있었기에, 제 스킨에서는 구분을 주는 식으로 해보았습니다.

그리고 footer부분의 저작권 표시 부분에 남색이 쓰이는데(개편전의 네이버 메인에서 위젯에 사용되던 컬러 계통입니다.) 이 부분은 NHN의 로고 컬러에서 차용된 것 같더군요.

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

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

내년은 어떤 의미를 가지는 해일까?

우선 과거 2년동안 무슨 일이 있었는지 정리해보았습니다.

2005년 : 저작권
네이버, 다음, 네이트온으로 포탈의 3강체계가 확립됩니다. 네이트온의 경우 싸이월드에 힘입어 엠에스엔 메신저를 누르는 기염을 토하며 부동의 국내1위의 메신저가 됩니다. 다음의 서비스를 벤치마크해오던 네이버가 이러한 네이트온의 성공에는 별로 동요하지 않는데, 메신저 서비스를 추가하는 것보다 기존의 블로그서비스를 강화하는게 났다고 판단했는지도 모릅니다. 확장형 포탈의 길을 걷던 네이버와 다음이 자존심을 지킨 덕분에, 3강 체제는 계속 이어져 나갈 수 있었습니다.

2006년 : 웹2.0
네이버의 블로그시즌2, 싸이월드C2, 다음의 티스토리 인수, 파란의 넥스트파란, 프리챌의 큐서비스 등 대형 포탈들이 조금씩 변혁을 시작해 나갑니다. 구글마저 개인화 홈페이지 서비스를 시작해 버렸으니, 전세계적인 포탈들의 변혁이라고 말해도 될 듯 합니다. 왜? 갑자기 전세계적으로 이런 일들이 일어난 것일까요?
바로 웹2.0이라는 단어의 탄생이라고 생각합니다. 오렐리 사장님의 이 한마디 때문에 많은 블로거들이 웹2.0을 인정한다 안한다로 양분되어 다투기도 했는데, 이 웹2.0이 단어의 탄생이 아닌 개념의 증명이라는 것을 증명하는데는 오래 걸리지 않았습니다. 새롭게 탄생한 많은 서비스들이 웹2.0을 새로운 사업의 전개로 연결시키지 않고, 전부터 존재하던 서비스들의 패러다임을 바꾼 상태로 제공해 나가기 시작했기 때문입니다. 웹2.0을 기반으로 새로운 사업을 전개한 기업들이 몰락한 것이 그 증거입니다.
또한, 구글의 애드센스가 기폭이 되어 국내에서도 검색광고시장이 확대되는데, 이를 위한 기반 사업의 일환으로 다음의 애드클릭스, NHN의 첫눈 인수, SK의 엠파스 인수등이 표면화되어 나타납니다.
비스타의 발표로 마이크로소프트 이외의 브라우저에 대한 관심이 깊어지고, 이제까지의 테이블 코딩에서 벗어나려는 움직임이 소형 웹사이트를 시작으로 점차 보이기 시작합니다. 웹표준의 태동이라고할 수 있겠지요. 한국의 대형 포탈중에는 다음이 제일 재빠르게 홈페이지를 개편해 나갑니다.

그렇다면, 2007년은?

추가 : 2006년은 네이버와 다음, 야후 등 많은 포털이 자사 API를 공개한 해이기도 합니다. 물론 구글의 영향이 있었음을 부정할 수 없습니다.

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

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