Starting on or about the third week of April, users still running IE6 or IE7 on Windows XP, Windows Vista, Windows Server 2003, or Windows Server 2008 will get will get a notification through Automatic Update about IE8.

IEBlog : Prepare for Automatic Update distribution of IE8

거의 8년 동안이나 웹의 뒷골목을 들쑤시고 다니던 IE6 패거리들의 씨를 말릴 시간이 다가왔다.
제발 이번 기회에 많이들 박멸되었으면 좋겠군.

정식 Internet Explorer 8 발표와 더불어 추가된 Compatibility View 기능으로, 이제 웹 개발자들은 자신이 개발한 웹 사이트가 이 Compatibility View List에 포함되었는지 수시로 신경쓰일 수밖에 없게 되었다.

사이트가 이 블랙리스트에 포함되어 있는지 알아보는 방법에는 IEBlog에 소개된 내용대로 두 가지가 있는데, 하나는 IE8의 주소막대에다 다음과 같은 주소를 입력하면 확인할 수 있다. res://iecompat.dll/iecompatdata.xml
또 하나는, xls 형태의 Excel 파일로 된 IE8 Compatibility View List 파일을 직접 내려받아서 확인할 수 있는데, 이 파일에는 도메인 이름과 함께 언제 사이트가 추가되었는지 그리고 삭제 요청이 다음 갱신 때 적용될 것인지도 확인 가능하다.

더 간편한 방법으로, 전에 소개했던 IE8 Compatibility View Blacklist Checker도 유용.
아래는 위 사이트를 이용해서 만든 bookmarklet으로, 웹 브라우저의 책갈피에 등록해서 사용할 수 있다.
➡ IE8 Compatibility View Blacklist Checker

결과가 YES라면 골치 아픈 거.

소통의 시도가 또 한번 무산되었다.
결국, 꽉 막힌 공간은 썩고 부패하기 마련인데, 곪아 터진 상처를 언제까지 그냥 모른체 할 것인가?

밤 늦게 잠들기 전 잠깐 뉴스 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