지금 웹 개발자들 사이에선 갑자기 터져나온 차기 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" />

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 파일이 등장하지 않았으면 한다.

얼마있으면 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 잔당들이지.

아래는 TextMate에서 제공하는 HTML의 기본 table snippet에 의해 삽입되는 코드이다.

<table border="0" cellspacing="5" cellpadding="5">
  <tr><th>Header</th></tr>
  <tr><td>Data</td></tr>
</table>

무척이나 단출하고 접근성을 염두에 둔 최소한의 요소들이 빠져있기 때문에 데이타 테이블을 짤 때 무심코 그냥 지나칠 수가 있다.
간단한 데이타 테이블이라도 접근성을 고려한다면 최소한 테이블 안에 caption 요소summary 속성을 추가하고 th 혹은 간혹 td 요소에는 scope 속성이 포함되어 있어야 한다.
그래서, 나름대로 수정한 table snippet (행의 갯수가 최소 4, 최대 7 기준):

<table id="${1}" summary="${2}"${4:${5: border="${6:0}"}${7: cellspacing="${8:5}" cellpadding="${9:5}"}}>
  <caption>${10}</caption>
  <thead>
    <tr>
      ${11:<td></td>
      }<th scope="col">${12:Table Header}</th>
      <th scope="col">${13:Table Header}</th>
      <th scope="col">${14:Table Header}</th>
      <th scope="col">${15:Table Header}</th>
      ${16:<th scope="col">${17:Table Header}</th>
      ${18:<th scope="col">${19:Table Header}</th>
    }}</tr>
  </thead>
  ${20:<tfoot>
    <tr>
      <th scope="row">${21:Table Footer}</th>
      <td colspan="${22:}">${23:Footer Data}</td>
    </tr>
  </tfoot>
  }<tbody>
    ${35:<tr>
      ${24:<th scope="row">${25:Header}</th>
      }<td>${26:Data}</td>
      <td>${27:Data}</td>
      <td>${28:Data}</td>
      ${29:<td>${30:Data}</td>
      ${31:<td>${32:Data}</td>
      ${33:<td>${34:Data}</td>
    }}}</tr>}
    ${0:}
  </tbody>
</table>

간혹 구조가 복잡한 데이타 테이블일 경우 scope 속성으로는 테이타 셀과 테이블 제목들과의 관계를 제대로 표현할 수가 없기 때문에 대신에 headers 속성을 써야 할 경우가 있는데, 현재 논의되고 있는 HTML 5.0의 표준 초고 문안에는 headers 속성이 포함되지 않을 예정이라서 개발자들 사이에 많은 논란이 되고 있다.

앞으로 headers 속성의 운명은 알 수가 없지만, 분명한 것은 지금 바로 적용될 수 있는 올바른 데이타 테이블의 구현 방법을 숙지하는 것이리라. W3C의 HTML 문서에 나와있는 화면 해독기를 고려한 Table 표현 방법이나 한 번 더 훑어보자.
데이타 테이블의 디자인 아이디어를 얻고 싶을 땐 Data Tables and Cascading Style Sheets Gallery가 도움이 된다.

W3C의 Internationalization Core Working Group에서 Internationalization Best Practices: Specifying Language in XHTML & HTML Content라는 제목의 문서를 새로 갱신해서 올려놓았다.

이 문서는 HTML 문서 내용을 다루는 저자나 프로그램 개발자들에게 세계 각국 언어에 맞는 현지화를 위한 일종의 안내서로 사용될 수 있도록 관련 권고 사항들을 전해주고 있다.
문서 내용을 요약하면 먼저 HTML 문서에 사용 언어를 선언할 때 주의할 사항으로 character encoding과 글이 읽히는 방향(direction of text)을 언어 선언과 혼동해서 쓰지 말라고 경고하고 있다. Character encoding 값과 사용 언어는 일대일로 바로 적용될 수가 없는데, 그 이유로 어떤 하나의 인코딩 값이 여러 다양한 언어를 대표할 수도 있기 때문이다. 글이 읽히는 방향도 한 언어 안에서 문서 내의 문맥에 따라 서로 다른 방향으로 읽히고 해석되어야 할 필요가 생길 수도 있고, 대표 언어를 선언하는 것만으로는 이런 상황을 제대로 표현해 줄 수가 없게 된다.

위 문서에는 웹 브라우저나 화면 해독기와 같은 user agents가 문서에 쓰인 언어를 올바로 해석할 수 있게 하려고 (X)HTML 문서 안에 사용 언어를 선언해 주는 대표적 방법들을 다음과 같이 소개하고 있다.

첫 번째 방법으로는 XHTML 요소에 langxml:lang 속성을 사용하는 방법으로, 문서 전체의 언어를 지정할 땐 html 태그에 정의해 준다. 물론 문서 안에 포함된 특정 요소에 다른 언어가 사용되었을 땐 해당 요소에 따로 적당한 언어 속성을 지정해 줄 수도 있다.

<!-- 보기 1: text/html mime type으로 전달되는 XHTML 1.0 문서 안에 언어 속성을 사용해서 선언해 준 예.-->
<html lang="ko" xml:lang="ko" xmlns"http://www.w3.org/1999/xhtml">

여기서 주의할 것은, HTML일 경우 lang 속성만 사용되며, XML로 전달되는 XHTML의 경우에는 xml:lang 속성만 사용한다.

두 번째 방법은 아래처럼 meta 요소의 http-equiv를 Content-Language로 지정해 주는 방법이 있다.

<!-- 보기 2: meta 요소의 Content-Language 선언. -->
<meta http-equiv="Content-Language" content="ko" />

여기서 문서에 사용된 언어와 의도된 독자의 사용 언어가 여럿일 경우 각 언어를 모두 나열해 줄 수도 있지만, 문서의 언어 해석을 위한 용도로는 적절치 않거니와 아직 이곳에 지정된 정보의 이용 상황은 극히 낮은 수준이다.

마지막으로, 언어 해석 정보는 문서와 함께 전달되는 HTTP header에서도 얻을 수 있는데, 이것도 대부분의 웹 브라우저들은 문서의 올바른 언어 해석을 위해서 이 곳의 정보를 참고하지는 않고 있다.

결과적으로, 지금까지는 첫 번째로 소개된 html 언어 속성을 이용한 방법이 HTML 문서의 언어 해석을 위해 가장 일관성 있고 효과적인 방법이라 할 수 있다.

추가 참고 문서: W3C I18N FAQ: Why use the language attribute?