웹에 접속하는 장비의 다양한 화면 크기와 점점 높아지는 pixel density에 맞춰서 상황에 따라 적당한 이미지를 전달해 주는 일은 어렵지만 당장 해결해야 할 시급한 문제였다.

이 문제를 적절히 대처하고자 여러 개발자들이 responsive images의 문제에 대응하는 많은 방법을 제시하고 있지만, 각각의 장단점을 고려하기 이전에 어차피 과도기적인 꼼수에 지나지 않는다는 문제를 공통으로 안고 있다.

그래서 이 문제를 해결할 장기적인 표준안을 도출해 내려고 Responsive Images Community Group에 모여서 지금까지 제시된 다양한 방법에 대한 서로의 의견을 교환하고 가장 이상적인 방법을 도출하고자 머리를 맞대고 있는 사이, 이 문제를 해결해 줄 또 하나의 방법으로 며칠 전 Apple에서 WHATWG list에 제시했던 img의 srcset attributes이, 외부에서 보면 갑작스러울 수도 있게, WHATWG 표준 draft에 바로 추가되는 일이 발생하였다. 그래서 그동안 머리를 맞대고 고민했던 많은 개발자들을 발끈하게 만들었고, 다수의 지지를 받으며 새로 도출해낸 <picture> element가 그냥 무시되었다는 점에서도 큰 허탈감을 표시하고 있다.

이런 사태는 개발자와 WHATWG 간의 원만한 소통 창구의 혼돈에서 비롯되었다는 얘기가 나오는데, 지금까지의 진행 상황은 Jeremy Keith씨가 올린 글에 자세히 나와 있다.

과연 이제 막 HTML draft에 추가된 srcset attribute이 앞으로도 그 자리를 지킬 수 있을지 모르는 일이고 또 몇 번의 수정안으로 대체되겠지만, 그 사용법을 보면 다음과 같다.

<h1><img alt="The Breakfast Combo"
         src="banner.jpeg"
         srcset="banner-HD.jpeg 2x, banner-phone.jpeg 100w, banner-phone-HD.jpeg 100w 2x"></h1>

Responsive images를 위한 img element의 srcset attributes(이)란 제목의 글 마저 읽기 →

WHATWG Blog에서 전한 내용: WHATWG Weekly: Now it’s <time> for <data>

HTML5에 포함되었던, 주로 시간과 날짜를 마크업 할 때 사용되던, time element가 보다 폭넓은 데이터 형식에 대한 요구를 수용하기 위해 schema.org에 정의된 Microdata 용어를 사용하는 data element로 대치되었다는 소식.

이번의 변경을 가져온 처음의 제안 내용과 논의를 살펴보면 적지 않은 반대 의견도 살펴볼 수 있는데, 개인적으로도 time element가 소개되기 이전에 미리 이러한 논의가 이뤄져서 개발자의 혼란을 막았었으면 하는 아쉬움이 있다. (HTML5는 아직 Working Draft임을 감안하더라도.)

Spec에 나와 있는 data element의 사용법을 살펴보면, data element는 감싸고 있는 내용에 대한 기계적으로 해석되는 용도의 value attribute을 항상 포함하고 있어야 한다.

간단한 예로, data element를 써서 특정 시간을 마크업 한 예.

<p>Our first date was <data value="2006-09-23">a Saturday</data>.</p>

다음은 data element로 schema.org에 정의된 Microdata 용어를 써서 블로그 글이 작성된 날짜를 마크업 한 예.

<article itemscope itemtype="http://schema.org/BlogPosting">
 <h1 itemprop="headline">Small tasks</h1>
 <footer>Published <data itemprop="datePublished" value="2009-08-30">yesterday</data>.</footer>
 <p itemprop="articleBody">I put a bike bell on his bike.</p>
</article>

data-* attributes과 마찬가지로 문서에 저장된 다양한 형식의 정보를 data element를 써서 기계와 JavaScript가 접근하기 쉽게 해놓았다지만, 마크업 하기 간단명료했던 time element의 어쩔 수 없는 퇴장은 그래도 아쉽다. 아직 덜 똑똑한 기계 때문에 이런 혼란스런 상황이 벌어졌고, 그래서 더 부지런해야만 하는 것은 개발자들의 몫으로 남겨졌다.

덧붙임: time element의 완전한 삭제/퇴장/배제를 재고해달라는 공식 요청
결국 time, data element가 공존하는 방향으로 갈 수도 있을듯한데 어떻게 될지는 지켜볼 일.

덧붙임 2: 결국, WG 회원들 간의 충분한 논의가 없었음을 인지하고 이번 사건과 관련된 spec의 수정은 일단 보류되었다.

개인적으로, Safari(WebKit)를 주 웹 브라우저로 사용하면서 Safari 5가 Extensions 기능을 지원하기 시작한 후로 제일 먼저 기다렸던 놈이 있는데, 웹페이지의 (x)html 표준 검사 결과를 표시해주는 SafariTidy plugin이 Extension으로 나와주는 것이었다. 그런데, 오늘 드디어 요놈이 Safari Validator Extension 모습으로 공개되었다. 😈

설치하면, 확장 막대(extension bar)에 Tidy와 W3C 검사 결과를 함께 보여준다.

Tidy 검사 결과를 누르면 현 웹페이지의 소스와 함께 오류 부분까지 꼭 집어서 보여주어서 무척 편리하다.

그리고 W3C 검사 결과를 누르면 W3C validator가 생성한 보고서를 띄워 준다. 참고로, 설치 후 페이지 로딩 속도가 느려진 것처럼 느껴진다면 평소에는 설정에서 W3C 검사 기능만 꺼주면 된다고 함.

이제 HTML5만 더 무르익으면, 요넘까지 지원되길 바래야지. 🙂

현재 웹의 화두는 웹 어플리케이션으로의 진화라고 요약될 수 있을 것이다. 이를 아우르는 새로운 웹 표준으로 HTML5가 자리잡고 있는데, 여기에는 과거 데스크탑 어플리케이션의 전유물로만 여겨지던 여러 기술들을 거의 모두 아우르고 있다. 과거, 한 때 정체되어 있던, HTML4, XHTML1 그리고 DOM2 HTML 웹 기술들을 대체할 목적으로 새로운 틀이 만들어지고 있는 것이다.

그렇다면, 지금 당장 HTML5를 사용할 수 있을까? 해답은 바로 웹 브라우저들의 지원 상황에 달려있다.
공식적으로 발표된 HTML5의 W3C Candidate Recommendation 단계로의 진입은 일러야 2012년으로 예상하고 있으며, 현 브라우저들의 지원 상황도 그 편차가 심하지만, 대세를 그르치지 않는 이상 앞으로 상황은 급속도로 좋아지리라 생각된다.

또한, 당장 HTML5를 사용해도 별 큰 문제가 없는 것이, HTML5 태생부터 과거 호환성을 염두에 두었기에 큰 무리없이 점진적으로 새 기술을 흡수(Progressive Enhancement)하는데 유리하다는 점도 있겠다. 좀 더 자세한 브라우저들의 HTML5 기술 지원 상황은 When can I use… 페이지에서 확인할 수 있다.

자, 그럼 HTML5로 전환하기 전 챙겨야 할 사항들을 알아보자. HTML5로 한 발 더 내딛기 전에 챙겨야 할 것들(이)란 제목의 글 마저 읽기 →

항상 웹 개발자들은 IE 렌더링 엔진의 모자름을 아쉬워하며, 사용자들이 더 나은 웹 브라우저를 설치해주기만을 간절히 바라거나, 혹은 최소의 방어 장치로 셀 수도 없는 온갖 가지의 임시 대응 패취 코드를 여기저기 심어놓는 일로 스트레스만 쌓이게 되는 일은 하루 이틀이 아니다.

이런 와중에, Google에서 문제에 직접적으로 칼을 대는 제안을 내놓았다. IE 심장을 Google Chrome의 렌더링 엔진(WebKit)으로 바꿔치기를 하려고 하는 것이다.

솔직히, 문제의 근본을 뜯어고치는 해결책은 아니더라도 살짝 돌아서 갈 수 있는 기막힌 방법이 아닐까? 주장대로만 된다면 한 번 Google Chrome Frame을 설치해놓은 IE 사용자라면, Google Chrome의 탁월한 렌더링 엔진 덕분으로 HTML5를 포함한 더 많은 표준 웹 기술을 아무런 제약 없이 맛보게 될 수 있을 테니까.

그런데, 폭 넓은 웹 기술에 관심이 많은 사용자라면 애초에 IE로 웹 서핑을 하려 하지는 않을 것이기 때문에, 결국 Google이 의도한 것은 평소 웹 기술엔 관심이 없는, 그리고 불가피하게 IE 6에 묶여있는 사람들에게 일시적으로나마 특정 사이트에 사용된 웹 기술을 사용할 수 있도록 하는 일종의 통과 패스권을 나눠주는 격이 될 테고, 또 개발자들에게는 하나의 화끈한 한 방의 해결책으로 사용될 수 있는 선택권이 추가되어 고마운 일이겠다.

자, 그럼 IE 사용자가 이 요긴한 통과 패스권을 처음 받으려면 우선 마주치는 페이지가 있는데, 살짝 혼란과 거부감이 들지는 않을까? (물론, 플러그인 설치 후 원래 페이지로 돌아가긴 하겠지만 말이다.)

그림 속 보여지는 app은 Google이 준비중인 HTML5 기술을 이용한 야심작 Google Wave로 현재 Internet Explorer 6,7,8 모두 지원하지 않는다.

어찌 됐든 상황을 되짚어 보면, Microsoft가 열어 놓은 뒷 구멍을 통해 자신의 심장이 경쟁자의 것으로 통채로 바꿔치기된 형국이니, 앞으로 MS의 반응이 재밌어지겠군.