ILMOL.COM

따끈따끈한 브라우저 업데이트가 릴리스 되었습니다. 많은 분들이 기다리셨던 Firefox 3.5!
많은 기능중에서도 저는 일모리네가 언제나 그렇듯이 쌩뚱맞는 @font-face를 살펴보고 싶은데요 일단 @font-face 이야기 전에 간단히 아웃라인만 살펴보겠습니다.

• HTML5의 video 태그와 audio태그를 지원한다는것 (기타 문서적인 틀을잡는 태그들은 이미 지원중이었슴)
• 더욱 빨라진 js엔진
• Location Aware Browsing 탑재
• 더욱 빨라진 컨텐츠 렌더링
• 새로운 웹기술적용: downloadable fonts, CSS media queries, new transformations and properties, JavaScript query selectors, HTML5 local storage and offline application storage, <canvas> text, ICC profiles, and SVG transforms.

파이어폭스 인스톨 후 html5의 video, audio 태그를 강조하는거 보니 안띄워줄수 없더군요. 태그는 간단합니다.

<video src="http://videos.mozilla.org/firefox/3.5/meet/meet.ogv" controls style ="width: 600px;"></video>

삽입후 출력되는 화면.

이제 css로 스타일을 입혀줄수 있겠죠 video {border: 3px solid #eee;} 응용의 부분은 무궁무진합니다.

@font-face

이번 파이어폭스 3.5 부터는 @font-face 가 지원되게 됩니다. CSS3에서 구현되는 기능으로 보지만 이미 CSS2 때에도 사실 IE에서 특정 폰트종류 (.eot) 만 지원되었었죠. 엄청난 관심가운데 개발이 되어졌음에도 불구하고 copyright, 라이센스 등의 문제와 브라우저 미지원으로 널리 사용되지 못했습니다. 물론 이제 사파리3.1, 크롬 2.0 브라우저에 이어 불여우3.5 까지 지원되며 곧 릴리스될 오페라10 에서도 지원하게 됩니다. 몇달안에 IE를 제외한 모든 메이저 브라우저들이 이 기능을 지원 한다는 것입니다.

W3C에서 정의하는 @font-face 를 따오면, @font-face는 필요한 폰트를 링크하여 필요한 부분에 출력토록 하는 기능을 담당합니다. 제작자가 특정 환경때문에 폰트 미지원을 우려하여 기본폰트만을 사용하는 제한을 벗어나서 유저에게 원하는 렌더링을 보여줄수 있게 됩니다. CSS 룰을 사용하여 유저에이전트(보통 브라우저) 는 주어진 텍스트 안에 제작자가 원하는 특정 폰트가 사용될 경우 다운로드 하여 출력하게 됩니다. TrueType (.ttf) 이나 OpenType (.otf) 을 사용할수 있는 것이죠.

The @font-face rule allows for linking to fonts that are automatically activated when needed. This permits authors to work around the limitation of “web-safe” fonts, allowing for consistent rendering independent of the fonts available in a given user’s environment. A set of font descriptors define the location of a font resource, either locally or externally, and the style characteristics of an individual face. Multiple @font-face rules can be used to construct font families with a variety of faces. Using CSS font matching rules, a user agent can selectively download only those faces that are needed for a given piece of text. - W3C

사용법은 나름 쉽습니다. @font-face 에서 사용되어질 폰트이름과 위치를 지정해 놓으면 기본조건이 갖추어 집니다. 그 후 보통 폰트 스타일을 적용하는 것과 동일하게 font-family를 사용하여 이름을 불러주면 되겠습니다.

@font-face {
   font-family: ILMOL;
   src: url("http://ilmol.com/ILMOL.ttf") format("truetype");
}

p {
font-family: ILMOL;
}

특별히 제작자가 사용하고자 하는 폰트와 비슷한 폰트가 이미 유저의 컴퓨터에 있을 시에 그것을 먼저 사용하도록 하며 비슷한 폰트 조차도 없을 경우 다운로드 하게 하는 방법이 local입니다. 예를들어 ILMOL 이라는 폰트와 ELMOL 그리고 YILMOL 이라는 폰트가 거의 비슷한 스타일을 갖고 있으니 ILMOL폰트를 다운로드 전에 ELMOL이나 YILMOL 폰트가 일단 유저 컴퓨터에 있나 확인하여 사용하게 하려면,

@font-face {
  font-family: ILMOL;
  src: local("ELMOL"), 
       local("YILMOL"), 
       url(ILMOL.ttf);
}
 
body { font-family: ILMOL, sans-serif; }

이렇게 지정해 줄수 있습니다. 이는 특히 다른 플랙폼의 컴퓨터들 사이에 비슷한 폰트를 지정할때 유용한데 맥에서의 Helvetica 는 PC에 없으므로 비슷한 서체인 Trebuchet MS 가 있나 확인을 먼저 하게한 후에 Helvetica를 다운받게 할수 있겠죠. 물론 둘다 저작권의 문제도 있고 기본적으로 제공되므로 실제적인 사용의 사례는 없겠지만 말입니다.

위는 실제적으로 사용해 본 결과 입니다. 약 40k밖에 되지 않는 “Walt Disney Script” 서체 입니다. 웹그림 1개 다운로드 받는 사이즈 정도밖에 되지 않지만 엄청나게 파워풀한 결과를 가지고 올 수 있습니다. 디자이너분들은 무슨 이야기인지 뼈저리게 느끼고 계실듯 하네요. 물론 현재 IE와 Opera 9.x는 보이지 않습니다.

아직 이른걸까?

인터넷익스플로러가 지원하지 않는다는 치명적인 단점 말고도 넘어야 할 산들이 있습니다. 일단은 서체의 라이센스 문제입니다. 다행이도 Typekit 이 이부분을 위하여 열심히 뛰고 있는 중입니다만 무료라고 제공되는 폰트들이라 해도 css링크나 웹폰트로의 사용은 금하고 있는것들이 대부분 입니다. 타입킷 이메일 알림이에 가입해 놓은지 오래되었지만 아직도 별 다른 소식이 없네요.

한국에 이 문제를 적용시키게 되면 그 문제는 더욱 커지게 됩니다. 무료로 제공되는 폰트들을 찾기가 거의 불가능 할 뿐더러 지난번 네이버에서 ‘나눔’ 서체를 공개하며 한글 폰트 개발이 얼마나 어려운가를 나누었지만서도 몇천자를 디자인하여야 함은 해외 폰트개발과는 너무나도 차이가 납니다. 또한 서체의 개발이 어렵고 방대한 만큼 그 용량또한 방대합니다. 약 4MB을 넘나드는 사이즈는 웹폰트로써 적합한지의 의문조차 갖지 못하게 만들죠.

그럼 우리에겐 단순히 그림의 떡이냐. 네 앞으로 몇년간은 충분히 가능합니다만 변화의 가능성 또한 충분합니다. 일단 IE의 미지원이 그래도 가장 큰 장애물이겠지만 IE 개발팀 또한 @font-face의 필요를 충분히 인식하고 있기 때문에 추후에 곧 지원되지 않을까 하는 생각입니다. 이미 .eot 폰트 종류를 지원하므로 가능한 부분이라고 봅니다. CSS3가 완전해지지 않는한 지원않겠다는 방침을 들고 일어서면 할말 없습니다만…

IE가 지원에 나섬으로 인해서 모든 브라우저에서 @font-face가 가능해 진다고 볼때 제일 먼저 군침을 돌릴만한 곳은 각종 메거진과 신문사들입니다. 사이트들이 더욱 미려해지고 시시각각 바뀌는 헤드라인이 그 어느때 보다도 아름답게 출력된다면 이를 마다할 미디어 매체는 없다고 봅니다. 더군다나 1px의 미학을 즐기는 디자이너들에게는 천국과 같겠죠.
“난 1px 오탁후!”
여기서 웹서체를 제공하는 회사나 폰트업체가 나온다면 그 또한 유명세를 타게 될지도 모르는 일이구요.

언제 어떠한 방식으로 이 부분이 한국의 디자이너들과 개발자들에게 영향이 갈지는 누구도 모릅니다. 하지만 이미 해외개발자들에겐 시동이 걸렸고 사이트가 더욱더 세련되어지고 진화되도록 도울것은 확실합니다.
Less image, faster browsing, better internet.
이건 그 누구도 부인할수 없는 모두가 원하는 결과입니다. :)

좋은 소식에도 불구하고 한숨소리가…? ;; ㅠㅠ

사파리4 브라우저에는 사파리 개발자들이 브라우저의 역량을 마음껏 뽐내는 흥미로운 부분을 담고 있습니다. 짧게나마 나누면서 파워풀한 html5+css3+js를 만나보겠습니다.

사파리 브라우저를 설치하시면 오프닝 영상이 나오게 됩니다. 이 영상은 처음에 단순한 맥OSX 설치후에 시작되는 프로그램 자체적인 영상으로 생각했지만 그것이 아니라 여러 이미지들과 작은 MOV 파일을 가지고 HTML, CSS3, JS 로 이루어진 html 페이지 입니다. 물론 영상을 보시면 하나의 비디오 파일을 돌리는 듯한 착각이 들 정도로 잘 꾸며져 있습니다. 이미 베타버전 공개시 토론되었던 부분이라 아주 오랜 시간 후에 치는 뒷북일수 있겠군요.

<audio id="music" src="http://images.apple.com/safari/welcome/media/audio.mp4"></audio>
  <div id="header">
      <h1>Welcome to Safari 4</h1>
  </div>
  <div id="apple">
		<div class="icon"></div>
		<div class="spots"></div>
		<div class="flare"></div>
		<div class="flareicon"></div>
  </div>
  <div id="safari">
    <div>
		 <video id="compass" src="http://images.apple.com/safari/welcome/media/compass.mov" width="256" height="256">
			 <img src="http://images.apple.com/safari/welcome/images/safari.jpg" width="200" height="200" alt="Safari 4" />
		 </video>
    </div>
  </div>
</video>

HTML5 지원 하면 떠오르는 두 태그죠 audio, video가 눈에 띄실겁니다. 그러나 어찌보면 이 페이지에서 작은 부분을 차지할뿐 중요한건 CSS3 자체에 있습니다. #apple 안에 들어있는 .icon, .spots .flare .flareicon 등이 영상에 직접적인 연관을 보여줍니다. 물론 이벤트를 컨트롤 하는 js도 빼 놓을수 없겠죠.

오프닝 페이지의 소스를 보시면 아시겠지만 웹킷전용 CSS3를 제어하여 각각의 icon spots 등을 순서대로 ease-in, linear 방식등으로 일정 시간에 플레이되고 지연되도록 설정되어 있습니다. 간단한 순서대로 나열해서 말씀드리자면 첫째로 대강의 기본 설정이 첫 부분입니다. 그리고 각각의 엘리먼트들이 스케쥴데로 플레이 되도록 -webkit-keyframes 값들이 지정되어 있고 마지막에는 설정값과 엘리먼트의 연결 그리고 플레이 시간이 지정되어 있습니다.

하나하나 설명을 드리면 너무나 길어질듯 하구요, 간단히 예제를 보면서 설명드리겠습니다.
이하 코드는 제가 방금 제작한 ilmol.com 인트로입니다… 참 썰렁하네요.
대강의 스토리 라인은 ilmol.com/wp 를 클릭시 설정된 애니메이션이 작동하는 것입니다. 애니메이션은 하단에서 부터 화면 상단부분까지 사이즈및 투명도가 올라가면서 뚜렷하게 출력된후 사라지는 순서로 정했습니다. 일단 구현된 페이지를 사파리4에서 한번 보시구요.

(계속 읽기…)

오늘 많은 분들이 한국에서 밤을 새시면서 이번 2009 WWDC를 지켜보셨으리라 생각됩니다. 어느때 보다도 신빙성이 있게 다가왔던 아이폰 출시의 소문들이 많았기에 이번 컨퍼런스는 커다란 실망으로 다가왔으리라 생각되네요.

이번 컨퍼런스는 강하게 시작되었습니다. 새로운 맥북 라인을 발표하며 유니바디 디자인 맥북이 맥북프로로 들어가면서 새로운 맥북 프로라인이 형성되었습니다. $1200 대의 맥북프로가 생긴 것이죠. 모두 8G 까지 가능하며 500GB 하드장착이 가능합니다.

그후 새로 발표될 OS 스노우레퍼드를 발표하며 이번 키노트는 정말 굵직한 것들만 발표되는 구나라는 생각이 들었죠. 윈도우 7을 언급하며 발표를 시작한 것이 아무래도 윈7이 상당히 Mac OS X에 근접했음을 알수 있었습니다. 이제 몇주간 윈7을 써보며 상당히 안정적이고 적어도 맥OS를 써보지 않은 사람들에겐 ‘바로 이거야’ 라는 생각이 들 정도의 여파를 가지고 올수 있는 마소의 (잘 배낀) 시스탬이구나 라는 생각이 들었거든요. 스노우 레퍼드의 매력은 충분하지만 윈도우7은 아주 성공적으로 시작되는데에는 큰 영향을 주지 않을꺼 같습니다. 아무튼 스노우레퍼드는 최고의 os로 남을것으로 생각됩니다. 설치후 용량이 6GB나 리커버 해준다니…. :)

그리고 이어진 사파리 4 이야기. 사파리 4가 정식 출시되며 여러부분 메이저 업글이 있음을 시사하며 강력히 선보였습니다. Acid3 100, JS 향상. 새로운 커버플로우와 그리드 UI 는 매력덩어리로 다가왔습니다. 백문이 불여일견 곧바로 설치.

의례적으로 브라우저 설치후 몇초의 짧은 오프닝 영상이 돌아가더군요.

영상후 곧바로 그리드 형태로 Top Sites 들을 자동으로 불러들여와서 로딩됩니다.
(계속 읽기…)

html5 를 주욱 읽다가 copy&paste 로 노트에 남겨두었던 div 에 대한 부분이다. 사실 오랫동안 table 디자인으로 익숙해지셨던 분들에게 일모리를 포함하여 table 디자인 대체 요소로 보고 있지만 사실 그 이상이기도 하면서 그렇지도 않다. 쏟아지는 nested div 들 앞에 무너지는 많은 퍼블리셔들 개발자들을 보며 gg! 그리고 <! — 와 –> 랑 절친을 맺으시길 이라는 말 밖에는…

Div 엘리먼트는 특별한 의미가 전혀 없다. 자식 엘리먼트를 나타낸다. 이어지는(연속적인) 엘리먼트 그룹에 일반적인 의미를 마크업 하기위해 class, lang/xml:lang 그리고 title 속성과 함께 사용될수 있다.
The div element has no special meaning at all. It represents its children. It can be used with the class, lang/xml:lang, and title attributes to mark up semantics common to a group of consecutive elements. - W3C

div 엘리먼트에 phrasing content 을 담을 수 있도록 허락함으로써 저자들이 class=”" 속성 사용에서 부터 마크업 안에 다른 어떤 엘리먼트를 넣지 않는등 div 를 남용하기 쉽도록 되어있다. 접근성의 시각으로 볼때 이것은 악몽^[1] 이며 그러한 페이지들을 표준이 아님을(non-compliant) 알리는 식으로 하되 스팩이 따로 지원하지 않는 한 지금 상태의 메카니즘대로 사용되는걸 제한하지는 않도록 하면 좋을꺼 같다.
Allowing div elements to contain phrasing content makes it easy for authors to abuse div, using it with the class=”" attribute to the point of not having any other elements in the markup. This is a disaster from an accessibility point of view, and it would be nice if we could somehow make such pages non-compliant without preventing people from using divs as the extension mechanism that they are, to handle things the spec can’t otherwise do (like making new widgets). - W3C

그러고 보니 Table 의 악용 그리고 남용에 대해 글을 쓴지가 어제 같은데 이제는 div 남용에 대한 글들을 여기 저기서 볼 수 있다. 사실 불완전한 HTML 내에서 시멘틱 마크업을 최대한 살리면서 디자이너들이 표현하려다 보니 남용아닌 남용이 표출될 수 밖에 없다. 단순한 division 을 나타내며 문서를 자르는 것 뿐만이 아니라 이것 위에 프레젠테이션을 씌워야 하는 고통은 이미 많은 퍼블리셔들과 개발자들이 경험한 고통이다 (물론 nested div 도). html5 에서 header, footer, article, section, aside 등이 어느정도 해결을 해준다고 하지만 그 또한 ‘바로 이거야!’ 라는 뇌리를 치는 해결책은 아니다. 물론 어느정도의 시멘틱적인 요소를 첨가함으로써 문서 자체에 의미를 주지만 그것을 더욱 의미 있게 나누려다 보니… 사실 더 머리가 아파온다. 오해는 없으시길. 대환영 그리고 대환영이다. 숨통이 트여지는 기분.

물론 아직 밖은 흐리다.

Phrasing content 는 문서의 text(문자, 본문)들과 그 text 들을 마크업 하는 문단내(intra-paragraph) 엘리먼트들 까지도 포함한다. phrasing content 의 모음이 문단을 형성한다.
Phrasing content is the text of the document, as well as elements that mark up that text at the intra-paragraph level. Runs of phrasing content form paragraphs. - W3C

P.S. 사이트에 간단히 JS 로 HTML5 분위기를 IE 에서도 낼 수 있다는 장점을 사용해서 일몰.com에 몇안되는 요소들을 첨부 해보았다. 전에 어느분의 포스팅에서도 본거 같은데, DOCTYPE html PUBLIC “-//W3C//DTD XHTML Basic 1.0//EN” “http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd” 이거… 외우기 힘들다… <!DOCTYPE html> 얼마나 좋나…

P.P.S 몇일간 사이트 업데이트를 할 예정.

1. disaster 재앙이라는 표현은 한국에선 최악의 상황으로 표현될 뿐더러 잘 사용되지 않는다. [↩]

웹표준계의 유명 인사들은 한마디씩 남기며 이미 웹을 흔들어 놓은 Version Targeting 이라는 주제의 제 2차 공방입니다. Zeldman 아저씨께서 “Version targeting, take two” 라고 제목을 붙이셨더군요. Zeldman 씨의 글과 Jeremy Keith씨의 글들인데 젤드만씨는 다들 아시니 Keith씨의 글을 번역했습니다. 아마도 1차 공방은 밑에 번역한 “Doctype을 넘어“의 “Beyond DOCTYPE: Web Standards, Forward Compatibility, and IE8” 과 번역하지 못했지만 그에 대한 답변인 Eric Meyer의 “From Switches to Targets: A Standardista’s Journey” 이라는 글을 지칭하는듯 합니다. 아무튼 아직도 오픈되어 있는 토론의 장이니 주저말고 목소리를 내어 볼수 있는 시간인듯 하네요. 물론 영어로… 말입니다.

웹표준계에서는 꽤나 중요한 이슈이니 최대한 빠르게 전한다고 몽롱한 상태에서 마구 번역했습니다. 참고로 Keith 씨의 글은 내용은 쉬우면서도 글은 어렵게 표현해서 힘든것이 없잖아 있었습니다만 좋게 봐주시면 감사하겠습니다.

Translated with the permission of A List Apart Magazine and the author[s].
이하의 글은 A List Apart Magazine과 저자의 허락아래 번역되었습니다.

브라우저를 향해 이미 쏘고 있잖아 안그래?

브라우저 벤더들에게 종속적 이노베이션은 그리 새로운 것이 아니다. 인터넷 익스플로러는 우리에게 IXMLHttpRequest, innerHTML 과 색상적용이 가능한 스크롤바를 주었으며 각각의 비표준 확장들을 자유롭게 사용 혹은 무시할수 있었다. 이제 인터넷익스플로러는 우리에게 새로운 종속적 테크놀로지를 버전지정 이라는 형태로 우리에게 소개하고 있다. 하지만 이번엔 이 기술을 무시하기 위해서는 뒤틀린 방식을 써야 한다.

혼전

내가 처음 ALA에서 버전지정에 대한 글을 읽었을때 한 부분이 이해가 되지 않았다. 에릭마이어의 열정적인 글의 마지막 부분에서 IE8 이 IE7 같이 작동 한다는 것을 언급 하는듯 했기 때문이었다. “말도 안돼” 라는 생각에 분명 에릭의 글을 오해 한것이라 생각했다. 올바른 이해를 위해서 Chris Wilson 에게, 만약 IE8 이 올바른 표준의 strict DOCTYPE (버전 지정 없이) 을 읽으면 어찌 되는지 물어보았다. 아니나다를까 그는 브라우저가 이전 버전처럼 똑같이 작동한다고 알려주었다.

이런 어불성설이 어디있나. 새 버전의 Word 가 이전 버전과 똑같고 숨겨진 명령어로만 새로운 기능을 사용할수 있다 상상해보라. 바로 그것이 마이크로소프트가 개발자들에게 요구하고 있는 것이다. 정확하게 따르지 않으면 IE8이 (IE9, IE10 등 계속) IE7과 완전 똑같이 작동 한다고 말이다.

나의 불신은 그저 마이크로소프트가 멍청하다거나 단순히 “악” 이라는 이유로 완화되지 않았다. 인터넷익스플로러 팀은 표준 이해가 아주 뛰어난 개발자들로 이루어져 있다. 분명 이 말도 안되는 믿기지 않는 방법을 제안 하는데에는 아주 좋은 이유가 있을것이라 생각한다.

웹을 구하기 위해 파괴하다

마이크로소프트의 제안은 IE6에서 IE7으로의 업그레이드라는 이벤트부터 시작되었다. IE6은 지루하고도 괴로운 몇년을 개발이 없이 보냈다. 결국에는 라이벌 브라우저들에 의해 시잠 점유율을 빼앗기기 시작하자 IE7 이라는 이전 버전보다 더 나은 CSS를 지원하는 브라우저를 내 놓는다.

IE6가 너무 많은 세월동안 고여있었기 때문에 그리고 시장점유 리더였기에 전체적으로 웹사이트들은 쿼크(quirk, ie의 비표준 모드) 이긴 하지만 브라우저에 작동하도록 코딩되었다. 이 웹사이트들은 “작동” 하는듯이 보인다. 다시 말하면 시장에서 가장 인기있는 브라우저에서는 잘 보인다는 것이다. 하지만 IE7 이 출시되었을때 이러한 웹사이트들은 필연적으로 다르게 렌더링 되었다. 웹표준을 준수하는데에 발전한 IE7 인만큼 타 표준 준수 브라우저들처럼 렌더링 한 것이다. 개발자들에게 브라우저용 핵 보다는 “컨디셔널 코멘트”를 사용해 달라는 켐페인에도 불구하고 마이크로소프트는 웹사이트 소유주들에게 IE7이 경기를 바꾸어 놓은데 대해 빗발치는 불만만을 받았다. 이것이 바로 인터넷 익스플로러 팀이 지칭하는 “Breaking the Web” 웹을깨는 것 이다.

위의 문구(breaking the web) 가 많은것을 말하지만서도 자세히는 담고 있지 않다. 첫째로 “웹”의 이슈가 아닌 “몇몇 웹사이트”의 이슈이다. 둘째로 “깨는것” 보다는 “다르게 표출하는것” 이 더 어울린다. 마지막으로 한개의 브라우저에서 웹사이트들이 어찌 보이느냐 를 이야기 한다는것을 잊으면 안된다. IE팀이 말하는 “웹을 깨는것” 은 엄밀히 말하자면 그들의 브라우저가 타 모던 브라우저들과 같은 방식으로 문서를 표기 한다는 것이다. 그것이 그리 나쁜 것일까?

누가 자식을 생각지 않겠는가?

사실 시장 리더라는 것은 동경할만 한 것이다. 하지만 그에 따르는 책임을 생각해 보라. 조그마한 변화에도 수천의 고객의 등을 돌리게 하는 테두리를 개발하고 지원하겠는가? 이것이 바로 마이크로소프트가 벗어나고자 하는 마비상태이다. 이 버전지정 제안은 이 부동의 상태를 깨는데에 좋은 해결책으로 볼수 있다. 거기에 meta 엘리먼트까지 가세하면 웹사이트들은 정확하게 어떻게 렌더링 되는지 지정할수 있다 (한 브라우저에서 말이다)

거기에다 마이크로소프트가 X-UA-compatible 을 ie7 에 지정했다면 많은 수고를 덜었을 지도 모른다. 개발자들이 브라우저 종속적인 핵을 고치기 위해 css를 제방문하여 수정하기 보다는 그저 웹마스터에게 사이트의 head 부분에 한 라이만 더하라고 하면 됬을 것이다. 비록 IE7에서 IE8으로의 업그레이드가 이정도로 기대를 얻지는 않았을 지라도 마이크로소프트가 미래를 준비했다는 것으로 위안이 되었을 것이다. 버전지정은 사이트 소유자들에게 특정 브라우저 버전에 렌더링이 종속되어 변하지 않도록 한다. 그것은 좋은 것이다. 나와 여러분 같은 표준 개발자들에게는 별 영향이 없을지라도 미래를 별로 걱정치 않는 사이트 소유자들에게는 간편한 해결책을 제공한다. 그 외에도 X-UA-compatible 이 헤더로 보내질수 있다는 사실만으로도 시스템 administrator 들에게도 서버 환경설정의 작은 한 변화로 이 이슈가 해결되는 것이다.

하지만 그 조차도 마이크로소프트에 따르면 너무 많은 것을 요구하는 것이다. 미래 개선에 별 상관치 않는 개발자들에게 meta 엘리먼트나 해더를 더함을 물어보는 것이 아니라 인터넷익스플로러는 표준 메니아 개발자들에게 버전지정을 사용하여 버전지정에 참여하지 않는 것을 기대하고 있다.

이유는 표준에 덜 집착하는 개발자들에게 한개의 엑스트라 라인을 문서에 넣는것에 신경을 쓰지 않아도 되기 때문이다. 오히려 그들에게 시장에서 제일 잘나가는 한 브라우저 버전의 쿼크모드를 쓰도록 권유하는 샘인것이다. 혹 그들의 문서가 타 브라우저에서 깨지는것은 마이크로소프트의 문제가 아닌것처럼. 이런 우월감으로 바라보는 시각의 반대면을 보면, 표준을 인식한 개발자들은 그들의 문서에 그 한줄을 사용할 가장 확실한 부류로 볼수 있다. 비록 설명할수 없는 이유로 IE=edge의 최신 버전 지정 사용이 권장되지 않고 있긴 하지만.

이 전략은 실패일 수 밖에 없다. 표준을 인식한 개발자들은 거의 본능적으로 한 브라우저에서 제대로 작동하도록 한줄의 불필요한 마크업을 하게 될것이다.

익사의 두려움

대부분의 웹 개발자 커뮤니티에서는 ie7 의 공개를 환영했지만 Redmond 안에서는 (마이크로소프트 회사가 위치한 Redmond, WA를 지칭하는듯) 실패로 보았다. 마이크로소프트는 IE7 업그레이드와 같은 실수를 되풀이할수 없다. 버전지정은 두려움의 산물인 기술이다. “웹을 깨는것” 을 두려워한 즉 다른말로 표현하자면 “한 브라우저에서 몇몇 사이트가 다르게 렌더링 되는것” 때문에 가혹한 반응, 해결책이 나온 것이다.

IE8이 얼마나 확연하게 현존하는 웹사이트들을 “깨는가”에 따라 이 두려움이 잘 혹은 덜 표현될 것이다. 개인적으로 나는 좀 아리송 하다. 도대체 다음 버전의 브라우저에는 무엇을 더하여 웹이 터지도록 할것인가? 만약 IE8이 이전 버전과는 확연히 다르게 표준을 준수하는 브라우저라면 파이어폭스나 사파리 오페라등의 표준 준수 브라우저들로 IE8에서 보이는 웹사이트들을 비교하여 평가해볼수 있을 것이다.

최고는 외롭다

Friendster 가 가장큰 소셜네트워킹 사이트였던 때가 있었다. 넷스케이프 네비게이터가 누구도 부인할수 없는 브라우저의 왕좌에 있었고 IE는 넷스케이프를 따라오려면 한참 먼 우스운 도전자였던 때가 있었다. 월드와이드웹 세계에서는 위치/상태 가 변덕스러우며 변화 한다. 이 버전지정의 기본 행동상태의 제안은 일정 기간동안 마이크로소프트가 자신의 브라우저로 성공하며 최고의 자리에 오른것을 기반으로 삼고 있다. 이것은 인터넷익스플로러를 통해서만 의미있는 웹의 경험을 할수 있다는 표현하지 않은 가정이다.

우리는 이 버전지정의 기본행동 상태가 없이는 혼돈의 범죄의 현장으로 변할것이라고 상기되고 있다.(한 브라우저에서…) 만약 마이크로소프트가 불완전한 IE8이 웹(한 브라우저에서…)을 구하는데 절대적이라고 생각하는것을 믿는다면 그것을 따르느냐 아니냐는 믿음에 달려있다. 바로 마이크로소프트가 IE8이 가지고 올 영향에 대해 올바르게 예언하고 있다는 믿음 말이다.

나는 사실을 기초해서 판단하고 싶다. IE8의 버전지정이 올바른 것인지 마이크로소프트가 쉽게 증명할수 있는 방법이 있다. IE8의 버전지정이 기본적으로 disable 되어있는 베타버전을 공개하는 것이다. 얼마나 웹이 깨지는지, 아니 몇몇 사이트들이 한 브라우저에서 다르게 렌더링 되는것이 얼마나 나쁜지 볼수 있을 것이다.

난 버전지정쪽의 모든 의견들을 듣고 이해 했다. 모두 IE8이 웹의 확연하게 많은 부분을 망칠꺼라는 가정을 하고 있었다. 만약 그 두려움이 베타브라우저의 출시후 현실이 된다면 난 당연히 버전지정쪽을 지원할것이다. 하지만 그때까지는 현재의 DOCTYPE을 담은 바르게 완성된 문서들을 최대한 지원하겠다는 몇년전의 약속을 지켜주기를 기대한다.

불완전한 미래

버전지정은 나쁜 아이디어가 아니다. 전달방식 메카니즘의 선택, 메타 엘리먼트 혹은 서버 해더는 좋다. 선택가능한 기능으로써 몇몇 환경에서는 정말 도움이 많이 될꺼라 믿는다. 하지만 강제적 마일스톤으로는 progressive enhancement 에 반대된다.

두통을 해결하기 위해 머리를 잘라버리는 것 처럼 IE의 버전지정은 “웹을 깨는것”을 해결할수 있다. 하지만 환자가 죽는다. 버전지정은 마이크로소프트가 이노베이션을 보여주는 기회일수 있었지만 그 반대로 이 제안은 마이크로소프트의 웹에 대한 근본적인 오해를 보여주었다. 웹의 창시자 팀 버너스 리의 웹은 언제나 “조금은 깨어져 있는” 곳이라는 것을 말이다.

HTML5 Validator.

절대 테스트용으로만 사용하시길 :)