개인적으로 한국 사용자들을 위한 Dashboard Widget을 개발하면서 몸소 느끼고 체험했던 몇 가지 사실들을 적어놓고자 한다.
사실 하나.
대부분의 한국 웹 사이트들은 그 구조가 아직 XHTML 형태로의 전환을 이루지 못하고 있다. 따라서, widget에서 원하는 정보를 XMLHttpRequest Object를 사용해서 가져오는데 상당한 벽에 부딪히게 된다.
이것은, 필요한 정보를 XML 데이터 형태로 직접 접근할 수 없게 됨으로써, 클라이언트 쪽에서는 입맛에 맞는 Document Object Model(DOM)로의 접근과 수정이 차단되어 버린다.
결국, 차선책으로 XMLHttpRequest Object의 responseText 속성을 가지고서 원하는 정보에 접근할 수밖에 없게 되는 샘.
이쯤 와서, 그나마 막강한 힘을 발휘하게 되는 것이 바로 JavaScript의 RegExp Object이다.
물론, DOM 형태로의 유연한 접근과 수정이 불가능하고, 어쩌면 거치지 않았어도 될 불필요한 과정이겠지만, 어쨌든 원하는 정보를 그야말로 긁어올 수는 있다. 하지만, 여전히 아쉬운 것은 마찬가지.
사실 둘.
웹 표준 준수의 문제.
한국 대부분의 사이트는 표준 준수에 따른 이점들을 제대로 인식하고 있지 못하는 듯하다.
이것이 widget 개발과 무슨 상관이 있느냐고?
엉성한 구조로 된 웹 페이지로의 접근은 어떠한 user agent들에도 불리한 영향을 끼치기 마련이다.
사실 셋.
웹 정보 접근 용이성의 문제.
가끔은, 심한 경우 웹 사이트의 특정 정보가 Windows에서만 적용되는 ActiveX control 혹은 JScript (Windows Script Technologies) 등의 기술만 사용해서 전달되어 보이는 경우가 있다. 이렇게 되면 다른 플랫폼을 통한 정보 접근은 완전히 막히게 된다. 다른 길로 돌아가는 접근 방도가 전혀 없을 때에는, 다른 곳으로 눈을 돌릴 수밖에.
짧지만, 이렇게 해서 지금까지 적어놓은 내용을 한 문장으로 정리를 한다면, 불행하게도 “한국 사용자들을 겨냥한 widget을 개발하려면, 웹 표준의 파괴로 인해 생긴, 높은 장벽들로 둘러쌓여 진 정보에도 무사히 접근할 수 있는 여러 꼼수들에 단련이 되어 있어야 한다.“가 되겠군.
끝으로, 그나마 잘 갖추어진 한국의 인터넷 하드웨어 기반 환경에 걸맞은 잘 짜인 웹 사이트가 많이 늘어나길 기대하며…
웹 표준 – 단지 ‘테이블 없는 사이트’ 그 이상
웹 표준이란 말은 사람마다 다른 뜻을 지닐 수도 있다. 어떤 이들에게 이것은 ‘테이블을 안 쓰는 사이트’일 수도 있고, 또 다른 이들에게는 ‘표준에 맞는 코드를 사용하는 것’일 수도 있다. 하지만, 웹 표준이란 이런 것들보단 훨씬 더 광범위한 뜻을 내포하고 있다. 웹 표준에 맞게 제작된 사이트는 표준(HTML, XHTML, XML, CSS, XSLT, DOM, MathML, SVG 등)을 준수해야 하며 그에 따른 올바른 용례들(표준을 준수하는 코드, 접근이 쉬운 코드, 의미 구조론적으로 올바른 코드, 알아보기 쉬운 URLs 등)이 적용되어야 한다.
한 마디로, 웹 표준에 맞게 제작된 사이트란 군더더기 없고, 깨끗하며, CSS 기반에, 접근이 쉽고, 사용하기 쉬우며, 검색 엔진들이 색인하기에도 쉬운 사이트를 말한다. 웹 표준 검사 항목(이)란 제목의 글 마저 읽기 →
공공기관 사이트들을 포함한 한국 웹 사이트들의 심각한 웹 표준 규약 파괴현상을 몸소 체험하면서, (X)HTML 페이지의 첫 줄에 선언되는 DOCTYPE의 중요성을 다시 한 번 여기에도 기록해 두고자 한다.
World Wide Web Consortium (W3C)이 DOCTYPE의 중요성에 대해 강조하고 있는 것을 인용하면,
doctype을 추가해 주는 것을 잊지 마십시오.
뭘 추가해?
HTML에는 한 가지 형식만 있는 것이 아니고, 실제로는 여러 형식이 있는데, 여기에는 HTML 4.01 Strict, HTML 4.01 Transitional, XHTML 1.0 Strict 등 그 수는 여럿이랍니다. 이 모든 HTML 형식들은 각각의 W3C 규약에 정의되어 있으며, 기기가 읽을 수 있는 언어로서 HTML 형식의 적법한 구조와 구성 요소들 그리고 이러한 요소들의 해당 속성들로 정의되어 있습니다.
이러한 정의는 “Document Type Definition” 혹은 짧게 DTD라고도 불립니다.
HTML 문서들을 읽어들이는 웹 브라우저와 같은 도구들은 (X)HTML이 실제로 어떠한 DTD를 사용하고 있는지를 알아야 하고, 이것이 왜 (X)HTML 문서들의 맨 처음에 다음과 같은 DTD 선언문을 포함해야 하는지를 잘 설명해 줍니다:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
위에서 사용된 문법에서 보이다시피, DTD 선언문은 그냥 짧게 “Doctype”이라고도 불립니다.
그럼, 왜?
왜 DOCTYPE을 써야 하냐고요? 왜냐하면, 이것이 당신의 웹 문서가 어떤 버전의 (X)HTML로 쓰였는지를 정의해주고 웹 브라우저와 같은 도구들이 이 문서를 올바르게 읽어 드릴 수 있게 하기 위해서는 꼭 필요한 아주 중요한 정보이기 때문입니다.
예를 들어, 문서에 doctype을 지정해 두면, (X)HTML의 문법을 검사할 때 사용될 수 있는 Markup Validator와 같은 도구를 사용할 수가 있고, 그래서 기타 브라우저들에서도 올바르게 당신의 문서가 보일지를 확인해서 잘 못 된 오류들을 수정할 수가 있게 됩니다.
하지만, 무엇보다도 가장 중요한 것은 대부분의 웹 브라우저들이 doctype 선언문이 있음으로써, 불필요한 추측을 하게 만들지 않는다는 것입니다. 이것은, “표준” 분석 방식을 사용하게 하면서 문서가 화면에 표시되는 속도가 더 빨라질 뿐만 아니라, doctype이 없어서 생길 수도 있는 예기치 못한 문제들로부터 자유로워질 수 있습니다.
일반적으로, 웹 브라우저가 DOCTYPE이 선언되어 있지 않은 html 문서를 읽어들일 때는, 대충 짐작해서 읽어들이는 방식(“Quirks” mode)을 선택한다. (어쩌면 요새 개발/배포되는 웹 브라우저들이 너무 관대(?)해서 이런 상황이 고쳐지지 않고 있는지도…) 이렇게 되면, 브라우저는 옛날 90년대 말에 사용되었던 방식으로 웹 페이지를 해석하게 되며, 그야말로 대충 짐작해서 읽어들이게 되면서, 원래의 의도한 구조와는 다르게 페이지를 보여주게 되고 또한 브라우저마다 제각기 다른 결과물들을 표시해 줄 수밖에 없게 된다.
결국, 지금의 21세기에 와서도 그들의 HTML 문서에 DOCTYPE이 선언되어 있지 않았다면, 웹 표준을 깡그리 무시하겠다는 선언과도 같으며, 그 내용은 제쳐놓고서라도, 전달 방법은 20세기 과거의 것으로 남을 수 밖에 없다.
빨리 고쳐주세요! 😐
– 권장하는 추가 참고 글들
요새 폭설 피해 기사들을 보면서, 별 도움은 안 되겠지만, 뜬구름 widget에도 기상 특보 상황을 표시해 주는 기능을 추가해 놓으면 알맞겠다는 생각에 기상청 홈페이지를 살펴보았다. 물론 기상 특보 상황은 대문에서 바로 살펴볼 수 있으니, 문제는 이놈을 XMLHttpRequest Object로 끌어오기만 하면 되는 샘.
생각보다 쉬우리라는 기분으로 기능을 추가하고 뜬구름을 실행시켜 보았으나…감감무소식이다.
결국, 이런저런 궁리 끝에 console.log를 살펴보니, 다음과 같은 자국이 찍혀 있다.
[526] http://www.kma.go.kr/index.jsp:Error - DOM Exception 3
DOM Exception 3? 뭐지? Document Object Model Exception 3???
문제의 원인은, 기상청 홈페이지의 html 소스를 보면 금방 알아차리게 된다.
맙소사. !DOCTYPE은 물론이고 <html> 시작 꼬리표까지 없단다. (그렇다면, 맨 밑의 </html> 꼬리표는 실수로 붙었단 말이냐?)
정부 사이트들이 웹 표준 나 몰라라 하는 상황은 이미 알고 있었지만, 이 정도일 줄이야…
이것은 사이트 제작자의 실수 이전에, 기본을 지킬 수도 없는 무지에서 나온 결과랄 수 밖에 설명할 도리가 없다.
앞니가 빠진 꼬리표 덕분에, html 문서도 일반 글자 문서(plain text)도 아닌 어처구니 없는 상황인지라 XMLHttpRequest로는 원하는 정보를 끌어올 방법이 없다. (물론, 다른 꼼수는 있겠지만, 힘 빠지는 것은 마찬가지.)
그나마 아쉬운 마음에 대문에 쓰여 있는 국민으로부터 사랑받는 열린 기상청
이라는 문구 때문에라도, 소귀에 경 읽기 심경으로, 문의 게시판에 정정 요구를 해봤지만, Safari와 Firefox에서는 글도 올라가지 않는다. 참으로 징하다. 🙁
전자 정부 부르짖는 그들은 실로 대~충 그까짓 거 뚝딱 정부로세. 👿
또 다른 탄생을 준비하고 있는 대~충 그까짓 거 뚝딱 현장 방문하기 << 말이 디지털이지 그 속 내는 그까짓 거 대~충하는 섬세하지도 못한 아날로그이다.
현재 WordPress(버전 1.5.2)는 Atom 발신 신호로 0.3 버전을 사용하고 있습니다만, 이는 공식적으로 더 이상 지원되지 않을 것이라고 합니다. 뒤를 이을, Atom 1.0은 거이 완성 단계이며, 이제 곳 IETF 표준으로 인정받게 될 예정이라는군요.
발신 신호로 많이 사용되는 RSS 2.0도 있는데 왜 값자기 Atom 1.0 소리냐구요? 이 곳을 보시면 RSS 2.0과 Atom 1.0의 장단점을 잘 비교해 놓은 글이 있습니다. 더불어서, 선택할 수 있는 발신 신호가 여럿이라면 사용자 입장에서는 구미에 맞게 선택할 수도 있겠지요.
앞으로 발표될 WordPress 1.6에서는 Atom 1.0 발신 신호를 지원할 예정이라고 합니다만, 미리 Atom 1.0 발신 신호를 쏴주고자 하시는 분들에게 그 방법을 소개해 드리고자 합니다.
WordPress에서 Atom 1.0 발신 신호를 쏴주는 방법은 비교적 간단합니다.
우선, Atom 1.0을 위해 수정해 놓은 wp-atom.php 파일을 열어서 따로 복사 php로 저장하고, WordPress의 기본 디렉토리에 있는 원래의 wp-atom.php 파일에 그대로 대치해 놓습니다. 이렇게 하면, Feed Validator (Atom 1.0 발신 신호 인준 기능은 아직 실험중-BETA)를 사용해서 갱신된 Atom 발신 신호가 올바로 되어 있는지 확인하실 수 있습니다. (여기의 Atom 발신 신호는 Safari가 잘 낚아채기는 합니다만, 몇 가지 오류 문구들로 인해 아직 인준을 통과하지는 못 하는군요. 😕 )
마지막으로, WordPress의 theme 폴더 안에 있는 header.php 파일을 열고, Atom 발신 신호의 링크 관련 title 꼬리표 내용을 “Atom 0.3″에서 “Atom 1.0″으로 올바르게 바꿔주시면 되겠습니다.
물론, 이 곳처럼 표딱지에 Atom 1.0 발신 신호 그림을 달아두면 더 좋겠지요.
따옴 – dev.d10e.net
참고로, Rakaz씨의 Atom 0.3에서 1.0으로의 전환이라는 제목의 글을 읽으시면, 바뀐 Atom 형식에 대한 자세한 정보를 얻으실 수 있습니다.
갱신 – 12월 15일에 갱신된 wp-atom.php 파일을 받아서 설치하면, 드디어 Feed Validator의 표준 인증도 무사히 통과한답니다.