제목은 말 그대로, 정확한 적용 시점은 아직 알려지지 않았으나, 차기 버전의 WebKit의 변화에 대비하기 위한 Dashboard Widget 개발자들이 취해야 할 조치사항이다.

Surfin’ Safari의 Blog에 올려진 글에 의하면, 차기에 발표될 WebKit에서는 그 동안 HTML과의 호환성을 이유로 여러 요소들에 사용되었던 XML 형태로 된 단독 꼬리표 닫침 용법(예를 들어, <script src="myscript.js" />)들을 실제로 꼬리표가 적절하게 닫힌 것처럼 인식하게 하는 기능이 제거될 것이며, 따라서 이러한 꼼수(hack)들을 수정하지 않으면 해당 widget들의 스크립트는 코드가 실행되지 못하게 되면서 제대도 작동하지 않을 것이라고 경고하고 있다.

그래서, 차기 버전의 WebKit에서도 자신의 widget들이 제대로 작동되게 하려면, 단독 꼬리표 닫침 용법을 사용했던 <script>와 <canvas>의 경우 또 하나의 닫침 꼬리표를 추가해주어야 한다.

<script src="myscript.js"></script>, <canvas></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로 전진해야 하는 이유일 것이다.

위 내용과 관련해서 추가 참고가 될 만한 글들:

• Sending XHTML as text/html Considered Harmful
• Content-Negotiation Techniques to serve XHTML 1.0 as text/html and application/xhtml+xml
• Quick guide to XHTML – Anne’s Weblog
• XML.com: The Road to XHTML 2.0: MIME Types
• Mozilla Web Author FAQ – How is the treatment of application/xhtml+xml documents different from the treatment of text/html documents?

Safari가 사용하고 있는 오픈 소스 웹 브라우져 엔진인 WebKit의 개발 버전을 탑재한 웹 브라우져로 이름도 WebKit이라는 놈이 있는데, 이 WebKit 웹 브라우져를 위한 JavaScript debugger가 발표되었다.

Drosera라는 이름은 가장 큰 식충 식물류의 이름에서 가져왔다고. 😀

항상 Safari를 쓰면서 아쉬워 했던 것이 마땅한 debugger의 부재였는데 이로써 벌레 퇴치기의 아쉬움을 말끔히 씻을 수 있게 되었다.

Drosera의 사용자 인터페이스를 보면 얼마 전에 흘러나온 DashCode의 JavaScript debugger와도 무척이나 닮아있는 것이 흥미롭다. 또한 Desora의 90 % 이상은 HTML과 JavaScript로 짜였졌다고 하니, 웹 어플리케이션의 새로운 가능성을 보는 듯 하다.

WebKit에서 Drosera 벌레 퇴치기를 불러오는 법은 WebKit Nightly Builds를 내려받아 WebKit과 Drosera를 하드 디스크에 복사한 후, WebKit을 실행시켜서 JavaScript debugger가 필요할 때마다 Drosera를 실행시키고 File 메뉴의 “Attach…”로 WebKit에 붙여놓으면 된다. (아직은 자동적으로 debugger를 꺼내볼 수 없는 것이 아쉽다. 하지만 이미 Dock에 올려놓고 적당한 벌레 아이콘까지 입혀 주었단다.)

아울러, WebKit 개발 버전을 사용하면 웹 페이지의 구조를 쉽게 파악할 수도 있는, 보기에도 멋들어진, Web Inspector까지 덤으로 얻게 된다. 😉

화면 해독기(Screen Reader)에서도 잘 작동될 수 있는 Ajax 구현이라는 글에는 화면 해독기의 작동 원리와 그에 따른 적절한 Ajax 어플리케이션들의 구현 방법, 그리고 이러한 방법들을 적용한 몇 가지 예시들을 설명하고 있다.

하지만, 아직 자연스럽고 완벽하게 적용되려면 갈 길이 멀은 듯.
새로운 기술이나 최신 유행이라도 현재의 사용 습관과 환경에 적용되기란 결코 만만하지가 않을 것이다.

Prototype Window Class는 JavaScript class로 HTML 페이지에 특별한 창을 추가할 수 있게 해준다.
일반 Pop up 창들과 구별되는 점들은,

• 창의 크기 조절이 가능하다.
• 최소/최대 창 크기 단추.
• Modal 대화창.
• 여러 가지적 효과들.
• 사용자 마음대로 바꿀 수 있는 창의 겉모양.
• 기타등등…

이 class는 Prototype을 기반으로 하여, script.acuio.us 라이브러리에 포함된 특수 효과들을 사용한다.
그야말로, 무궁무진하게 뻗어가는 “웹 어플리케이션”의 진화를 엿볼 수 있다.

Prototype Window Class가 제공하는 여러가지 창들의 모양새 맛보기

만약 전체 개발자들 사이에 공유되는 만능 common.js 파일 같은 것이 있다면, 여기에 소개된 열 가지 (덤으로 하나 더) 함수들이 포함되어 있을 것이다. 이것들은 다용도 스위스 칼처럼 개발시 아주 유용하게 사용될 수 있는 것들이다. 이들 모두는 그 유용성이 이미 많은 사용자들로 인해 검증되었으며, 오늘날 가장 유용하게 사용되는 열 가지의 JavaScript 함수들이라 믿는다. 가장 많이 애용되는 열 가지 맞춤 JavaScript 함수들(이)란 제목의 글 마저 읽기 →

 없음.