웹사이트 오류 검색 사이트

[dusl]

http://www.coolcheck.co.kr/

이런 사이트가 있네요.
제가 운영하는 홈페이지는 D 등급을 ㅠ.ㅠ

그러나 막상 이 홈페이지는 파이어폭스에서 자바스크립트 오류가 나타났다는.-_-;;;;

여러가지 체크해주는데 체크해주는 내용중엔

---------
19. html tag 오류
해당 사이트에서 발견된 잘못 쓰인 태그들을 표시합니다. W3C(World Wide Web Consortium)에서 제정한 html 4.01을 기준으로 이를 위반하는 것들입니다. 내장 에디터(Premium)를 위한 라인정보가 함께 표시되므로 쉽고 즉각적인 수정이 가능합니다.
---------
도 있네요.

각 브라우저별 O X 표시를 해줍디다.

[astraea]

진단에 active x 를 요구하는거 같아서 그냥 포기했어요;;

[조웅희]

쿨첵을 개발하고 있는 (주)우리인터넷입니다.

자바스크립트 오류는 확인후 시정하도록 하겠습니다. 그리고 저희는 비영리 목적으로 사이트를 만들고 운영하는 개인을 대상으로 무료로 사이트 관리 서비스를 제공하고 있습니다. 전문적인 프로그래머만을 대상으로 하고 있지 않고 있기 때문에 부득이 액티브 액스 형태로 제공하고 있으니 포기하지 마시길. 유저들의 피드백이 충분히 반영되는 시기에 애플리케이션 형태로도 제공하도록 하겠습니다.

아시다시피 w3c 규약은 권고안이고 실제 규약을 브라우저 제작사들이 그대로 따르고 있지는 않습니다. 고생스러우시더라도 수고해주시고 저희도 모질라가 널리 사용될 수 있도록 노력하겠습니다. 저희 사이트에도 적극적으로 개선사항이나 요구사항을 주시면 최대한 반영하도록 하겠습니다. 감사합니다.

[kheled]

랭키닷컴에 올라있는 국내 탑 사이트들이 IE가 아닌 브라우저에서 문제가 생기는 경우는, 대부분 레이아웃 문제보다는 IE 전용 DOM 모델 (document.all, window.<id>, <element>.outerHTML 등), CSS 모델 (<element>.style.pixelTop 등), 이벤트 모델 (attachEvent 등)을 사용했기 때문이더군요.

ActiveX를 요구하기 때문에 직접 테스트해보지는 않았지만, 이 부분에 대한 계도 작업도 중요하다고 생각합니다.

[조웅희]

잘 알겠습니다. 사실 syntax error는 아직까지 저희 여력이 미치지 못하여(공부가 덜 되어 있어서^^;) 형식적인 검사만 수행하고 있습니다. 그리고 이 부분에 대해서는 이미 여러 좋은 솔루션들이 나와 있어서 저희가 섣부르게 도전하지 못하는 분야이기도 합니다.

저희의 현재 주관심사는 URL 파싱문제입니다. Regular Expression을 얼마나 정치(예외처리 포함, 이 부분에서 IE(!)가 처리하는데 저희가 처리 못하면 신뢰성에 문제가 생깁니다.)하게 할 수 있느냐 그리고 한글을 비롯한 2바이트 언어를 얼마나 잘 처리할 수 있느냐가 관건입니다.

이 문제를 어느 정도 해결하게 되면 다음 단계는 accessibility 문제를 제기할 예정입니다. 인터넷의 취지가 정보의 공유라면 "접근성"이라는 말이 시사하는 바는 매우 크다고 봅니다. 아주 단순한 예로 이미지에 alt text만 제대로 달아줘도 시각장애인들은 사이트 서핑이 대부분 가능합니다(시각장애인과 직접 면담후 얻게된 정보). 이 때 필연적으로 syntax 문제가 자연스럽게 제기할 예정입니다.

다른 문제이긴 하지만 현재 액티브 액스에 대한 안좋은 경험들이 쿨첵의 사용을 주저하게 만드는 것 같습니다. 그러나 사실 이것처럼 제작자나 사용자에게 편리한 것도 없는게 현실입니다. 문제는 배포하는 회사의 신뢰도이겠지요^^; 이는 애플리케이션으로 배포해도 동일하게 발생할 문제입니다. 하루빨리 사용자분들의 신뢰를 쌓도록 하겠습니다!

[빛알갱이]

좋은 서비스를 제공해 주셔서 감사합니다.
몇 가지 지적하고 싶은 것이 있어서 적어 봅니다.

1 한글은 표기 체계이지 언어가 아닙니다.
2.한글은 2byte 언어가 아닙니다.
3.2byte는 CJK 표기 체계의 특정 인코딩에서는 쓰이지만 모든 CJK 표기를 위한 인코딩이 2byte를 글자 한 자를 위해 쓰지 않습니다. GB18030은 최고 4byte를 쓰고, EUC-JP는 3byte, UTF-8은 최고 4byte, EUC-KR도 규정대로 엄격하게 따른다면 최고 8byte를 씁니다. 다른 경우는 그다지 중요하지 않지만, UTF-8과 GB18030은 중요하므로, CJK 언어 표기에서 쓰는 모든 인코딩이 2byte라는 그릇된 미신은 속히 떨쳐 버리시기 바랍니다.

더 나아가, 문법 체크만 한다면 인코딩이 큰 문제가 될 이유가 전혀 없습니다. 초기에 인코딩을 제대로 인식하기만 하면 (잘못 인식한 경우 사용자가 강제 지정할 수 있도록 하고) 그 후 내부 처리는 전적으로 유니코드 기반으로 하면 되니까요.

4. Active X 사용에 대해 : 신뢰성이나 보안의 문제보다 훨씬 중요한 문제가 있는데 간과하고 계신 것 같아 적습니다.

웹은 플랫폼 독립성이 생명입니다. 위와 같은 문법 체크 기능도 그런 방향에 도움을 주는 유용한 도구입니다. 그런데, 바로 그 도구가 Active X를 써서 특정 플랫폼 종속적이라면 자기 모순입니다. Active X에서 자바로 전환하는 것을 고려해 보십시오. (Java application이라면 local file 접근에 문제가 없을 것이므로. signed applet을 쓸 수도 있을 것이고요) 특정 플랫폼에서 개발하는데에 Active X가 편리하므로 그렇게 하셨다는 것은 이해할 수 있지만, 그 편리성은 특정 플랫폼 사용자에게만 해당합니다. 다른 플랫폼 사용자에게는 편리성 이전에 아예 사용이 불가능합니다. 이미 접근성 문제를 언급하셨으니까, 더 이상 길게 얘기하지 않겠습니다.

5. alt tag을 그냥 다는 것만으로는 충분하지 않습니다. 여기에도 복잡한 문제가 꽤 많습니다. 짧은 논문 한 편은 이 문제를 주제로 쓸 수 있습니다. 어쨌든, alt tag이 없는 image가 들어간 html 4.01 문서는 문법을 어긴 것이므로 문법을 지키기 위해서라도 alt tag을 달아야 합니다.

6. W3C의 '권고안'과 표준에 대해 : '표준'이란 말은 여러 가지 의미로 쓰일 수 있습니다. 하지만, '권고안'이란 말을 W3C에서 쓴다고 해서, W3C에서 만드는 권고안이 '표준'이 아니라고 할 수 없습니다. W3C 권고안은 IEEE, IETF, Unicode consortium에서 제정하는 표준과 동등한 위치에서 표준입니다.

[조웅희]

좋은 지적 해주셔서 감사드립니다. 제가 공부가 덜 되어 있어 새로 배운 것도 많이 있군요:)

개발팀에서 검토하도록 하겠습니다.

제가 모질라 프로젝트에 관심과 애정을 갖는 이유는 근본적으로 현재의 특정 브라우저 또는 플랫폼의 독점 상황이 가져오는 폐해 때문입니다. 님도 마찬가지일 거라고 생각합니다. 이 대의가 모든 논의의 기반이자 공감대라고 생각합니다.

이런 전제하에서 님께서 지적한 문제에 대해 제 생각을 말씀드리자면,

4. 지적하신 대로 분명 모순되는 점은 존재하나 쿨첵은 엔드 유저가 아닌 사이트 개발자를 대상으로 합니다. 이미 저희 사이트의 Q&A에서 모질라 유저분에 대한 답변에서 말씀드렸습니다만 저희 회사가 개발 여력이 부족한 상황에서 다른 플랫폼 더 나아가 플랫폼 독립적인 제품을 개발할만한 상황은 아닙니다. 몰라서도 아니고 고의도 아니니 이 점에 대해서는 당분간 부디 양해를 바랍니다.

아 그리고 액티브 액스로 장난을 치는 몇 몇 포탈들 때문에 저를 포함한 일반 엔드 유저들이 좋지 않은 기억을 갖고 있는게 사실입니다. 그럼에도 불구하고 저희 회사 입장에서는 이른바 Site Analytics 분야(이 분야에 관한 document는 저희 사이트 관련자료에 걸려있는 벤더 링크에서 충분히 접하실수 있습니다.)의 솔루션을 쉽게 배포할수 있는 방법을 고민하다가 불가피한 선택으로 일단 액티브 액스를 선택한 것입니다. 사실 능력있는 자바 개발자가 저희 개발진에 합류할수만 있다면 이런 고민은 애초에 필요가 없었겠죠. 기업 대상의 상용 버전은 무료 버전과 달리 애플리케이션으로 배포됩니다. 그러나 역시 윈도우 종속적입니다...


5. 접근성 문제는 다행히 제가 충분히 논의가 가능한 문제이고 제가 보기에 long description등의 문제를 지적하신 거라면 굳이 언급할 필요는 없을듯 해서 핵심만 말씀드린거니 양해를 해주셨으면 합니다.

6. w3c 권고안은 합의된 규약이고 표준입니다. 거기에 대해 부정하는 사람이 있을까요? 그러나 최소한 html 규약의 발전사에서 "시장의 논리"에 의해 굴절의 과정을 겪은 것도 사실입니다. 예컨데 WAI처럼 현실에서 section508에 의해 법제화되지 않은 이상 html3.2 이후의 권고안이 현실에서 de facto의 힘을 가질수 있는지 궁금합니다. 혹시 제가 오해의 소지를 남긴게 있는지?

이상 제 의견을 말씀드렸읍니다만 부족한 점이 있으면 언제든지 지적해주시기 바랍니다. 감사합니다.