웹표준계에서는 꽤나 중요한 이슈이니 최대한 빠르게 전한다고 몽롱한 상태에서 마구 번역했습니다. 참고로 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을 빠른 시일내에 볼수 있기를…

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

“Beyond DOCTYPE: Web Standards, Forward Compatibility, and IE8″

성장은 언제나 진통이 따른다. 브라우저도 개발자들이 특정 브라우저나 툴에 맞추게 되면 유저들이 진통을 격게된다. 새로운 브라우저 버전들이 공개되고 몇개의 버그들이나 스팩의 약간의 변화에 사이트들은 깨지게 되고 상사나 유저들이 실망하게 되는 것이다.

몇시간을 들여 왜 사이트가 깨졌는지 설명할수 있겠지만 아예 처음부터 깨지지 않는다면 더 낫지 않겠는가?

약간의 배경

CSS의 상당한 업글을 보여주었던 IE7 의 공개에 힘입어 IE팀은 완전히 새로운 렌더링을 탑제한 IE8(CSS2.1 을 최대한 따른) 개발을 시작했다. 그리고 Acid2 렌더링 테스트를 완벽하게 통과하는 기염을 토해내었다. 이것은 IE가 곧 generated content 와 data URL 을 지원한다는 것 뿐만이 아니라 hasLayout 이 완전히 사라진다는 것을 의미한다. Acid2 를 통과한 사파리나 iCab, Konqueror 그리고 오페라와 렌더링에 있어서 동격을 이룬다고 할수 있다. (Firefox3는 Acid2를 통과했지만 아직 출시되지 않았다.)

이번 새 엔진을 개발하는 동안 IE팀은 IE7 을 공개하면서 받은 여러 비판을 잊지 않았다. 몇몇 표준 구루들과 Microsoft의 몇몇 팬들까지도 IE7 이 버그나 CSS 지원에 있어서 충분하지 못했다고 생각했었고 상당수의 개발자들은 IE7 에서 깨지는 사이트들을 바라보며 불신에 속삭였다. 이에 Roger Johanssen은 자신의 블로그에 IE가 깨지는 3가지의 이유를 나열했지만 IE팀은 4번째 이유까지 발견했다. CSS 레이아웃을 가능케 하는 중요 부분인 Doctype 이 호환성을 지키기 위해서 너무나 부족함을 말이다.

DOCTYPE 스위치는 깨졌다

1998년, Todd Fahrner 가 개발자를 위한 모드와 그외의 사람들을 위한 2개의 랜더링 모드를 가능케 하도록 제안한다. 컨셉은 간단했다. 유저 에이전트(ex 브라우저) 가 표준에 적합한 DOCTYPE 을 포함한다면 제작자가 표준작업을 제대로 알고 한 문서라는 것을 가정하고 “표준”데로(W3C 박스모델을 사용하여) 렌더링을 하는 것이었다. 반대로 DOCTYPE이 명시되지 않았을 경우, “quirks” 쿽스 모드로 인식하여IE5.x/Windows 의 비표준 박스모델로 렌더링 되는 것이다.

이 컨셉은 2년후 IE5/Mac 브라우저에 처음 적용되어 타 브라우저들에 빠르게 퍼져갔다. 표준을 조금이라도 인식하는 개발자들은 이미 ‘validation’ 의 목적으로DOCTYPE 을 삽입하여 사용하고 있었으며 스펙에 따라 렌더링하는 데에는 그 이상을 따르지 않았다. 표준을 상관치 않는 개발자들에겐 DOCTYPE 을 상관치 혹은 몰랐기에 문서가 특별한 모드로 렌더링 되고 있었다.

불행하게도 다음의 두 중요한 사실이 DOCTYPE 이 표준 모드로의 스위치로써 지탱되지 못하도록 하였다.

1. A List Apart 이나 Web Standards Project 등을 통하여 표준을 자각한 개발자들은 완전한 DOCTYPE을 슬슬 삽입하게 되었고
2. IE6가 6년간 렌더링에 변동이 없었으므로 많은 개발자들이 자신들이 맞다고 생각 하게 되었다.

이 두 상황이 Doctype 스위치를 악화한 치명적인 이유는 개발자들이 Doctype을 맞게 쓰는 것이 표준을 올바로 이해하고 렌더링을 제대로 하는 것일 꺼라는 ‘가정’을 했기 때문이다. 왜 실패했는지 어떻게 아느냐고 묻는다면, 바로 IE7이 공개되었을때, 사이트들이 깨진것을 보면 알수 있다.

물론 Roger가 지적했듯이 IE6에 국한된 CSS 핵을 사용했기 때문이기도 하다. 하지만 대부분은 IE6 에서만 사이트 렌더링을 확인한 이유이거나 혹은 가장 많이 사용되는 대표적인 IE6에서만 잘 보여진다면 괜찮다고 생각했기 때문이다. IE6의 불완전함은 문서로 잘 나타나져 있었으니 개발자들이 좀 알고 있었어야 한다고 할지 모르지만 많은 개발자들은 “표준 모드” 의 옵션이 주어지지 않았거나 아예 그 존재조차 모르고 있었다.

IE의 플랫폼아키택인 Christ Wilson 은 IE의 개발의 핵심은 웹을 깨트리지 않는 것이라고 자주 이야기 하곤 했다. 하지만 슬프게도 IE7 은 많은 이들에게 바로 그것을 행해버리고 말았다. 똑같은 실패를 거듭하지 않고자 Microsoft는 Web Stands Project (저자 또한 멤버이다) 와 여러 표준을 인식한 개발자들에게 앞으로 개발자들이 올바른 표준을 준수할수 있도록 도울수 있는 방법에 대해 도움을 요청했다. 목표는 DOCTYPE 스위치 보다 더 뚜렷하며 IE뿐만이 아닌 여러 브라우저들에서도 적용이 가능한 ‘방법’ 을 찾는 것이었다.

완벽을 바라는 미래

작년 SXSW 에서 나는 운좋게도 뉴욕 공립 도서관의 Carrie Bickner 가 진행하는 토론회를 보게되었다. (Carrie Bickner, A List Apart의 Jefferey Zeldman의 부인) “디지털 유산과 Individual Collector 의 보호” 라는 주제 아래 도서관들과 개개인들이 디지털 아카이브를 유지하며 격는 문제점을 토론하고 있었는데, 대부분의 문제들은 꾸준히 업그레이드 되고 있는 파일 포멧들과 어플리케이션들에서 비롯된 것들이었다. Microsoft 오피스 2007을 예로 들면, Word1.0 버전의 문서를 그 당시 의도 했던 것처럼 렌더링, 보여주지 못한다는 것이다. 이 토론회는 나로 하여금 지금까지 웹이 얼마나 변해왔으며 앞으로 웹이 진화하며 얼마나 변화할 것인가에 대해 생각하게 하였다.

웹표준의 지지자의 한사람으로써 브라우저들의 꾸준한 발전과 함께 표준 이행을 꾸준히 개선하기를 원하지만 힘들게 만들어온 웹(테이블 레이아웃 조차도)을 보존하는 것 또한 중요하다고 생각한다. 아직까지는 Doctype 스위치가 괜찮게 돌아가니 그다지 “뒤로돌리는것” 이 어렵지 않겠지만 IE6 의 “표준” 에 맞춘 사이트는 어찌할 것인가? 많은 경우 IE7 이 제대로 렌더링 하지 못한다는걸 우리는 이미 잘 알고 있다. 그렇다면 저자가 원한데로 페이지를 보기위해서는 IE6 브라우저를 언제나 하나씩 가지고 있어야 한다는 말인가? 바로 그것이 수많은 도서관들이 옛 파일들을 보기 위해서, 보존하기 위해서 택한 방법이다. IE8이 점점 다가 오고 있는 가운데 IE7의 렌더링 엔진에 맞춘 문서들이 갖게될 문제들은 앞의 도서관들과 별반 다를 것이 없다. 과연 무엇이 해답인 것인가?

브라우저 버전에 맞추기

이상적인 세상에선 모든 스펙들이 시작에서 부터 유저에이전트들의 해석, 이행까지 완벽할것이다. 그보다 약간 덜 이상적인 버전의 세상에선 브라우저 밴더들이 꾸준히 업데이트 되는 표준들을 즉시 유저에이전트(브라우저)에 적용하여 유저들이 손가락 까딱 하지 않고 최신 버전의 브라우저를 사용 가능토록 할 것이다. 우리 개발자들 또한 최신의, 최고의 기술들을 사용하여 이전 버전 호환성의 걱정 없이 사이트나 어플들을 개발 할 것이다. 하지만 모두가 알다시피 우리의 현실은 그정도 레벨의 완벽에도 가깝지 않다.

표준은 힘들게 개발되고 발전하여 가끔은 몇년씩 걸려 “권고안” 에 상태에 이른다. 브라우저 공개의 사이클은 상품개발이나 마케팅 (보안, 기능 속도등) 과 긴밀하게 연관되어 벤더들이 표준에 직접 참여함에도 불구하고 표준 스펙의 준수는 먼 이야기가 되기 십상이다. 그리고 유저들은 특히 공공기관이나 회사들은 브라우저 업그래이드가 절대 빠르지 않다.

이 모든 요인들은 우리 웹개발자들을 사이트를 제작함에 있어서 곤란하게 한다. 우리가 원하는데로 브라우저가 보여준다는 보장이 어디있단 말인가?

CSS2.1이나 JS1.5 등의 언어의 버전을 명시하는 방법도 있긴 하다. 하지만 불행하게도 브라우저 벤더들은 몇몇 부분들의 스펙들을 적용하며 브라우저들 간의 해석이 다르기도 하니 두개의 동급의 브라우저들 에서 같은 CSS 인데도 완전히 다른 렌더링을 보여주기도 하며 같은 컨트롤이지만 완전히 다른 이벤트를 연출하기도 한다.

이러한 상황 가운데 우리 개발자들에게 주어지는 게런티, 보장, 5년 후나 지금이나 똑같이 해석될수 있는 옵션은 한가지 밖에 없다. 개발 배경이 된 브라우저들 리스트를 명시하게 한 후 해당 브라우저들을 이전 버전들도 지원케 하여 개발자가 원래 계획했던 모습들이 현재 뿐 아니라 미래에도 렌더링 되도록 하는 것이다.

이것이 바로 우리 그룹이 IE8에 제안하기로 결정한 것이며 타 브라우저들에도 적용되기를 바라는 것이다.

syntax 를 간편하게

이 “버전 지정”을 개발자들이 브라우저에 적용함에 있어서 중요하다 생각했던 부분중의 하나는 하드코딩이나 프로그램에 사용함을 쉽게 적응 할수 있도록 하는 것이었다. Conditional 코멘트나 XML 프롤로그, 혹은 HTML 프로필 형식등의 여러 syntax 옵션들을 고려해 보았고 그중 META 메타 엘리먼트 만큼 역할을 잘 수행하는 것이 없었다.

간단한 meta 선언을 삽입하여 우리는 IE8 이 어떠한 렌더링 엔진을 사용하는지 지정할수가 있다. 예를들어 이것을 head 부분에 삽입하면

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

IE8에서 새 “Standard Mode”를 사용하여 렌더링 하게 된다. 이 방법은 쉽게 다른 브라우저들도 포함할 수 있다.

<meta http-equiv="X-UA-Compatible" content="IE=8;FF=3;OtherUA=4" />

이 지정법을 쉽게 설명하자면 이 meta 엘리먼트를 사용을 character 인코딩을 지정해 주는것과 같은 방식이다. 이 “버전지정”이 작동하기 위해서는 meta 엘리먼트가 head안에 최대한 상위에 위치해야 하고 타 메타 엘리먼트나 타이틀 엘리먼트가 상위에 위치할수 있으나 타 엘리먼트들 보다 아래에 위치하면 안된다.

요목조목 살펴 보신 분들은 HTTP-equiv 형을 사용한것을 아셨을 것이다. 이 뜻은 서버쪽 해더에도 다음의 삽입시에 같은 효과를 볼수 있다는 것이다.

X-UA-Compatible: IE=8;FF=3;OtherUA=4

또한 함께 사용할수도 있다. 예를들어 header 방법으로 기본락을 전체 사이트에 적용시킨 후에 각각의 필요한 페이지에 meta 엘리먼트를 사용하여 적용 시키는 것이다.

Progressive enhancement은 어디로?

특정 브라우저 버전에 지정하는 “버전지정”은 미래까지도 확실한 사이트 렌더링의 보장이 있지만 그렇다면 progressive enhancement(1)의 콘셉을 깨뜨리는 것일까? 앞으로 우리가 사이트를 만드는 방식을 바꿔야 하는 것일까? 최신 CSS 속성들이 유효할때 즉시 사용할수 있는 것인가 말이다. 이 질문들은 우리가 처음 “버전명시” 를 논의할때 갖고 있었던 많은 질문들 이었다.

예를들어 IE8이 generated content(2) 을 지원하지 않는다고 한다고 가정한 후 (Acid2를 통과한만큼 지원하지만 그저 예를 든것임) IE8을 지정하여 generated content 를 사용한다면 IE외의 타 최신 브라우저들에서는 generated content가 보여질것이고 IE9가 generated content를 지원하더래도 사이트는 IE8에 지정되어 있기에 볼수 없을 것이다. 이 사이트에 “지정” 되어 있는 정보를 IE9로 업데이트 해야 비로소 generated content를 볼수 있는 것인데, 이것은 progressive enhancement의 코어 컨셉을 역행 하는 것이다.

이 progressive enhancement 부분을 포기해야 한다는 것이 상당한 고통인만큼 이 지침은 어찌보면 public-facing 임을 감안할때 최선일지도 모른다. 앞으로 브라우저들이 어떻게 작동할 것인지에 대한 “가정”을 내리면 안되기 때문이다. IE9로의 변화가 조금이라도 사이트의 레이아웃을 깨뜨리거나 스크립트의 지침의 해석을 바꾸게 된다면 유저들에게도 재난일 뿐 아니라 새 브라우저가 나오기전에 잘 보이던 상태로 돌리기 위하여 개발팀 또한 고생해야 할것이다.(이것이 현재 웹의 상태이기도 하다) “버전지정”은 개발팀이 원할때, 새 브라우저에 맞추어야 겠다고 결정을 내렸을때, 특히 새 브라우저 버전에 맞출 시간을 우리 팀이 정하여 원하는 만큼의 시간을 맞추고(새 브라우저 출시 시간에 맞추지 않고) 작업에 착수할수 있다.

그렇다면 “버전지정”은 progressive enhancement의 끝을 말하는 걸까? 현재로써는 no, 아니다. 일단 “버전지정”이 포함되지 않은 버전들의 브라우저들을 앞으로 몇년간 써야 하고 progressive enhancement은 여러 레벨의 CSS와 JS 를 지원하는데 필요한 방법이기 때문이다. 더 나아가 conditional 코멘트를 사용하여 스타일을 구현하고 스크립트를 덧붙여 IE 브라우저들을 사용하는 것을 몇년간 더 해야하기 때문이며 마지막으로 Progressive enhancement 테크닉을 사용한 JS 는 새 브라우저를 준비하는데에 재코딩의 시간을 줄여주기 때문이다.

보너스: “edge”

위험을 감수하며 무모함을 즐기는 이들을 위하여 IE는 “edge” 라는 값을 제공하기로 했다.

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

이 옵션은 권장하지 않으며 사이트를 가장 최신의 IE브라우저로 렌더링을 지정하는 방법이다. IE=1000 이라는 편법을 써서 최신 IE 브라우저를 지정 하는 것 보다는 깨끗한 방법이지 않은가? 하지만 실험용 사이트에 적용 하는것 말고는 edge값을 적용 하는 것은 그리 실용적이지 않을 것이다. 이유는 Eric Meyer 라고 해도(렌더링의 지존) 새 브라우저가 가지고 올 레이아웃이나 스크립트 버그들을 예상할수 없기 때문이다.

미래의 희망

오랫동안 우리 디자이너들과 개발자들은 사이트를 제대로 출력이 가능한 신뢰할수 있는 방법을 고대하고 있었다. 크로스 플랫폼이 가능한 스타일과 스크립트를 짜야하는 두통에다 새 브라우저의 출시와 함께 손도 대 보지 못한곳이 깨지는 아픔을 견뎌야 하고 우리의 클라이언트들과 보스, 그리고 유저들에게 예상치 못한 곳이 깨지는 원인을 설명하는것이 절대 즐겁지도 않다. 하지만 IE8 의 버전지정의 소개와 함께 터널끝에 희망의 빛이 보인다. 나는 다함께 타 브라우저 벤더들도 마이크로소프트와 뜻을 같이 하여 이 기능을 적용했으면 하는 바램이다.

1. Progressive Enhancement - 기본 컨텐츠와 기본 기능들이 모든 브라우저들과 모든 이들에게 접근이 가능케 하며 접근성, 시멘틱 마크업 그리고 외부 css 와 스크립트를 강조하는 컨셉이다.
2. Generated Content - 생성된 컨텐츠. 예를들어 :before나 :after 를 사용하여 컨텐츠를 브라우저가 직접 생산하는 것을 일컫는다.

defaults write com.apple.Safari \
WebKitDeveloperExtras -bool true

오른쪽클릭시 Inspect Element 메뉴가 하단에 나타남.

최근들어 없으면 안되는 사파리 기능이 되어버렸다.
여태 쓸모없다가 왜 이제서야 눈에 띄는건지…

특히나 로딩타임과 양을 그래프로 보여주는 ‘Network’는 내 친구.