"네이버 탑페이지 HTML 유효성 검사 통과"
코멘트에서 id와 name의 중복문제가 나온다. 사실 "보안된 페이지의 HTML Validation Check 방법"을 보면서 살짝 예상하기도 했었다. (더불어 W3C Validator는 내부에 설치할 수도, 파일을 직접 올려서 확인해 볼 수도 있다.)
W3 Validator나 SGML Parser는 DTD에 따른 문법 검사만 한다고 보면 된다. 가령 이번에 문제가 된 "12.2.3 항목"은 DTD에 정확히 표현되어 있지 않다. HTML의 과도기적 문제라고도 할 수 있는데 id 속성과 Anchor의 name은 서로 문법이 틀리다. DTD가 뭔지 id와 name이 뭐가 틀리다는 건지는 직접 찾아 보시고(하단 덧글 참고)
맞춤법이 맞다고 해서 올바른 국어가 아니듯 DTD 검사를 통과해도 DTD가 커버하지 못하는 Spec에서 문제가 될 수 있다. 사실 Spec문서에서는 다양한 오용사례(Illegal Example)를 들어가면서 이런 것들을 설명하고 있다. 따라서 DTD에 맞췄다고 안심할 것이 아니다.
개인적으로는 SGML Parser보다는 HTML Tidy를 선호한다. 좀더 에러를 깐깐하게 찾아준다. Serial은 SGML Parser를 먼저 통과해야 하는데 많은 경우 문법적 에러를 당장 수정할 수 없는 경우도 많기에 상대적으로 비추천한다.
HTML Tidy만 통과하면 이제 문제 없는 것일까? 이 벨리데이터 플러그인의 문제점이 하나 있는데 소스를 서버에서 받은 상태 그대로 검사한다는 것이다. JavaScript에 의한 변화 상황이 반영되지 않는다. 특히 JS에서 innerHTML이나 document.write로 넣는 것들은 Validator에서 알아 볼래야 볼수가 없다. 원래부터 문법이 난리였던 사이트에서 html 상으로만 정리를 한다 하더라도 JS 코딩은 여전히 과거의 습관대로일 것이므로 문제가 완벽히 해결이 안되는 경우가 많다.
FF를 쓴다면 "Web Developer 플러그인"을 추천하는데 다른 좋은 기능도 있지만 페이지가 완성된 상태의 HTML을 뽑아주는 기능이 있다. JS가 수행하는 변화까지 반영되는 것이다(물론 브라우저마다 코드가 달라진다면 브라우저마다 따로 작업을). 이렇게 나온 HTML을 바로 Validator로 돌려버리면 거의 초 허접소리를 듣게 되는데 이유는 브라우저의 오브젝트 모델 기반이기 때문이다. 가령 "<br />"은 "<br>"로 바껴버린다(이것이 Textcube 에디터에서 문제시 되었던 부분). doctype은 하늘나라로 날라가 버리셨고 등등등. 기본적으로 태그 짝은 맞다고 가정하고 수동 보정 작업을 좀 해줘야 한다.
아니면 본인처럼 능력 되시는 분들은 코드를 읽으면 된다! (참 쉽죠?)(네이버 메인은 읽다가 잠들었다. -ㅅ-)
개발하시는 분들은 참고하시고, 더불어 행여나 W3C Validator 통과했다고 전혀 문제없다는 주장을 하는 일이 없으시길.
PS.
글쓰면서 네이버 실제 코드좀 인용하려다가 FF가 또 죽었다. 어서 개발팀에서 나머지도 깔끔하게 손봐주길 기다려야 할지도. FireBug + Mac 콤보는 상당히 불한하다는 느낌이다.
아무튼 글 날라가서 처음에 자세하게 쓴것이 저하늘로~~~ 결국 대충 쓰게 되었다. ㅠ.ㅠ
PS.
Textcube 관리자화면에 Validated 마크가 붙던 과정에, 위처럼 DTD는 준수하지만 실제 마크업의 사용이나 시멘틱 까지 가면 완전 개판임을 알고 있었다. 결국 저 마크는 자랑의 마크라기 보다는 각오의 마크로 보는 것이 옳을 것이다.
코멘트에서 id와 name의 중복문제가 나온다. 사실 "보안된 페이지의 HTML Validation Check 방법"을 보면서 살짝 예상하기도 했었다. (더불어 W3C Validator는 내부에 설치할 수도, 파일을 직접 올려서 확인해 볼 수도 있다.)
FF의 HTML Validator 플러그인의 설정화면
맞춤법이 맞다고 해서 올바른 국어가 아니듯 DTD 검사를 통과해도 DTD가 커버하지 못하는 Spec에서 문제가 될 수 있다. 사실 Spec문서에서는 다양한 오용사례(Illegal Example)를 들어가면서 이런 것들을 설명하고 있다. 따라서 DTD에 맞췄다고 안심할 것이 아니다.
개인적으로는 SGML Parser보다는 HTML Tidy를 선호한다. 좀더 에러를 깐깐하게 찾아준다. Serial은 SGML Parser를 먼저 통과해야 하는데 많은 경우 문법적 에러를 당장 수정할 수 없는 경우도 많기에 상대적으로 비추천한다.
HTML Tidy만 통과하면 이제 문제 없는 것일까? 이 벨리데이터 플러그인의 문제점이 하나 있는데 소스를 서버에서 받은 상태 그대로 검사한다는 것이다. JavaScript에 의한 변화 상황이 반영되지 않는다. 특히 JS에서 innerHTML이나 document.write로 넣는 것들은 Validator에서 알아 볼래야 볼수가 없다. 원래부터 문법이 난리였던 사이트에서 html 상으로만 정리를 한다 하더라도 JS 코딩은 여전히 과거의 습관대로일 것이므로 문제가 완벽히 해결이 안되는 경우가 많다.
FF를 쓴다면 "Web Developer 플러그인"을 추천하는데 다른 좋은 기능도 있지만 페이지가 완성된 상태의 HTML을 뽑아주는 기능이 있다. JS가 수행하는 변화까지 반영되는 것이다(물론 브라우저마다 코드가 달라진다면 브라우저마다 따로 작업을). 이렇게 나온 HTML을 바로 Validator로 돌려버리면 거의 초 허접소리를 듣게 되는데 이유는 브라우저의 오브젝트 모델 기반이기 때문이다. 가령 "<br />"은 "<br>"로 바껴버린다(이것이 Textcube 에디터에서 문제시 되었던 부분). doctype은 하늘나라로 날라가 버리셨고 등등등. 기본적으로 태그 짝은 맞다고 가정하고 수동 보정 작업을 좀 해줘야 한다.
아니면 본인처럼 능력 되시는 분들은 코드를 읽으면 된다! (참 쉽죠?)(네이버 메인은 읽다가 잠들었다. -ㅅ-)
개발하시는 분들은 참고하시고, 더불어 행여나 W3C Validator 통과했다고 전혀 문제없다는 주장을 하는 일이 없으시길.
PS.
글쓰면서 네이버 실제 코드좀 인용하려다가 FF가 또 죽었다. 어서 개발팀에서 나머지도 깔끔하게 손봐주길 기다려야 할지도. FireBug + Mac 콤보는 상당히 불한하다는 느낌이다.
아무튼 글 날라가서 처음에 자세하게 쓴것이 저하늘로~~~ 결국 대충 쓰게 되었다. ㅠ.ㅠ
PS.
Textcube 관리자화면에 Validated 마크가 붙던 과정에, 위처럼 DTD는 준수하지만 실제 마크업의 사용이나 시멘틱 까지 가면 완전 개판임을 알고 있었다. 결국 저 마크는 자랑의 마크라기 보다는 각오의 마크로 보는 것이 옳을 것이다.
