한국 철도 공사 웹 페이지와 HTML 주석문

[빛알갱이]

한국 철도 공사 웹 사이트의 첫번째 페이지 (http://www.korail.go.kr)가 완전히 망가져 보이는군요. 다른 페이지는 문제 없는데, 첫번째 페이지만 문제가 있습니다.

이유는? 약간 어이 없게도 comment 문법을 안 지켰기 때문입니다. HTML 4.01 문서에 보면 다음 구절이 있습니다. (영어 원본: http://www.w3.org/TR/html4/intro/sgmltut.html#h-3.2.4
한국어번역 : http://trio.co.kr/webrefer/html/intro/s ... ml#h-3.2.4)

3.2.4 Comments

HTML comments have the following syntax:

<!-- this is a comment -->
<!-- and so is this one,
which occupies more than one line -->

White space is not permitted between the markup declaration open delimiter("<!") and the comment open delimiter ("--"), but is permitted between the comment close delimiter ("--") and the markup declaration close delimiter (">"). A common error is to include a string of hyphens ("---") within a comment. Authors should avoid putting two or more adjacent hyphens inside comments.

http://www.korail.go.kr//2003/html/index.htm의 소스를 보면
다음과 같은 코멘트가 굉장히 많습니다.

Code: Select all

<!------또 하나의 팝업창 띄우기 (오늘창 다시 안띄우기)--------->

위 커멘트의 문제는 HTML 4.01에서 바로 흔한 실수라고 지적한 실수를 범하고 있다는 점입니다. 즉, 커멘트 안에 둘 이상의 잇달아 나오는 하이픈(-)을 쓰지 말라고 했는데, 여러 개를 쓰고 있습니다. 그 바람에 모질라의 HTML parser가 헛갈려 합니다. 위와 같은 커멘트를 모두 다음처럼 바꾸면 잘 보입니다.

Code: Select all

<!-- -또 하나의 팝업창 띄우기 (오늘창 다시 안띄우기)- -->

Safari나 Konqueror나 MS IE는 잘 하는데, 왜 모질라는 못 하느냐? 물론, 이런 것도 봐 주도록 고칠 수도 있을 것입니다. 하지만, 표준에서 위와 같은 제약을 둔 이유는 구현을 좀더 효율적이고 용이하게 하려는 의도 때문입니다. 다른 브라우저 제작자들은 이것을 봐 준다고 해서 모질라가 꼭 그래야 할 필요가 없다는 얘기입니다. 또한, 다른 브라우저들은 이것을 봐 주기 위해서 효율성을 희생했을 수도 있고 (모든 경우가 아니라면, 이처럼 표준을 위반한 경우에), 프로그램 구조를 안 좋게 만들었을 수도 있습니다.

[빛알갱이]

고치라고 메일을 보내고 싶은데, 보낼 때가 마땅치 않군요. 유일하게 나온 이메일 주소(m_korail at korail.....)는 웹마스터 주소가 아니라 일반 고객 문의용 주소인 것 같고요.

그래도 비교적 (다른 곳에 비해서) HTML 문법 오류 수가 적은 편인데 (javascript의 경우도 경고 하나만 나오더군요.), HTML 주석문에서 결정적 실수를 해서 Gecko engine을 쓰는 브라우저에서 제대로 볼 수 없군요.

[빛알갱이]

고치라고 메일을 보내고 싶은데, 보낼 때가 마땅치 않군요. 유일하게 나온 이메일 주소(m_korail at korail.....)는 웹마스터 주소가 아니라 일반 고객 문의용 주소인 것 같고요.

철도 공사 전산 관련 팀 전화 번호를 하나 받았습니다. 내일 연락을 한번 해 보겠습니다.

[hyeonseok]

저도 다른 디자이너 들이 comment 를 길~~게 입력할때 그러지 말라고는 하는데 정확히 왜 그래야만 하는지는 몰랐거든요...

이런 문제가 발생 할 수도 있군요...조심해야 겠네요... -o-;

Code: Select all

<SCRIPT LANGUAGE="JavaScript">
<!--

요 부분이 심히 의심이 가는 부분이네요.. 주석 처리가 안되어 있어서..

그런데...script 부분을 저렇게 주석으로 처리 하는 것이 반드시 필요 한가요? 스크립트가 지원이 되지 않는 브라우져를 위해서 주석 처리 한다고는 하는데... 요즘도 브라우져도 해당사항이 있을 까요? 저는 javascript 에 주석처리를 하지는 않아서...안해줘도 상관없나 궁금하네요..

[빛알갱이]

주석 처리는 script 안에 있는 내용을 이해하지 못 하는 (원래 모르는 tag은 건너 뛰어야 하는데) 옛날 브라우저를 위해서 합니다. 철도 공사 페이지의 경우 그것이 문제가 아니고, 그 위에 커멘트 문법을 어겼기 때문에 그 뒤에 따라 나오는 Javascript 부분이 통째로(<script>와 </script>를 포함해서) 커멘트로 인식되어서 아예 실행이 안 된 것이 문제입니다. 모질라에서 소스 보기를 해 보면 커멘트가 색깔이 다르게 나오므로 모질라 파서가 어느 부분을 커멘트로 인식한 것인지 알 수 있습니다.

더 자세한 설명이 다음 문서에 있습니다.

http://webtips.dan.info/comments.html

아직 시험해 보지 않았는데, MS IE나 Safari가 이 테스트를 통과하지 못 할 확률이 높군요. 이 테스트를 통과하면서, 철도 공사 페지의 주석문 문법 문제를 '봐 줄 수'는 없을 것 같거든요.


http://www.hixie.ch/tests/evil/mixed/comments-evil.html


참, 철도 공사에 몇 군데 전화를 걸었더니, 결국 웹 페이지 하단에 있는 m_...@mail.korail... 주소로 보내면 웹 마스터가 글을 본다고 하네요. 한번 보내 보겠습니다.

[hyeonseok]

하...이 테스트 잼있네요..

Win2000 에서

IE5, IE6, Opera 7.54 모두 테스트를 통과하지 못했습니다. -_-;;;;;;
Netscape 7.2 는 잘 되는 군요.


이 버그를 이용해서 flash 를 선택적으로 불러들이는 방법을 배포 했던 사람이군요... ^^
http://ln.hixie.ch/?start=1081798064&count=1
저는 이 Hixie method 는 겁이 나서 사용은 안하고 있습니다. 나중에 수정이 되면 페이지가 정상적으로 안나올 가능성이 높아서...^^;;

[빛알갱이]

Ian Hixie는 W3C CSS WG의 주요 멤버이고 (http://www.w3.org/Style/CSS), 모질라 개발에도 오랫동안 관여했습니다. (지금도 QA로 활동 중) 현재 소속은 Opera입니다. 또, WHATWG에서도 주도적인 역할을 하고 있습니다. (http://www.whatwg.org)

[빛알갱이]

메일을 보냈는데, 지극히 의례적인 답변만 왔습니다. 이 문제 고치는데 시간이 얼마나 걸린다고...

다시 한번 메일을 보내야겠습니다. 다른 분들도 그 페이지 하단에 편지 봉투 그림에 있는 주소로 항의 메일을 보내 주시면 좋겠습니다.

단, 이 문제가 firefox 1.0이나 suite 1.7.x에서는 어떤 이유로 없을 수도 있습니다. 하지만, suite 1.8a6 (firefox 1.1을 향해 가는 버전도 마찬가지)에서는 확실한 문제가 있습니다.

[임인택]

http://dust.seoul.go.kr/


이곳도 같은 문제인것 같네요.

[빛알갱이]

맞네요. 거기도 comment 문법이 틀려서 스크립트와 html 일부가 커멘트로 인식되어서 제대로 안 보이는군요.

철도 공사 사이트는 그 밖에도 'document.'를 생략한 곳이 있어서 열차 조회 등이 안 되더군요. 흔히 보는 일이지만, 한 파일 안에서도 'document.'를 붙인 곳도 있고 안 붙인 곳도 있더군요. 그 파일을 손대는 사람에 따라 제각각인 것인지....

[파란사오정]

답장을 받았습니다...

...생략...
아울러, 죄송하옵니다만 공공기관으로서 익스플로러가 보편성 및 보급성에서
다른 웹브라우저 보다 장점이 있어서

익스플로러 기반하에 홈페이지를 운영하고 있습니다.

(홈페이지 개발단계에서 공공기관인 관계로 예산절감 등의 사유로 인하여)

참고로, 금년 3월중에 새롭게 전면 개편하여 보다 쎄련된 홈페이지를 선보일
예정입니다. 지켜봐 주십시요.
...생략...

[hyeonseok]

(홈페이지 개발단계에서 공공기관인 관계로 예산절감 등의 사유로 인하여)

요새 공공 기관들은 접근성을 높이는 것을 중시하고 있는데...

그리고 다들 알다시피 예산 절감 == IE 전용 은 아니죠.

IE 전용은 예산 낭비, 예산을 적절히 사용했는지 평가할 수 있는 능력이 없는지도...

[guest]

(홈페이지 개발단계에서 공공기관인 관계로 예산절감 등의 사유로 인하여)

요새 공공 기관들은 접근성을 높이는 것을 중시하고 있는데...

그리고 다들 알다시피 예산 절감 == IE 전용 은 아니죠.

IE 전용은 예산 낭비, 예산을 적절히 사용했는지 평가할 수 있는 능력이 없는지도...

혹시 웹개발에 종사하고 있는 분이거나 정부 예산 집행 용도 부서에 계신 분이라면 그 내용이 무엇을 말하는지 알 수 있을 겁니다. 괜한 엉뚱한 딴지는 걸지 마세요.

까놓고 얘기해서 웹개발자 중에서 디자이너나 코더나 기존 IE 환경이 아닌 비IE 환경까지 포함한 개발이라면 그 비용이 훨씬 높아지는 것은 알텐데요.

그리고 예산 집행할때 저렴한 업체를 선정하기 때문에, 그것도 소액이 아니면 입찰이기 때문에 당장 어떻게 해 볼 수 있는 것이 아니잖습니까. (뭐 입찰 시방서 작성할때 포함해라면 단가가 올라갈 것이고 그러면 예산 반영하면 되지 않느냐고 하면 소관 예산처나 국회에서 그냥 배정해 줄리는 전혀 없고.. 등등을 말하는 것은 아니겠죠.)

다행히 새로 개편하면서 firefox에서도 잘 나오게 해 준다니 늦었지만 반가운 소식이네요. 개선은 좋지만 막무가내는 문제가 있길레 지나가는 길손이 기분은 나쁠지 모르겠지만 한마디 하고 갑니다.

[hyeonseok]

까놓고 얘기해서 웹개발자 중에서 디자이너나 코더나 기존 IE 환경이 아닌 비IE 환경까지 포함한 개발이라면 그 비용이 훨씬 높아지는 것은 알텐데요.

잘못 알고 계신 것이 있습니다.

IE 환경과 비 IE 환경은 서로 배타 적인 것이 아닙니다.
"표준" 을 준수 하게 되면 추가 비용없이, 오히려 더 저렴한 비용으로 모든것을 만족시키는 개발이 가능합니다.

비용이라는 것은 표준에 대한 교육 비용이 되겠지요.

비용이 추가되는 부분을 포함하는 것이 아니라 기존의 잘못된 방식(호환성떨어지는)으로의 개발을 피하면 되는 것입니다.

표준을 준수 하고 개발 비용도 줄이고 개발 업무로드도 줄이고 트래픽으로 발생하는 연간 운영비용도 줄이고 접근성 향상 시켜서 장애인도 사용할 수 있게 하고..
그러기 위해서는 잘못된 인식을 바꾸고 표준을 적용해야 한다.

막무가내 인가요?

이미 이 포럼에서는 이러한 내용의 많은 토론이 오고 가고 있습니다. 좀더 많은 내용을 둘러보시고 같은 생각을 할 수 있었으면 좋겠습니다.

[tenshi]

금년 3월중에 새롭게 전면 개편하여 보다 쎄련된 홈페이지를 선보일 예정입니다.

이게 국내 IT 업계의 보편적인 마인드인 것 같습니다.
관공서라면 사정이 좀 나을 것 같지만..
시각장애인용, pda용, text전용.. 이런 서비스들은 단지 점수를 따기위해 눈가리고 아웅하는 식이고, 형식적인 구성으로 정작 필요한 내용은 열람하기 힘든 경우가 대부분입니다.


단지 일시적인 비용만을 생각하고,
이 곳 사람들을 정저지와식 논리로 모인 집단 정도로 치부하시는 것 같군요.

좀 더 그 일시적인 비용이 후에 어떤 가치로 돌아올 것인가에 대한 생각을 해보셔야 겠습니다. guest님!

[회니]

제발 다른 표준은 제쳐놓더라도
자바스크립트에서 document. 이것만이라도
제대로 붙여 줬으면 좋으련만 ...

[빛알갱이]

까놓고 얘기해서 웹개발자 중에서 디자이너나 코더나 기존 IE 환경이 아닌 비IE 환경까지 포함한 개발이라면 그 비용이 훨씬 높아지는 것은 알텐데요.

"document."를 생략하지 말아야 할 곳에서 생략하지 않는데, 드는 추가 비용이 얼마입니까? 타이핑하는데 드는 시간? 그 시간은 쓸데 없이 커멘트에 쳐 놓은 "-----------"를 치지 않아서 절약하는 시간으로 충분히 만회할 수 있겠네요.

지금 님은 'if (IE) blah blah else if (Mozilla) blah blah else if (NN4) blah blah'와 같은 식으로 생각하고 있기 때문에 비용이 더 많이 든다고 생각하고 있습니다. 그런 식이 전혀 필요 없다고는 하지 않겠습니다. 하지만, 표준을 지켜서 작업한다면 대부분은 그런 식으로 만들 필요가 거의 없습니다. 그런 부분이 있다고 해도 브라우저 비호환적인 부분을 잘 둘러 싸서 프로그램을 쉽게 해 주는 JS library(무료,오픈 소스)도 여럿 있으므로, 실재로 'if else if else if'와 같은 일을 할 일은 거의 없습니다.