웹표준/크로스브라우징 붐이 불었던 2004년 전 후에는 W3C validator이 상당히 중요했습니다. 정확히 뭔지는 모르겠지만, 웹표준이 붐이라 하고 그걸 검사해주는 사이트에서 통과만 되면 배너를 달 수 있고 이걸로 있어보이게끔 만들 수 있었기 때문입니다.
따라서 당시 웹표준 검사기를 통과한 사이트들 하단에는 위와 같은 배너들이 달려있는 것을 많이 볼 수 있었습니다.
W3C validator에 통과되었다고 웹표준/웹접근성을 준수하게끔 퍼블리싱을 했다는 의미는 아닙니다.
실제로 문법과 지정된 HTML DTD에 해당하는 엘리트먼트들이 있는지만 체크하고 이에 따라 통과/오류를 판단하기 때문입니다. HTML 문서내에 적절한 엘리트먼트들을 사용했는가?는 판단하지 못합니다. 따라서 검사기 통과를 목적으로 퍼블리싱한다 하여 웹접근성을 향상키시고 모든 브라우저에서 동일하게 구현되는 크로스브라우징이 된다는 생각은 잘못된 생각입니다.
접근성의 경우, 장애인차별법(이하 장차법)으로 인해 공공기관/대기업은 웹 접근성을 준수해야 하며 이에 기초하여 국가에서 한국 웹 접근성가이드를 만들어 배포했지만, 실제 장애인들이 이용할때 불편함을 많이 호소합니다. 없는 것 보다는 낫지만 접근성 가이드를 준수한다하여 장애인들이 완전 편하게 이용할 수 없는 것과 같이, ‘실질적으로 W3C validator에 통과한다 하여 완벽한 웹사이트를 제작했다는 것이 아니다.’라는 것을 말하고 싶습니다.
그럼, 왜 블로그에 소개하는가?
재학중인 대학교에서 웹디자인/퍼블리싱이 전공필수였습니다. 컴퓨터 공학과도 아니고 디자인 학과기에 웹표준, 웹접근성, 올바른 엘리트먼트 사용에 대한 개념을 기반으로하지는 않지만 어쨌든 위지윅 에디터가 아닌 하드코딩으로 웹진을 만드는 과정을 거쳤는데요, 여기서 많은 학생들이 어려움을 호소한 것이 ‘자기가 생각한대로 안나오고 깨진다는 것’입니다.
표준/비표준을 떠나서 특정 브라우저를 기준으로 작업했기에 크로스브라우징 고려는 제외로 하고 원인을 찾아봤더니 가장 기본적인 TAG를 사용할때에 열고 닫는것을 까먹거나 제대로 하지 않아서(해당 엘리트먼트에 없는 속성을 삽입한다던지) 발생한 것이었습니다.
주변에 도움을 요청하지만, HTML 퍼블리싱에 최적화된 애디터를 사용하는 것도 아니고 모든 것이 메모장에서 이루어진 것이기 때문에 가독성이 딸리고, 특정한 규칙이나 Indent를 주면서 코딩한 것이 아닌 막무가내 스파게티 코드라 직접적인 원인을 찾아내기가 상당히 어렵습니다.
HTML/CSS 웹 퍼블리싱을 처음 접하는 사람들은 반드시 W3C validator을 이용하자
웹 표준, 접근성, 크로스 브라우징에 도움은 되지 않지만, 적어도 기본문법과 자신이 실수한 부분을 파악하기 위해서 웹 퍼블리싱을 처음 접하는 사람들에게 W3C validator를 권하고 싶습니다.
HTML/CSS는 쉬운 언어입니다.
PHP, C, Javascript, Phython에 비하면 정말 쉬운 언어입니다. 하지만 초보자들은 어려워 합니다. 정말 이 분야에 관심있어 하는게 아니라 반 강제로 하는 경우가 많기 때문에 큰 관심을 가지지 않습니다. 아무리 옆에서 설명해줘도 한 귀로 듣고 흘려버립니다. 그리곤 나중에 동일한 문제로 또 질문합니다.
따라서 자기가 직접 왜 문제가 있는지 찾고 스스로 해결 할 수 있도록 해주는 것이 중요하다고 생각합니다. 이것의 기본이 W3C validator 이라 생각합니다.
MDN과 같은 레퍼런스를 알려주는 것도 중요하다고 생각하지만, 모든 검색 습관이 네이버에서 시작해서 네이버로 끝나기 때문에 저는 포기했습니다. 가끔 외부에서 가져온 소스를 보면 충격입니다. 예전 90년도에 쓰였을 font 태그와 같은 비표준 태그들을 신기하게 긁어와서 사용하기 때문이죠.
