Dashboard Widgets의 개발 도구로서 Mac OS X 10.5 Leopard부터 배포될 예정인 Dashcode의 베타 버전이 ADC 회원들에게 공식적으로 배포되기 시작했다.

물론, 아직 베타 버전이라 기능상으로 완전하지 못하며 Mac OS X 10.4와의 호환성을 위해 몇 가지의 제약이 있단다. 앞으로 Dashcode에 관한 새로운 소식은 Dashcode ADC 페이지에서 확인할 수 있다.

이미 오래 전에 우연하게 유출된 것과 비교하면, 기본적으로 제공되는 각 template들의 기능과 돌아가는 모습이 보다 안정적이어서 개발이 거의 마무리 단계에 있는 것 같고, 기타 개발 환경도 벌써부터 실제 widgets 개발과 디버깅에 커다란 도움이 되리라 생각된다.

오른쪽 그림에서 보여주는 것처럼, 이번 Dashcode beta 버전에서 기본적으로 제공하고 있는 widget template들 중에서 Gauge의 것은 아무런 수정 없이 바로 사용할 수가 있을 정도여서, 또 한번 Dashcode 개발 붐이 일면서 더 멋진 widget들이 쏟아져 나오리라 기대된다. 8)

W3C의 Web Application Formats Working Group은 미국 시간으로 어제(11.09) Widget 1.0의 첫 기초 표준안을 공개하였다.

이미, Web 기술은 웹 브라우져들의 영역에서 벗어나 Apple의 Dashboard나 Yahoo! Widgets Engine 그리고 Google Desktop 상에서 적용/구현되고 있으며, 앞으로 발표될 Windows의 Vista에서도 이러한 추세에 맞춰 Sidebar의 Gadgets이란 이름으로도 적용될 예정이다.
그런데, 이들 모두는 client-side Web 어플리케이션들로서 그 운용 기술은 같은 것이지만 배포와 적용 환경은 제각기 다르다. 하지만, Widgets 요구사항에도 밝혀져 있듯이, 이번 기초 표준안의 마련으로 과연 앞으로 widgets의 배포에서부터 시작해서 적용 환경까지 통합될 수 있을지는 지켜볼 일이다.

예쁜 아이콘들과 바탕 화면 그림들 그리고 맥의 아쿠아 인터페이스를 대체하는 여러 테마들을 모아놓은 InterfaceLIFT는 내가 자주 방문하는 곳인데, 마침 이 곳에 새로 올라오는 주제별 작품들을 Dashboard에서 바로 확인할 수 있도록 하는 InterfaceLIFT.com Widget이 Apple의 Dashboard Widget들의 소개 페이지에 등록되어 있다.

그런데, 쓰면서 한 가지 아쉬운 것이 있다면, 이왕에 편하자고 쓰는 거면 창에서 보여주는 아이콘들과 배경 화면 그리고 테마들 간의 선택을 뒤쪽 설정판까지 가서 설정해 줄 필요없이, 그냥 앞의 보여지는 창에서 바로 선택해서 볼 수 있다면 더 편하지 않을까?

목마른 사람이 우물을 판다고 (물론 제작자의 동의 없이), 뒤쪽에 있는 선택 메뉴를 앞쪽 판에도 추가하고, 덩달아서 메뉴 선택시 이미 선택되어져 있는 항목에 ✓를 올바로 표시해 주지 못 하던 벌레까지 잡게 되었다. 8)

이것도 물론 소스 코드가 완전히 공개되어 있는 widget의 개발 환경이 가지고 있는 장점 덕분에 가능한 일이다.

아무튼, 광적으로 widget들을 수집하는 습관 때문에 이미 Dashboard 화면에는 꽉 들어찬 모두 20개나 되는 widget들로 인해 더 이상의 자투리 공간마저 없는 실정이다. 이리저리 widget들의 자리를 바꾸어 주면서 남은 공간을 확보해 보려는 노력도 더 이상은 소용없을 지경이라서, 어쩌면 widget 수집광들의 필수도구라 할 만한 요놈을 설치해야 할 날이 올지도… 😛

제목은 말 그대로, 정확한 적용 시점은 아직 알려지지 않았으나, 차기 버전의 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?

평상시에는 바깥 날씨 widget에서 제대로 보여주던 몇몇 도시들의 날씨 정보가 오류를 내며 먹통이 되버리는 문제가 발생해서, 문제가 되는 도시들 중의 한 곳을 골라 기상청 주요 도시 예보에 있는 해당 도시의 페이지 소스를 살펴 보았는데…

무슨 짓을 했는지 아주 개판으로 만들어 놓았다. 👿

이건 도가 지나쳐서 어디서부터 손을 대야 할지 망막할 정도니…
참고 대처할 수 있는 꽁수에도 한계가 있단다! 젠장…

개판 오분 전이 아니라, 완전 개판이군!

6 시간 후의 기상 예측도 엉터리라고 욕을 먹고 있으니, 그들이 잘 하는 것은 과연 무엇이 있단 말인가? 👿