밤 늦게 잠들기 전 잠깐 뉴스 feed를 훑어보다가 눈에 팍! 힘들어 가게 만드는 제목의 글을 발견. 😯

IE8 Blacklist: forcing standards rendering opt-in

이게 무슨 소리야? 분명 IE 8의 기본 렌더링 모드는 최신 웹 표준 모드로 동작할 것이라는 발표를 이미 밝힌 것으로 아는데, 얼마전 대충 읽고 흘려 두었던 IEBlog의 Compatibility View 소개 글을 다시 읽어보니 다음 구절이 하이라이트.

When users install Windows 7 Beta or the next IE8 update, they get a choice about opting-in to a list of sites that should be displayed in Compatibility View. Sites are on this list based on feedback from other IE8 customers: specifically, for what high-volume sites did other users click the Compatibility View button? This list updates automatically, and helps users who aren’t web-savvy have a better experience with web sites that aren’t yet IE8-ready.

Compatibility view improvements to come in IE8

결국, 특정 웹 사이트를 방문한 많은 사용자들이 IE8에 있는 Compatibility View 버튼을 누르게 되면, 이 기록들이 블랙리스트에 추가되면서 해당 사이트는 자동으로 IE7 Compatibility 모드로 보여진다고 하는 얘기. 문제는 아무리 사이트가 웹 표준을 준수해서 만들어졌더라도, 어쩌다 한 번 리스트에 올라가게 되면 해당 사이트의 top domain은 물론 subdomain들도 목록에 추가되면서 IE7 호환 모드로 보여준단다. 괜한 객기를 부렸다간 오해를 일으켜 큰 코 다칠 수도? 👿

이런 예기치 않은 상황을 미리 막으려면, 전에도 한 번 얘기되어 논란이 많았던, 완전 표준 모드로 동작하도록 하는 META tag이나 HTTP Header (X-UA-Compatible: IE=EmulateIE8 혹은 X-UA-Compatible: IE=Edge)를 추가하라는 얘기의 원점으로 다시 돌아오는데, 덩달아 Intranet 환경에선 Compatibility View 모드가 작동될 수도 있다니, 아직 정식 버전이 나오지도 않은 마당에 왜 이런 장막들만 자꾸 치려 하는 것인지 이해를 못하겠다.

Doctype, Conditional comments, Meta tags, documentMode, Compatibility View 버튼, Compatibility list, Internet/Intranet?… 과연 자신이 개발한 웹 사이트가 IE8 사용자의 모니터에는 정작 어떤 모습으로 비칠지 이젠 짐작조차 하기도 힘든 상황이 되고 만 것인가? 🙁

새벽에 괜히 이 무슨…

덧붙임: 혼란을 불러일으키고 있는 IE8의 Compatibility View에 관한 정리된 내용의 글이 올려짐.

이미 알려진 바와 크게 다른 내용은 없고,

• 설치시 Compatibility View 사용은 기본 설정이 아니라 사용자의 선택 항목이다.
• 블랙리스트에 올려진 WHOIS에 등록된 사이트의 주인에게는 메일로 이런 사실을 인지시키고 원하면 리스트 등록 삭제 과정도 함께 알려준다고 함.
• 블랙리스트의 목록은 IE 보안 업데이트와는 분리되지만 비슷한 주기로 갱신된다고 함.
• IE8 Compatibility View Blacklist Checker

이젠, IE8의 META Tag에 의한 표준/호환 모드 전환 설명 차트까지 등장할 지경이니, 이런 꼬인 상황의 해결책은 결국 그놈의 META tag 뿐일까?

HTML 5의 최신 동향을 전해주는 WHATWG Blog의 “The Road to HTML 5” 연재글 중 최근에 올라온 글을 보면, HTML 문서의 character encoding 관련 새로운 <meta charset> attribute을 소개하고 있다.

현재 HTML 문서의 character encoding을 지정해 주는 META 선언 방법은 다음과 같은데,

<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">

여기에, 이놈보다 한 단계 더 위의 우선권을 갖게 되는 놈으로 다음과 같은 용법이 새로 추가되었단다.

<meta charset="UTF-8">

굳이 또 하나의 character encoding 관련 META 선언 용법을 추가한 이유는,

The rationale for the <meta charset=""> attribute combination is that UAs already implement it, because people tend to leave things unquoted, like:
<META HTTP-EQUIV=Content-Type CONTENT=text/html; charset=ISO-8859-1>

Andrew Sidwell씨의 설명

(이미 대부분의 브라우저들에서 <meta charset>이 이미 적용되어 사용 가능한 것을 실험해 볼 수 있다.)
이렇게라도, 또 하나의 포장된(?) 길을 열어두어서 보안상의 나쁜 불상사가 일어나지 않도록 미연에 방지하자는 건데, 아무래도 가장 속편한 방법은 서버에다 다음 한 줄의 깔끔히 마무리.

AddDefaultCharset utf-8

추가 참고 문서 – HTML 5 differences from HTML 4

IE를 웹 표준과 호환되는 브라우저로 만들어주는 IE7 JavaScript 라이브러리와 JavaScript 압축 도구인 packer로 널리 알려진 Dean Edwards씨의 사이트 도메인이, 부주의에 의한 도메인 연장 실패로, 다른 사람의 손아귀로 넘어가 버렸다는 소식.

현재 사이트의 내용은 거의 그대로 옮겨져서 보여주고 있지만, 당분간 상황의 추이를 지켜봐야 겠군. 어쩌다 이런… 😕

갱신(2009.4.3): 이제서야 새로운 도메인으로 완전 이주했네요.
http://deanedwards.me.uk/

아래 한 줄의 코드 실행으로 Firefox 3(FF3), Firefox 2(FF2), Firefox(FF), Internet Explorer(IE), Safari(Saf) 그리고 Chrome(Chr)의 결과 값을 얻을 수 있다:

B=(function x(){})[-5]=='x'?'FF3':(function x(){})[-6]=='x'?'FF2':/a/[-1]=='a'?'FF':'\v'=='v'?'IE':/a/.__proto__=='//'?'Saf':/s/.test(/a/.toString)?'Chr':/^function \(/.test([].sort)?'Op':'Unknown';

퍼 나른 곳 = The Spanner – Detecting browsers javascript hacks

물론, 각 브라우저의 차기 버전이 배포되면 결과 값은 틀려질 수가 있으므로 사용에 주의를 요하지만, 종종 단순한 작업을 위한 긴급 처방으로 요긴할 때가 있다.

웹에서 넓리 사용되는 PNG 그림 형식에는 크게 두 종류로 나뉘는데 PNG-8과 PNG-24 버전이 있다. 물론 PNG-24 버전은 거의 완벽한 alpha transparency 재현이 가능하지만, 잘 알려졌다시피 IE 6에서 보기 흉하게 보이는 이유 때문에, 이를 해결하기 위한 몇몇 IE 6 PNG fix 관련 JavaScript 라이브러리들이 존재한다. 하지만, 기술적 의존도와 겹쳐저서 깔끔한 해결책이 될 수 없기에 찜찜함이 남는다.

이런 상황에서, 또 하나의 해결책이 될 수 있는 방법으로 Adobe의 Fireworks를 사용 여러 단계의 부드러운 alpha transparency가 적용된 PNG-8 파일을 생성하는 법이 주목받았지만, 문제는 다른 그래픽 어플리케이션에서는 이와 같은 방법을 그대로 사용할 수 없다는 것이 제약으로 다가올 수 밖에 없다.

그래서, 다른 방법을 찾아보다 위의 글에서도 잠깐 언급되었던 터미널 도구인 pngnq에 주목.
물론 Fireworks에서 저장하는 것처럼 언제나 휼륭한 결과물을 얻을 수는 없겠지만, 대부분 만족할 만한 효과를 낼 수 있어서 대체 방법으로 충분하다. pngnq 바이너리 파일은 여러 플랫폼들을 지원하고 있는데, 불행히도 정상적인 작동을 위해서 필요한 libpng가 Mac OS X에는 기본적으로 설치되어 있지 않아서, Mac에서 libpng 설치를 위한 간단한 패키지 인스톨러를 가지고 libpng 라이브러리 설치한 후, 내려받은 pngnq 바이너리를 /usr/bin이나 /usr/local/bin에 복사해서 사용.

pngnq 설명서를 보면 얼핏 복잡해 보이지만 기본적인 사용법은 상당히 간단하다:

$pngnq [input files]

터미널에서 위와 같이 입력하면, 원래 그림의 같은 디렉토리에, 이름 뒤 -nq8.png가 붙은 새로운 alpha transparency가 적용된 PNG-8 그림 파일을 얻을 수 있다. 변환 후 PNG 압축 도구를 이용한 후 처리도 필수.

헌데, 이렇게 IE6를 위한 꼼수들을 차곡차곡 모아 두어도 절대 개운한 기분은 아니군. 🙁