blockquote element는 원래 다른 곳에 있는 소스 일부를 인용해서 표시할 때 사용되는 요소로, 인용한 해당 소스의 주소는 보통 cite attribute에 넣어서 표시해 주게 된다.
그런데 여기서 문제가 되는 점은 cite attribute에 포함된 소스는 기본적으로 해당 문서를 해석하는 user agents에게만 인식되고, 일반 사용자에겐 전혀 노출되지 않기 때문에, 이 정보를 제대로 표시해 주려면 CSS 혹은 JavaScript의 힘을 빌려 밖으로 끄집어내서 그냥 일반 텍스트로 보여줄 수밖에 없었다.
이런 바람직하지 않은 상황을 해결하려고 아래에 표시된 코드처럼 blockquote 요소 안에 <footer>를 써서 인용 소스를 표시해주는 방법이 제안되기도 했으나, 표준에 들어맞지 않는 사용으로 Spec Editor로부터 거부되기도 하였다. (참고로, 최근에 이를 다시 허용해 달라고 요구하는 제안이 보고되었음.)
<blockquote>
<p>The <code><span class="pln">blockquote</span></code> element represents a section that is quoted from another source.</p>
<footer>— <cite><a title="4.5 Grouping content — HTML5" href="http://dev.w3.org/html5/spec/grouping-content.html#the-blockquote-element">W3C HTML5 specification</a></cite></footer>
</blockquote>
대신 HTML 표준 문서의 blockquote element를 설명해 놓은 부분을 보면 이와 관련 권장되는 마크업 방법론으로 figure, figcaption 요소를 함께 쓴 다음과 같은 것이 예시되어 있다.
blockquote 요소가 맞닥뜨린 위기 상황(이)란 제목의 글 마저 읽기 →
HTML5에선 근래에 그 쓰임새가 더욱 다양해진 여러 형태의 웹 문서나 웹 애플리케이션의 사용 패턴에 부응하려고 기존 elements의 확장 개념으로 좀 더 명확한 구조적/의미론적 정의를 부여하는 새로운 elements가 추가되었다.
그래서 그 쓰임새에 맞는 적절한 elements를 가지고 HTML 문서를 작성하면, 저자가 의도한 대로 그 의미가 제대로 전달되면서 더불어 다양한 웹 접속 장비에서의 해석도 훨씬 수월해지기 마련이다.
문제는, 웹 브라우저가 새로운 elements에 대응하는 Accessibility APIs를 아직 제대로 적용하지 못하고 있는 실정이다. 결국 웹 접근성을 고려해서 WAI-ARIA에 근거한 적당한 ARIA landmark role을 직접 지정해 주어야 하는데, 마침 W3C에서 HTML을 작성할 때 WAI-ARIA를 올바로 구현하는 법에 대한 안내 문서(W3C Editor’s Draft )를 공개하였다.
이 문서에서 ARIA role을 적용해야만 하는 HTML5 elements와 해당 element에 지정해 주어야 하는 기본 ARIA role을 간추리면 다음과 같다.
ARIA role을 적용해야만 하는 HTML5 elements(이)란 제목의 글 마저 읽기 →
거의 막차를 탄 갑작스러운 느낌으로 <main> element가 HTML5 확장 spec의 draft 문서에 추가되었으며, 조만간 HTML 5.1 spec에도 추가될 예정이란다.
이름에서 알 수 있듯이, main element는 문서 혹은 앱의 주요 내용을 감싸는 용도로 사용되는데, 과거에 주로 <div> element에다 id 값으로 ‘content’ 혹은 ‘main’을 줘서 주 내용을 감쌌던 것을 공식적인 main element로 대체하면 되겠다. 이렇게 하면 지원 브라우저에선 WAI-ARIA landmark 중 하나인 role=main으로 자동 인식된다.
사용할 때 주의할 점은, main element는 sectioning content가 아니므로 문서 outline에 어떠한 영향도 끼치지 않으며, 문서에는 하나의 main element만 추가할 수 있고 또 article, aside, footer, header 혹은 nav element 안에 존재할 수 없다.
HTML5의 main element(이)란 제목의 글 마저 읽기 →
웹에 접속하는 장비의 다양한 화면 크기와 점점 높아지는 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(이)란 제목의 글 마저 읽기 →
IE6,7,8에게 새 HTML5 elements를 인식시켜주는 html5shiv를 문서에 추가하는 방법으로 보통 head에서 다음과 같이 불러온다.
문젠 그냥 이렇게 html5shiv를 googlecode에서 불러오면 성능상 별로 안 좋다는 얘기.
이렇게 추가된 script는 HTTP compression 되지도 않았거니와 CDN을 사용하면 당연히 얻겠거니 하는 cache 적용도 되어있지 않다. (현재 겨우 180초뿐이다.)
더군다나, 현재 공식 배포 채널로 사용되긴 하지만, 버그도 잡고 성능이 향상된 최신 버전으로의 적용도 더뎌서 github에서 활발히 개발되고 있는 html5shiv의 최신 버전(현재 Tag 3.5)을 내려받아 compress(minified)한 후 직접 호스팅하는 편이 여러모로 더 이롭다는 얘기.
참고로, Modernizr를 쓴다면 이미 core에 포함되어 있기 때문에 따로 추가할 필요는 없으며, 최신 버전도 곧 적용될 예정이란다. 끝으로 “절대 다른 사람의 source code repository에 있는 리소스에 직접 링크를 걸지는 마라”는 경고로 말을 맺고 있음.