어쩐지 뜸금없이 짠하고 나타난 Safari 4 Beta 1의 출현으로 무슨 새로운 기능들이 추가되었는지 관심을 모으고 있는 가운데, 우선 처음 설치하고 창을 열면 반기는 환영 영상 페이지가 인상적이다.

뜬금없는 궁금증에 페이지 소스를 살펴보니, 의외로 깔끔한 HTML 5의 Docktype이 눈에 들어온다. 찬찬히 살펴보면, 짧은 소개 영상 전체가 하나의 동영상이 아닌 CSS 3와 HTML 5 표준으로 이루어진, 그야말로 Safari 4가 새로 지원하기 시작한 신 웹 기술들이 서로 조화롭게 어울리며 뽐내고 있는 모습이다. 8)

여기에 사용된 모든 웹 기술들은 이번에 함께 문을 연 Safari DevCenter에서 자세하게 소개되어 있는데, 그 중 아래는 WebKit이 지원하는 CSS Reflections를 따라해 본 모습.

이제 막 꽃을 피우기 시작한 새로운 웹 기술들을 재빠르게 흡수해서 적용해주는 모습이 참 기특하긴 한데, 이런 추세가 다른 진영에도 전파되서 실제 웹 환경에 적용할 수 있는 시기가 빨리 찾아왔으면 하는 바램이다. 그건 그렇고, 왜 Squirrelfish라는 기존 JavaScript 엔진의 이름을 ‘Nitro’로 바꾼 이유는 몰까?

연초에 있었던 기상청의 개편으로 한 동안 멈춰버린 날씨 예보만 보여주던 바깥 날씨 위젯이, 이번 판올림으로 드디어 온전한 동네 예보를 지원하게 되었다. 8)
이번에는 동네 예보를 지원하기 위해 많은 부분을 뜯어고치면서 전국의 날씨 관련 지역 데이타를 모으는데만 지루하고 많은 시간이 소요되었지만 – 읍/면/동 동네 이름의 영어 주소 변환 작업은 결국 중간에 포기 😐 – 덩달아 전국 3,500 여개의 자세한 동네 날씨를 표시할 수 있게 된 것은 그나마 다행으로 생각한다.

위젯의 특성상 작은 공간 안에 다양한 날씨 정보를 효과적으로 표시해 줄 수 있는 방법을 찾다가 WebKit이 지원하는 CSS Animation 기능을 적용해서 JavaScript의 도움 없이도 멋진 애니메이션 효과도 구현할 수 있었다. 또한 공개된 글꼴들 중 Eraser Dust라는 놈을 CSS3의 Web Fonts 기능을 이용해 위젯에 심어놓으면서 칠판 배경에 잘 어울리는 날씨 정보를 표시할 수 있었고, 뿐만 아니라 곳곳에 사용된 CSS3에 정의되어 있는 border property들은 한층 만족스러운 디자인을 이끌어내는 데 많은 도움이 되었다.

아마도, 브라우저의 호환성 걱정 없이 새로운 웹 기술들을 마음껏 실험해 볼 수 있다는 것이 위젯 개발만이 주는 재미와 장점이 아닐까 생각된다.

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