Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9, text/plain;q=0.8, image/png,*/*;q=0.5
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en) AppleWebKit/522.10.1 (KHTML, like Gecko) Version/3.0 Safari/522.11
드디어 Firefox에 이어 Safari도 제대로 된 XHTML 문서를 올바로 해석해서 보여주게 되었다.
W3C의 Internationalization Core Working Group에서 Internationalization Best Practices: Specifying Language in XHTML & HTML Content라는 제목의 문서를 새로 갱신해서 올려놓았다.
이 문서는 HTML 문서 내용을 다루는 저자나 프로그램 개발자들에게 세계 각국 언어에 맞는 현지화를 위한 일종의 안내서로서 사용될 수 있도록 관련 권고 사항들을 전해주고 있다.
문서 내용을 요약을 하면 먼저 HTML 문서에 사용 언어를 선언할 때 주의할 사항으로 character encoding과 글이 읽혀지는 방향(direction of text)을 언어 선언과 혼동해서 쓰지 말라고 경고하고 있다. Character encoding 값과 사용 언어는 일 대 일로 바로 적용될 수가 없는데, 그 이유로 어떤 하나의 인코딩 값이 여러 다양한 언어를 대표할 수도 있기 때문이다. 글이 읽히는 방향도 한 언어 안에서 문서 내의 문맥에 따라 서로 다른 방향으로 읽히고 해석되어야 할 필요가 생길 수도 있고, 대표 언어를 선언하는 것 만으로는 이런 상황을 제대로 표현해 줄 수가 없게 된다.
위 문서에는 웹 브라우저나 화면 해독기와 같은 user agents가 문서에 쓰여진 언어를 올바로 해석할 수 있도록 하기 위해 (X)HTML 문서 안에 사용 언어를 선언해 주는 대표적 방법들을 다음과 같이 소개하고 있다.
첫 번째 방법으로는 XHTML 요소에 lang과 xml:lang 속성을 사용하는 방법으로, 문서 전체의 언어를 지정할 경우 html 태그에 정의해 준다. 물론 문서 안에 포함되어 있는 특정 요소에 다른 언어가 사용되었을 경우에는 해당 요소에 따로 적당한 언어 속성을 지정해 줄 수도 있다.
보기 1: text/html mime type으로 전달되는 XHTML 1.0 문서 안에 언어 속성을 사용해서 선언해 준 예.
여기서 주의할 것은, HTML일 경우 lang 속성만 사용되며, XML로 전달되는 XHTML의 경우에는 xml:lang 속성만 사용한다.
두 번째 방법은 아래처럼 meta 요소의 http-equiv를 Content-Language로 지정해 주는 방법이 있다.
보기 2: meta 요소의 Content-Language 선언.
여기서 문서에 사용된 언어와 의도된 독자의 사용 언어가 여럿일 경우 각 언어를 모두 나열해 줄 수도 있지만, 문서의 언어 해석을 위한 용도로는 적절치 않거니와 아직까지 이 곳에 지정되어 있는 정보의 이용 상황은 극히 낮은 수준이다.
마지막으로, 언어 해석 정보는 문서와 함께 전달되는 HTTP header에서도 얻을 수 있는데, 이것도 대부분의 웹 브라우저들은 문서의 올바른 언어 해석을 위해서 이 곳의 정보를 참고하지는 않고 있다.
결과적으로, 지금까지는 첫 번째로 소개된 html 언어 속성을 이용한 방법이 HTML 문서의 언어 해석을 위해 가장 일관성있고 효과적인 방법이라 할 수 있다.
아래는 웹 문서에서 많이 쓰이는 대표적인 활자들과 그들의 올바른 HTML entities 표기이다.
웹에서의 활자 표시는 종이 인쇄 역사 보다 훨씬 짧은 이유로 제대로 된 활자를 표현하는 데는 비교적 더 많은 제약을 받지만, 그것이 불가능한 것도 아니고 단지 아직 잘 알려지지 않았을 뿐이다.
(여기서는 WordPress의 콩나물 따옴표 문제로 설치했던 Unfancy Quote Plugin 때문에 따옴표들이 밋밋하게 표시된다.)
참고 글:
아무 준비없이 그냥 뛰어든다면 그 코드는 물론 무참히 깨지고 말 것이다. 그렇기 때문에 항상 코드 속 HTML entities들과 겹치는 부분은 웹 상에서도 그대로 보여지도록 알맞게 고쳐주어야 한다. 악명 놓은 놈들로 >, &, <가 있지.
물론 간편하게 웹 상에서 준비 작업을 해줄 수도 있겠지만, 한글 사용에 약간 문제가 있고 서버와의 연결은 필수 조건이다.
단순한 작업이지만 매번 번거로워서 Dashboard 용 widget으로 만들게 되었다.
이름을, 약간 우습지만, 웹에 뛰어든 코드(Code Postable)로 지었는데, Dashcode Beta에서 탄생한 첫 위젯이지만 만드는 작업이 꽤 순조로웠기에 앞으로 발표될 정식 버전이 기대된다.
그나저나, 정작 위젯 1순위 후보에서 탈락한 온라인 문법/철자검사기가 utf-8를 지원해주면 좋으련만 아쉽군… 
제목은 말 그대로, 정확한 적용 시점은 아직 알려지지 않았으나, 차기 버전의 WebKit의 변화에 대비하기 위한 Dashboard Widget 개발자들이 취해야 할 조치사항이다.
Surfin' Safari의 Blog에 올려진 글에 의하면, 차기에 발표될 WebKit에서는 그 동안 HTML과의 호환성을 이유로 여러 요소들에 사용되었던 XML 형태로 된 단독 꼬리표 닫침 용법(예를 들어, <script src="myscript.js" />)들을 실제로 꼬리표가 적절하게 닫힌 것처럼 인식하게 하는 기능이 제거될 것이며, 따라서 이러한 꼼수(hack)들을 수정하지 않으면 해당 widget들의 스크립트는 코드가 실행되지 못하게 되면서 제대도 작동하지 않을 것이라고 경고하고 있다.
그래서, 차기 버전의 WebKit에서도 자신의 widget들이 제대로 작동되게 하려면, 단독 꼬리표 닫침 용법을 사용했던 <script>와 <canvas>의 경우 또 하나의 닫침 꼬리표를 추가해주어야 한다.
,
개인적으로, 앞에 공백 하나를 더한 단독 꼬리표 닫침 용법이 단지 HTML과의 호환성을 위한 하나의 hack이였다는 사실을 미쳐 눈치채지 못했다.
결국, Doctype!을 지정하였더라도 xhtml 문서를 application/xhtml+xml 혹은 text/xml MIME 형태로 서버에서 전달하지 않는 한은, 일반 html 문서일 수밖에 없다. 그렇다고, 웹 문서를 진정한 xhtml 형태로만 전달할 수는 없는 이유는 썩을 놈의 Microsoft Internet Explorer가 진정한 XHTML 문서를 전혀 다룰줄 몰라서 단지 문서 통채를 내려받기 때문이다.
이러한 상황에서, 굳이 xml 형태의 문서가 필요하지 않는 경우, XHTML을 가장한 HTML을 작성할 것이 아니라, 아직은 HTML4 형태의 문서로도 충분할 것이라고 말을 끝맺고 있다.
모든 웹 브라우져들이 아직 XHTML을 제대로 처리하지 못하는 과도기적 상황에서 웹 개발자들에게는 XHTML로의 완전한 이주는 험란한 일이겠지만, 과거에만 머물러 있을 수도 없는 노릇이다. 그래서, 정작 중요한 것은 단지 표준에 맞는 마크업(markup) 뿐만이 아니라, HTML4 시절에는 더딜 수밖에 없었던 내용으로부터의 표현과 동작의 완전한 분리, 웹 접근성 그리고 의미론적 마크업이 XHTML로 전진해야 하는 이유일 것이다.
위 내용과 관련해서 추가 참고가 될 만한 글들: