Robert씨의 블로그에는 유능한 웹 인터페이스 개발자를 구할 때, 꼭 물어봐야 할 몇 가지 사항들을 적어놓은 글이 올라와 있다.

그 곳에 올려진 질문 항목들을 옮기면 다음과 같다:

• 왜 DOCTYPE이 중요한가?
• Quirks Mode, Almost Standards Mode 그리고 Strict Mode의 차이점은 무엇인가?
• 의미론적(semantic) 코딩이란 무엇이고, 이것이 왜 중요한가?
• 박스 모델(box model)이란 무엇인가?
• hasLayout의 문제를 설명하고 이것에 대한 대처 방법은?
• CSS에 정의되어 있는 한정성(specificity)이란 무엇인가?
• CSS에서의 float들은 어떻게 동작하는가?
• WAI란 무엇인가?
• 만약 글꼴 크기를 픽셀(pixels) 단위로 지정했을 경우, Internet Explorer에서는 어떤 문제가 발생하가?
• Internet Explorer에서는 alt 속성을 어떻게 처리하고 있으며, 결과적으로 어떤 부작용이 발생할 수 있는가?

대부분의 항목에 대한 질문과 해답은 이미 웹 상에서도 많이 논의되었던 것들이지만, Almost Standards Mode의 존재는 처음 알았다.
물론 위에서 던져진 질문들 중에서, Internet Explorer와 관련된 박스 모델과 hasLayout 문제 그리고 alt 속성 처리와 글꼴 크기 관련 문제는 Internet Explorer 7의 발표와 함께 험난했던 과거의 웹 개발 기록으로만 남게 될 듯하지만, 새로운 상황에 대처하기 위한 또 다른 골치거리들이 등장할 터이고, 따라서 의미론적 코딩과 웹 접근성에 관한 고찰 그리고 웹 표준에 대한 이해는 한결 더 중요하게 요구되어 질 것이다.

– 새로 덧붙임: 친절하게도 Robert씨는 자신의 블로그에 썼던 유능한 웹 인터페이스 개발자를 구할 때, 꼭 물어봐야 할 항목들에 대한 해답들을 올려놓았다. JavaScript에 대한 이해와 접근성에 끼칠 수 있는 폐해가 추가 덕목으로 더해졌다.

– 추가 참고의 글들

• Gecko’s “Almost Standards” Mode – MDC
• Exploring Internet Explorer – HasLayout Overview
• The alt and title attributes | 456 Berea Street

Margin들 간의 충돌이란, 웹 페이지 안 두 개 이상의 block box들이 위 아래로 교차해서 만날 경우 서로가 가지고 있는 margin 값이 하나로 합쳐지는 현상을 말한다.

그렇다면, 하나로 합쳐지는 margin의 너비는 어떻게 될까? 일상적인 흐름에서 생길 경우에는, 서로 교차하는 margin 값들 중에서 최대치의 margin 너비를 가지는 놈으로 대치가 된다. 둘 중에 하나가 0 이하의 margin 값을 가지고 있는 경우에는, 최대치의 margin에서 그 만큼을 뺀 값이 되고, 모두가 0 이하의 margin 값을 가지고 있을 때에는 0에서 두 값을 모두 빼게 된다.

이런 공식은, 물론 box들 간의 일상적인 흐름에서 충돌하는 경우에 적용되는 것이고, float된 상태이거나, overflow된 상태, 혹은 절대적 값을 가지고 위치하는 경우 등에는 이런 충돌이 일어나지 않는다.

결국, box 요소에 지정되어 있는 margin 값은 절대적일 수 없고, 다른 box들과 부딪힐 경우 테두리(border)를 둘러싸고 있으면서 언제든 상황에 따라 줄어들 수 있는 스폰지와 같은 보호막 구실을 하게 된다.

참고 글: W3C Working Draft – Box model – Collapsing margins

그런데, 위의 참고 글에 의하면,

The top margin of an in-flow block-level element is adjoining to its first in-flow block-level child’s top margin if the element has no top border, no top padding, and the child has no clearance.

그래서, box 자체는 위를 감싸고 있는 스포지가 없더라도 box 안에 담겨있는 하위 요소들의 스폰지가 box의 테두리 밖으로 돌출될 수도 있단다.
이런 돌출이 의도하는 상황이 아니라면, box의 top border 혹은 top padding 값을 지정하게 되면 밖으로 삐져나오는 부작용을 막을 수 있게 된다.

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

오늘 눈에 띈 신문 기사에는 미국의 Brown University에서 조사한 글로벌 전자정부(Global E-Goverrnment), 2006의 결과에서 한국 정부의 홈페이지가 198개국 중 1위를 기록했다고 한다.

내가 알고 경험한 것들에 의하면 결코 이런 결과가 나올 수 없는데, 과연 그렇다면 이런 결과가 어떻게 나올 수 었었단 말인가?

자세한 조사 내용이 담긴 Global E-Government Full Report, 2006(pdf)를 살펴보면 1위로 올라서게 된 과정을 알 수가 있다.

이 조사 결과에 따르면 한국 정부 홈페이지의 항목별 채점 결과는 다음과 같다.

결과를 보면, 전체 점수는 1위를 했어도, 항목별 점수는 초라할 정도로 심한 불균형을 이루고 있다.
아무리 홈페이지가 훌륭하고 풍부한 내용을 담고 있더라도, 장애를 가진 사람들이나 적은 수의 OS 사용자들에게 접근 자체를 가로막는 웹 접근성이나 기초적인 보안에 심각한 문제가 있다면, 이것은 결코 자랑만 할 일은 아니지 않은가?

조사 대상국들 중 1위를 했다는 사실만 강조할 것이 아니고, 절대적으로 부족한 면들을 개선하려는 노력이 꼭 필요할 것이다.

덧. 겉으로 드러나는 사실이 모든 것을 말해주지는 않는다.

오랜만에 IEBlog에 IE7에 적용될 CSS 변화들에 관한 환영할 만한 글이 올라와 있다.

여기에는 <!DOCTYPE> 전환에 의한 strick 모드 하에서만 적용되는, CSS2.1와의 호환성을 높이기 위한 거의 200 개 이상의 변화들과 개선된 사항들이 있을 예정이라고 한다.

물론 예전의 잘 못된 습관들에 의해서 개발된 사이트들은 이에 따른 수정도 불가피하게 되었지만, 수정에 필요한 도구들도 마련해 두었다고 하니 지켜볼 일이다.