사파리 블로그에 이미 소개 되었는지라 많은 분들이 아실지도 모르지만 CSS Animation 이라 불리우는 역동적인 CSS 부분들이 이번 3.1에 첨가되었고 그 중에서도 Transition (전환) 에 관한 것들이 구현 가능케 되었습니다. [이하의 모든 예제들은 사파리 3.1이 설치되어 있어야 확인하실수 있습니다.]

transition-property - 어떠한 전환 속성을 작동시킬 것인지 지정 예: opacity
transition-duration - 얼마동안 이 속성이 지속될것인지 지정ow long the transition should last.
transition-timing-function - 어떠한 종류의 타이밍을 갖을것인지 지정. 예: linear vs. ease-in vs. a custom cubic bezier function
transition - 물론 한번에 지정가능한 속성도 제공하는군요.

위의 div 에 마우스를 가져다 대시면 천천히 div 가 사라지는 효과를 확인하실수 있습니다. 이는 div 에다
div {opacity: 1; -webkit-transition: opacity 1s ease-in; }
값을 정해준 후 hover 시에 opcity 가 0으로 되도록 지정된 결과 입니다.
div:hover {opacity: 0;}

이 외에도 여러가지 효과를 줄수 있는데 간단한 transition 속성으로 많은 이득을 볼수 있습니다.

실무적으로야 아직 쓰이지는 못하겠지만 여러가지 생각해 볼수 있는 부분인거 같네요. 이번에 Torrey Rice가 이 CSS Animation 기능을 활용해서 SVG 와 함께 멋진 동작 예제를 구현해 놓았습니다. 설명을 곁들여서 보시면 이해가 더 쉬우실 겁니다.

아시다시피 CSS3의 계획이 계속 지연되면서 몇몇 브라우저들 사이에서 multi background image나 text shadow 등등이 자체적으로 지원되고 있는 실정입니다만 이러한 불완전함을 핑계로 인터넷익스플로러 팀이 자체 CSS 개발을 이루겠다는 야심을 보인 것입니다. 일단은 CSS3-IE 로 부르고 있고 이 스타일시트가 초안으로 들어갈때 즈음에 IE9 베타가 출시될 것으로 보입니다.

많은 개발자들과 디자이너들의 한숨이 여기저기서 튀어 나오고 있는데요.

마이크로소프트의 인터넷익스플로러 팀이 CSS3-IE를 개발하려 한다는 것은 일모리의 조작된 만우절 논리일 뿐이다. - 빌게인츠

CSS3-IE 개발을 과연 누가 믿겠느냔 말이다. 그저 4월1일의 장난일 뿐이다. - 젤든맨

이러한 논란들로 CSS3-IE 의 개발을 무시하고 있습니다. 저 또한 강력히 동의하고 있는 부분이구요. 여러분들도 동의 하시리라 생각됩니다.

너무나도 낚이신분들이 많을꺼 같아 두려움의 한숨만 나올 뿐입니다…

죄송합니다.

오페라는 다음주중에 “최초로 Acid3를 통과했다는” WinGogi Desktop build 를 공개한다고 밝혔고, Webkit팀은 자신들의 엔진이 “최초로 Acid3를 통과한 공개버전이다” 라는 비슷하지만 다른 뉴스를 보내고 있습니다. 오페라는 비공개 엔진이 통과했으므로 인증샷으로 설득하려 하며 사파리는 당당히 공개버전이 통과했다며 군중을 설득하려 하고 있습니다. 재밌죠 ^^

With r31342 WebKit has become the first publicly available rendering engine to achieve 100/100 on Acid3.

일단 어찌 판명될지는 두고봐야겠지만 일단 Acid3를 통과한 오페라와 사파리 엔진들 축하합니다.

여담. 어제 자기전에 모질라 10주년 축하 샷을 찍었는데 영 폼이 안나는군요. 졸리긴 졸렸나 봅니다. 저건또 머라 쓴건지;;

“10주년 축하합니다!” 앞에다가 “자랑스럽습니다. 당신의” 를 넣고 “그리고 감사합니다” 를 뒤에 넣는다고 css selector 넣고 멀 끄적였는지 원. 하고보니 촌스러워요. ㅡㅡ; 공개사과 합니다.;;

여담2. 요즘 시간 나는데로 일모리네를 업데이트 중입니다. 지금 한 RC1 정도밖에 안된거 같네요. 접근성 꽝, CSS는 정리도 잘 안되서 크키만 하고 꽝, 오늘중으로 guestbook 정도는 손보고 열으려 합니다. 웹표준이란? 이 글을 쓰다보니 한 글로 쓰기에 좀 무리인거 같아서 아예 위키식으로 방대하게 작업하려 합니다. 화이팅.

It’s true that acid tests like this are not thorough standards compliance tests, and often enter the realm of very obscure standards details. But Acid 3 tests a lot of technologies that matter to everyday web development.

이러한 Acid 테스트가 표준의 절대적인 기준이 되는것은 아니지만 실질적인 웹 개발에 필요한 기술을 테스트 하고있다.(그러므로 웹킷은 이것을 지키기로 한다). - Webkit Blog

여담이지만 인터넷익스플로러의 css 버그들에 관한 업데이트가 css-discussion 에 업데이트 되고 있습니다. - 현재 다운되었군요;;

예전에 한창 IE 파해치기 모드이었을때에 IE6를 돌리며 동시에 IE 5.5를 다운받아 사용할수 있는 사이트를 소개 했었는데 이젠 링크도 깨졌고 약 3년전의 이야기라 그동안 설마 Microsoft 의 OS 를 가동시키시며 포멧을 안하신 분들이 그리 많지 않을거라 생각하며 재포스팅 하기로 했습니다. 이번엔 설치 프로그램으로 돌아가더군요. 해서 오래전 Internet Explorer 3.0 버전부터 ^^;;; IE4.01, IE5.01, IE5.5, IE6.0 까지 5개의 버전을 설치하여 최근 인증확인없이 IE7, IE8베타 설치가 가능해 지면서 7개의 버전들을 동시에 구동할수 있게 되었습니다. 물론 이제 5.5 이하 버전은 거의 사라졌다고 봐도 되지만 가끔 5.5 버전까지의 크로스 브라우징을 원하는 곳들이 있기에 깔아두면 좋을듯 합니다.

페이지가 영어이긴 하지만 용기를 내시고 TredoSoft 포스팅 마지막 부분의 “Download Multiple IE installer” (10.3MB) 을 클릭하시면 됩니다.

그러고 보니 2005년 당시에는 사파리의 윈도우 버전은 꿈도 못꾸었기 때문에 사이트가 사파리에서 어떻게 보이는지 스크린샷으로 보여주는 사이트들이 인기가 있곤 했습니다. 불여우는 대망의 1.0으로(2004 11월) 뉴욕타임즈 1면에 전면 광고를 하는 기염을 토하며 시작했었고 말이죠. Opera 는 무료이긴 했으나 작은 광고가 붙어 나왔기에 무광고 브라우저를 위해 블로거들이 오페라 베너를 달아 일정다운로드 수가 넘어가도록 했었죠 ^^;;; 기억에 lunamoth 님께서 성공하셨던거 같은… 이루마를 듣고 있으니 센티멘탈해져버렸습니다 ㅡㅡ;;;

아무튼 이제 편하게 IE7 / IE8 베타 까시고 IE6 이하 버전들까지 한 컴퓨터에서 돌리시며 즐거운(고통스러운) 크로스브라우징의 세계를 즐기시기 바랍니다. 물론 막히시는 부분은 일모리네 혹은 CSS Design Korea 등의 도움을 절대 받으시는 것도 정신 건강에 도움이 됩니다. 담배는 몸에 해롭습니다………..

오늘도 밤을 새시는 여러 많은 분들 힘내세요;;;;;;;;;

자려했는데 오늘밤에 고쳐야할 친한 동생의 컴퓨터가 있는지라 포멧하면서 기다리는 동안 키보드를 두드리고 있습니다.. ㅠㅠ

원문 IEblog: why isn’t ie8 passing acid2?
왜 ie8이 acid2 를 통과하지 않는걸까?

비록 IE8 베타1이 ACID2를 통과한다 했지만 몇몇분들은 위의 이미지처럼 깨져있는것을 보셨을 것입니다. 해서 약간의 설명이 필요하다 생각했습니다. IE8 은 ACID2 테스트를 http://www.webstandards.org/files/acid2/test.html 사이트에서 통과하였습니다. (참고로 이곳은 acid2 테스팅을 위한 인기높은 사이트입니다. 현재 접속이 힘드실수 있습니다.) 웹에는 이 acid2 테스트가 가능한 여러 사이트들이 있으며 제가 최근 본 acid2 서비스 사이트는 http://acid2.acidtests.org 입니다.

IE8 은 Active X 컨트롤의 크로스 도메인 보안 확인 기능으로 인해 ACID2의 “복사본” 사이트의 테스트를 통과하지 못했습니다. IE가 Object 태그의 HTML 컨텐츠를 자체적으로 돌리지 않고 IE의 렌더링 엔진을 Active X 처럼 구동하여 HTML 컨텐츠를 보여주므로 동일한 크로스 도메인 보안 확인또한 적용(다르게 해석하면 거치게) 되는 것입니다.

그렇다면 어떻게 ACIDTEST.ORG 카피(역: 카피라고 자꾸 강조하는군요) 가 OBJECT fallback 을 어떻게 이해하여 스마일얼굴의 눈을 처리하는지 보겠습니다.

<object data=”data:application/x-unknown,ERROR”>
<object data=”http://www.damowmow.com/404/” type=”text/html”>
<object data=”data:*the eyes DATAURI* …>
</object>
</object>

IE 는 위의 하이라이트된 라인 부분의 OBJECT fallback 과정을 멈추게 됩니다. 이 일에 참여했던 팀과 나는 이것이 바른 작동이라 결정내렸으며 이유는 이 크로스 도메인 컨텐트가 404 HTTP 에러코드의 실패한 리소스 인지 혹은 다른 표준의 한 부분이 실패를 알리는 부분인지 알기 위해서 네비게이션을 허락해야하기 때문이죠. 호환성을 유지하며 기본적으로 보안을 유지하기 위해서 원래 웹저자들이 원하지 않았을지도 모르는 fallback 물러서는걸 발동하고 싶지 않았습니다. 제일 안전한 해결책과 함께 시작했으며 이제 앞으로 이 부분을 미래 베타를 위해 안전하게 조금 느슨하게 하는 것을 고려하고 있습니다.

이제 www.webstandards.org 가 제공하는 공식 ACID2 테스트 페이지를 보겠습니다.

<object data=”data:application/x-unknown,ERROR”>
<object data=”http://www.webstandards.org/404/” type=”text/html”>
<object data=”data:*the eyes DATAURI *>
</object>
</object>

보시다시피 (역: ACID2 를 통과했을때의) 테스트 도메인이 같으며 고로 모든것이 잘 돌아갑니다. 아시다시피 http://webstandards.org (앞에 www 가 없음을 주목) 라는 네비게이션을 허락합니다. 이것 또한 크로스 도메인 접근 이죠. www.webstandards.org != webstandards.org 처럼말입니다. 이것 또한 ACID2 테스트가 맨위의 그림처럼 깨어지게 보이게 할 것입니다. 그러므로 테스트 시에는 www.webstandards.org 를 타입하기 바랍니다.

Phil Nachreiner
Internet Explorer Developer

음….

번역이 잘 되었나 모르겠습니다. 일단 ie8 이 Active X 컨트롤의 크로스도메인 보안 체크를 하므로 www.webstandards.org 라는 공식적인 페이지에서만 smily face 가 완성이 된다는 해명으로 볼수 있겠네요.

이 부분에 대한 Ian Hickson(acid2와 acid3 개발) 의견입니다.

But if it’s failing — for whatever reason, cross-domain or not — you should fallback. Hence the current behaviour is still a bug.

(BTW why would it be a cross-domain problem? This should be exactly the same as an iframe, which can cross domains fine.)

하지만 일단 (acid2 테스트를) 실패했다 어떠한 이유에서건 크로스 도메인이든 아니든 말이다. 그러므로 현재 동작상태는 버그이다.

(헌데 그것이 왜 크로스 도메인 문제인가? 이건 크로스도메인이 가능한 iframe과 동일한 것이다.)

역시 루머아닌 루머가 맞았습니다. 베타1 버전이 출시되었군요. Server 2003, Vista, XP SP2 버전까지 나와있습니다. 아시다시피 베타 버전이라는 점 유념하시구요. 다운로드시 마이크로소프트 다운로드 센터의 명시를 보니 이렇게 설명되어 있습니다.

이 베타는 모든 이들에게 오픈이지만 특별히 개발자들과 디자이너들이 새 툴과 새 레이아웃 엔진등을 테스트 하는 것에 있다. 웹사이트를 개발하지 않을 시에는 Emulate IE7 버튼을 눌러 IE7 에서 서핑하듯 돌아올수 있다.

아마도 IE7 엔진을 담고있는 이득을 여기서 보는듯 하군요. 아무튼 오늘 블로고스피어 뿐만 아니라 수많은 개발자들, 유저들 가운데서 IE8 이야기로 후끈후끈 할듯 보입니다. 특히 IE8 의 표준모드는 ACID2 테스트를 통과하지 못하는 지라 못내 아쉬움이 많이 남긴 합니다. 그래도 많은 발전이라고 기쁘게 받아들이며 일단 이곳저곳을 테스팅 중입니다.

덧: 현재 제 사이트도 그러하지만 ^^ 많은 사이트들이 form 부분에서 상당수 깨지고 있습니다. 혹시나 공통적인 해결점이 있다면 알리도록 하겠습니다.

덧2: 버전지정을 통한 대충 대충 어느정도 해결점을 찾음.

버전타게팅을 사용한 편법

이 버전지정 테크닉은 아마도 빠르게 번질 “IE8에서 사이트가 깨지는것을 해결하는” 편볍 해결책으로 나올듯 싶습니다. 여러가지 테스트를 해본 결과 이전에 말씀드린 버전타게팅이 제대로 작동하는듯 보입니다. 다시말해서 meta 태그를 사용하여 ie7 렌더링 엔진을 사용하도록 하면서 ie8 표준모드를 사용치 않도록 함으로 해서 깨어진 ie8 의 사이트를 제대로 보이게 하는 것이죠.. 특히나 대형 커뮤니티 사이트나 포털등은 지금이라도 ie8에서 깨지는 것을 일단은 막고 차후에 고치는 방향으로 가는것도 좋다고 생각이 됩니다. 편볍 해결법은 이렇습니다.

<meta http-equiv="X-UA-Compatible" content="IE=7" />

이 코드를 해더에 삽입을 하면 되지만, 주의해야할 부분은 ie7 코멘트핵을 쓰셨다면 ie8 핵을 지정한후 ie7 스타일시트를 그대로 옮겨와야 합니다. 여러 테스팅을 해본결과 ie7 렌더링을 하게되지만 브라우저는 ie8 이므로 ie8 코멘트핵을 이해하더군요.

<!--[if IE 7]>
  <link type="text/css" rel="stylesheet" href="styleie7.css" />
 <![endif]-->
 <!--[if IE 8]>
  <link type="text/css" rel="stylesheet" href="styleie7.css" />
 <![endif]-->

혹은 ie 핵을 잘 쓰시는 분이라면 “ie7 과 그 이상” 이라는 핵을 설정해 주면 위와 같은 효과를 내겠죠. [if IE 7] 을 [if gte IE 7] 으로 바꿔주면 되습니다.

<!--[if gte IE 7]>
  <link type="text/css" rel="stylesheet" href="styleie7.css" />
 <![endif]-->

일단 웹의 진보적인 성격과 웹표준의 발전으로 볼때에 한 버전에만 머무는 버전지정은 그다지 추천하고 싶지는 않지만 일단은 IE8이 베타버전인만큼 버전지정을 통하여 IE8 표준모드에 맞는 사이트가 개발될때까지 IE7 렌더링으로 채택하는 것이 바른 방향이라고 생각됩니다. 그저 버전지정으로 머무는것보다는 앞으로 꾸준히 발전할 익스플로러를 보면서 표준을 채택한 웹개발의 방향을 바라보는것이 맞다고 생각됩니다.

새로운 기능들

마이크로소프트는 웹사이트를 통하여 새로운 기능들을 5가지로 소개하고 있습니다.

“Activities”

“Activities 는 어느 웹페이지에서든지 빠르게 필요한 서비스를 사용할수 있도록 돕는 서비스 입니다.” 라고 말하고 있네요.

2가지 종류의 “활동”을 보통 담당하게 될텐데 첫번째는 “찾기” 류의 기능으로 어떠한 정보를 찾는것을 말합니다. 웹사이트의 주소를 보고 곧바로 지도에서 찾도록 하던지 구글에서 직접 정보를 찾아서 보여주는 것이죠. 두번째인 “보내기” 부분은 웹사이트의 컨텐츠를 어디론가 보내는 역할입니다. 예를들어 자신의 블로그나 이메일로 보낸다거나 하는 기능이겠죠.

특징은 유저들이 직접 “Activities” 를 지원하는 서비스들을 선택하여 사용할수 있다는 것입니다. 아마 네이버도 들어가겠죠?

WebSlices

Slice 가 ‘자르다’의 뜻인만큼 웹의 어느 필요한 부분을 자르다 라는 의미를 내포하고 있는거 같습니다. 이는 피드 리더기를 브라우저에 실용화하여 적용시킨듯 하군요. 즐겨찾기 기능처럼 피드를 WebSlice 로 툴바부분에 선택해 놓으면 피드가 업데이트 될때마다 사이트에 방문하지않고도 툴바의 링크를 클릭함으로도 피드를 읽어볼수 있는 기능입니다.

즐겨찾기바

이름과 약간의 기능들이 추가된 툴바 입니다. 즐겨찾기를 해 놓은 사이트들 뿐만 아니라 여러 다른 문서들 예를들어 워드, 엑셀, 파워포인트 문서들도 즐겨찾기를 해 놓을수 있군요.

자동 크래쉬 복구 기능

ACR 이라고 불리운다는군요. 약간 아이러니 한 기능이 아닐까 했는데요 ^^ 브라우저가 갑자기 다운된다거나 탭이 담고 있는 사이트가 다운될때 복구되는 기능입니다.

향상된 피슁 필터

피슁기능에 “Safety Filter” 기능이 더 생긴 것입니다. 더욱 안전한 서핑을 위함이라고 하는군요.

내 사이트를 IE8에 최적화

Activities, WebSlices 등의 적용방법들과 함께 CSS2.1 준수, 더 나은 AJAX 개발, DOM 코어 향상, API 선택자, 플랫폼 기능향상, Circular 메모리 누출 경감, HTML 향상과 ACID2, 그리고 Namespace 와 Protected Mode API 지원의 부분들을 이야기 하고 있습니다. 이 부분들은 계속 업데이트 하겠습니다.

아시다시피 IE8의 방향은 웹을 깨지 않는, 즉 IE7의 렌더링을 기본으로 삼으면서 원하는 개발자들에게는 IE8의 소위 “표준 렌더링 모드”를 선택할수 있도록 하는 것이었습니다. IE6 에서 IE7으로 넘어오며 깨어진 수많은 사이트들이 더이상 브라우저 업그레이드를 통해 깨어지지 않도록 “배려” 한다는 명분 아래 IE8은 새로운 버전과 ACID2 를 통과한 렌더링 엔진을 갖고 있으면서도 하위버전으로 렌더링이 되는 방향을 택하려 했었던 것이죠.

이제 이 방향을 틀어 IE팀은 원래 계획이었던 Version Targeting을 중심으로 한 호환성 유지 보다는 IE8 이 Standard Mode, 표준 모드를 기본모드로 택하게 되면서 IE 가 배려하고자 했던 IE6 이나 IE7 에 종속적인 사이트들을 감싸기 보다는 표준 준수를 권장하는 미래 지향적인 표준의 브라우저로 거듭날 것이라는 입장을 알린 것입니다. 그 입장이 사실인지 아닌지는 잘 모르겠지만 일단 웹표준 커뮤니티에서는 “일단은” 기쁘게 받아들이고 있는 뉴스가 되었습니다.

In light of the Interoperability Principles, as well as feedback from the community, we’re choosing differently. Now, IE8 will show pages requesting “Standards” mode in IE8’s Standards mode. Developers who want their pages shown using IE8’s “IE7 Standards mode” will need to request that explicitly (using the http header/meta tag approach described here).

하지만 아직 이르다

아마 이 뉴스에 가장 크게 반응 할 그룹은 웹개발자들 소위 퍼블리셔로 불리는 그룹과 사이트를 소유하고 있는 그룹일 것입니다. 퍼블리셔/ui 개발자들은 상호연동성(Interoperability)을 선택한 IE8 과 함께 표준으로 변화된 사이트들을 제작하는 것이 꿈만 같은 일이겠으나 꾸준히 남아있을 IE6와 IE7 잔재들 가운데 과연 사이트 관리자가 투자를 통한 표준지향을 선택하게 될까요?

이슈는 이것입니다. IE8 이 표준렌더링 모드를 기본으로 탑제하지만 IE7 의 렌더링 모드를 Version Targeting 을 통해 제공하게 됩니다. IE6와 IE7에 종속적인 사이트들이 IE8이 출시 되었을때 IE7 때처럼 새 브라우저에 맞는 개발을 선택하기 보다는 현재 유지되고 있는 IE7 의 렌더링을 메타태그 한줄로 사용할수 있게 되면서 IE8 표준모드 대신 불완전한 표준 브라우저 IE7 렌더링 엔진을 사용할 가능성이 상당히 높습니다. 또한 IE8 이 출시 된 후 라고 하더래도 IE7 과 IE6 의 브라우저 점유율의 변화가 급격히 찾아오지 않는한 IE8 표준 모드에 맞추어 사이트를 개발하게 된다면 IE7, IE6에서 깨어지는 현상을 피할수 없으므로 하위버전 또한 고려하여 사이트 개발을 진행해야 하니 과연 IE가 어느정도의 위험을 감수하는 것인지.

IE8 이 표준모드를 기본모드로 탑제 했다고 하지만 앞으로 버전지정(version targeting) 기술의 잔재가 어디까지 어떻게 이어질지는 두고 봐야할 문제인듯 싶습니다.

웹표준계에서는 꽤나 중요한 이슈이니 최대한 빠르게 전한다고 몽롱한 상태에서 마구 번역했습니다. 참고로 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의 버전지정은 “웹을 깨는것”을 해결할수 있다. 하지만 환자가 죽는다. 버전지정은 마이크로소프트가 이노베이션을 보여주는 기회일수 있었지만 그 반대로 이 제안은 마이크로소프트의 웹에 대한 근본적인 오해를 보여주었다. 웹의 창시자 팀 버너스 리의 웹은 언제나 “조금은 깨어져 있는” 곳이라는 것을 말이다.

Acid2가 HTML, CSS의 정적인 부분의 테스팅을 담당했다면 Acid3는 100가지의 ECMAScript 와 DOM 등의 브라우저의 다이나믹 부분을 검사하게 됩니다. 2주 전만해도 16개의 테스팅에 개발자들의 참여를 구했었는데 이미 다 끝이 났다니 앞으로 즐겁게 브라우저들의 발전을 지켜볼수 있을꺼 같습니다. 물론 즐거운지는 봐야 알겠지만 말이죠.

P.S. 이 100/100을 빠른 시일내에 볼수 있기를…