이젠 Doctype Switch가 아니라 Version Targeting?

Web Standards 댓글이 없음 »

지금 웹 개발자들 사이에선 갑자기 터져나온 차기 IE8에서 처음 도입될지도 모를 소위 “Version Targeting”에 관한 논쟁으로 시끌거리고 있다.

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

이 웹 사이트는 IE X에 최적화되어 있습니다.의 부활?

당연한 얘기지만, 제대로 된 웹 개발자들은 웹 표준 규약을 준수하면서 접근성이 좋고 동시에 효율적이고 유용한, 그리고 점진적으로 확장 가능한(progressive enhancement) 웹 사이트를 개발하려고 하지 결코 특정 버전의 웹 브라우저만을 목표로 개발하지는 않는다고 믿고 있다. 그런데 이번 소식은 어쩌면 이런 믿음에 찬 물을 끼얹는 얘기가 될 수도 있다.

이런 얘기가 나온 것이, 앞으로 웹 표준 규약을 정말 잘 따르는 IE8을 발표하게 된다면, 현재 다수의 웹 표준을 무시하고 제작된 많은 웹 사이트들이 무참히 깨져 보이게 되는 현상을 막아보겠다는 의도로 이해되지만, 그 실제 구현 가능성이 의심스럽고 (IE8에 내장된 Time Machine?), 설령 이것이 그대로 구현된다고 하더라도, 위의 제안서에 의도된 대로 다른 웹 브라우저들에서도 똑같이 이번 version targeting 관련 meta tag가 구현되지는 않기만을 바랄 뿐이다. (다행히, 이미 WebKit에서는 version targeting을 구현하기 어렵다는 점을 밝혔다.)

이 소식을 듣고 가장 먼저 드는 의문은, 만약 이 meta tag을 완전 무시해서 개발된 지금의 사이트들은 IE8에서는 과연 IE6의 랜더링 엔진을 쓰게 될 것인가? 아니면 IE7? 짐작컨데, 이 경우는 또 Doctype switch에 따라 IE7(Standards mode)과 IE6(Quirks mode)를 오락가락 할 듯한데, 이렇게 되면 미래에 사용자가 아무리 더 똑똑한 웹 브라우저로 접속해도 해당 웹 사이트는 개발자의 손을 떠나 하나의 특정 랜더링 엔진에 묶여버리는 것은 아닌지?
몰론, 이것을 방지하기 위한 방법으로 한 줄의 meta tag를 추가해주고, 오래된 사이트의 경우 새로운 웹 표준 환경에 맞게 오래되고 잘못된 코드를 수정해주면 되겠지만, 과연 개발자의 주기적 유지보수가 지원되고 있는 웹 사이트는 얼마나 될 것이며, 어쩌면 웹 표준 나몰라라 하는 무지한 웹 개발자의 경우 이 version targeting을 역 이용해서 아예 자신의 웹 사이트를 자청해서 IE6에 묶어놓는 경우도 빈번할 것이다.

결국, 혁신에는 둔감해졌으나 시장 장악력을 최우선시 할 수 밖에 없는 MS가 독점적 위치에 있는 웹 브라우저의 자리를 앞으로도 계속 고수하기 위한 또 하나의 방어막이자 웹 표준으로 가기 위한 걸림돌로 밖에 보이지 않고, backwards compatibility를 앞세워서 현재의 웹 환경을 그냥 꽁꽁 얼려버릴지도 모를 일이다.

가장 우려되는 점은 이것이 실제 구현될 경우, 특히 IE의 독과점이 지속되고 있는 국내의 현실을 비추어 볼 때, 웹 표준화의 진척 속도는 더 느려질 수 밖에 없을 것이고, 어쩌면 웹 환경은 더 오랫동안 IE6 혹은 IE7에 묶여버리게 되리라는 예측이다.
더러운 먼지는 털어내야지, 진공 포장해서 고이 간직할 필요는 없지 않은가?

이번 제안을 몇 번씩 읽어봐도 장점이라고 예시된 backwards compatibility나 더 가속화될 IE의 웹 표준 기술 지원 주기(?), 개발시 특정 IE 버전을 위한 가상 머신의 불필요, 더 예측 가능하고 계획된 점진적 개발의 진행 등 여러 이점들 보다도, 이것이 가져올 더 심각한 부작용이 염려되는 것은 어쩔수 없다.

But wait, a lot of people say at this point, why isn’t this a problem for Firefox, or Safari, or any other browser? The answer is that developers of many sites had worked around many of the shortcomings or outright errors in IE6, and now expected IE7 to work just like IE6. Web developers expected us, for example, to maintain our model for how content overflows its box, even in “standards mode,” even though it didn’t follow the specification – because they’d already made their content work with our model.

IEBlog: Compatibility and IE8

그건 웹 표준이란 존재를 모르는 무지한 웹 개발자들의 불평이었겠지.

그나마, 이제 HTML5의 spec은 훨씬 더 명확해졌다는 소식은 들려오지만, 앞으로의 웹 개발 환경은 훨씬 더 복잡해지겠군. IE6 mode, IE7 mode, Super Standards mode… 😕

IE8에서 Super Standards mode를 원하세요? 그럼, 할 일이 하나 더 있군요. 아래의 meta tag를 추가하는 것도 잊지 마세요. 이제 Super Standards mode는 공짜가 아니랍니다! 아참, 요놈은 IE8 전용.

<meta http-equiv="X-UA-Compatible" content="IE=8" />
꼬리표:

IE7.js가 알파 딱지를 떼다.

CSS, JavaScript, Web Standards 댓글이 없음 »

IE에게 웹 표준을 잘 인식하도록 최면을 거는 IE7 JavaScript 라이브러리가 2.0(beta) 버전으로 갱신되었다. IE7.js v2.0(beta)의 자세한 갱신 내용은 개발자의 웹 블로그의 글에 올려져 있는데, 주요 내용은 다음과 같다.

  • 이제 IE7 프로젝트는 googlecode로 자리를 옮겨서 진행됨.
  • 이제 IE7은 모듈러(modular) 형태로 배포되지 않고, 크게 IE7.js와 IE8.js 파일로 분리되서 배포됨.
  • IE7.js는 실제 MSIE7 브라우저에 포함되어 있는 기능들만을 인식하게 고쳐줌.
  • 기타 모든 기능 개선은 IE8.js로 옮김.
  • IE7의 파일 크기 축소(11KB gzipped).
  • IE7의 실행 속도 향상.
  • blank.gif 파일을 제외하고 다른 모든 의존적 추가 파일들이 필요없게 됨.
  • Google 서버를 통해 IE7/IE8.js 파일들을 바로 링크할 수 있게 됨.
  • base64로 인코딩된 그림을 위한 기능 수정은 더 이상 포함되지 않음.

간단하게 각각의 IE 6와 IE 7 브라우저를 위한 기능의 분화가 있으면서 파일도 둘로 나뉘게 되었다.
실제 웹 페이지의 적용은 이제, 라이브러리 관련 파일들을 서버에 올려둘 필요없이, 간단하게 <head>에 다음과 같이 써주면 끝.

MSIE5-6 웹 브라우저를 MSIE7처럼 행동하도록 기능을 갱신하려면,

<!--[if lt IE 7]>
<script src="http://ie7-js.googlecode.com/svn/version/xx.x/IE7.js" type="text/javascript"></script>
<![endif]-->

또는, MSIE5-7 웹 브라우저를 포함해서 MSIE7가 지원하지 않는 몇몇 CSS selectors와 속성들을 인식하도록 하려면 다음과 같이 써준다.

<!--[if lt IE 8]>
<script src="http://ie7-js.googlecode.com/svn/version/xx.x/IE8.js" type="text/javascript"></script>
<![endif]-->

아무쪼록, 나중에 IE 8이 발표되면서 또 하나의 IE9.js 파일이 등장하지 않았으면 한다.

꼬리표:

Safari 3와 WebKit을 위한 웹 표준화 대비 지침 사항들

Apple, Mac & iOS, Notes, Web Standards 2개의 댓글 »

얼마있으면 Leopard 발표와 더불어 함께 공개될 WebKit 엔진에 기초한 Safari 3를 앞두고, Apple에서는 웹 표준에 기반한 웹 개발을 도모하기 위해 더 엄격해진 코딩 기술을 요구하게 될 예정이며, 이를 위해 몇 가지 웹 표준화 대비 지침 사항들을 공개하였다.

이미 잘 알려져 있다시피, 의도하지 않은 렌더링 오류를 피하려면 올바른 Doctype의 사용을 권장하고 있으며 CSS에서 색깔 지정시 hex 값은 항상 hash(#)로 시작할 것을 요구하고 있다. 또 특정 요소에 접근할 때는 그 요소의 id 값을 사용해서, document.getElementById('myInput')처럼 쓸 것이며, document.myForm.myInput과 같은 축약 용법은 name 속성이 지정되어 있을 때만 사용할 수 있다.

이 밖에도, 어떤 요소의 속성 값을 얻을 때 다음과 같은 축약 용법 대신에,

var target = document.getElementById('someID');
var targetTitle = target.title;

표준에 정의되어 있는 method인 getAttribute, setAttribute을 쓰라고 하는데, getAttribute method의 경우 실제 다른 브라우저들에서는 돌려주는 값이 상황에 따라 저마다 다르기 때문에, 어차피 이에 대한 대비도 필요할 것이다.

그리고 그림의 크기 지정과 관련해서, 보통 지정된 그림의 크기가 실제 그림 크기와 다를 경우 이미지의 크기는 자동적으로 조절되어 표시되는데 , 만약 이 차이가 한 쪽에서만 발생할 경우 어떤 브라우저에서는 실제 그림의 측면 비율을 무시하고 지정된 한 쪽 면의 크기만 조절되어 표시되는데, Safari 3에서는 CSS 규약에 나와있는 대로 가로 세로 측면 비율에 따라 양쪽 면의 크기가 함께 자동 조절되어 표시된다. 여기서 의도되지 않은 상황을 피하려면, 양쪽 가로 세로의 크기를 함께 지정해 주면 되겠다.

결국, 웹 표준 코딩의 중요성은 앞으로도 더욱 부각될 것이지만, 더욱 성가시게 된 것은 바로 IE 6 잔당들이지.

꼬리표: