24. HTML 유효성 검사

  • 번역 : 녹풍

들어가며

지금까지 오면서 HTML 페이지를 좀 만들었을 것이다. 아마 당신이 보기에는 괜찮게 보일 것이다. 하지만 몇 가지 문제가 있다. 이런 문제점을 찾고, 이 페이지들이(혹은 미래에 당신이 만들 페이지가) 여러 브라우저들에서도 에러 없이 제대로 보이도록 할 수 있는 가장 좋은 방법은 무엇일까?

유효성 검사(validation)이 답이다. 사이트의 코드를 검증할 수 있도록 제공하는 툴은 여러 개가 있다. W3C 외에 몇 군데서 제공을 하고 있다. 당신이 사용할 수 있는 가장 일반적인 세 가지 유효성 검사기(validators)는 다음과 같다 :

  • W3C 마크업 밸리데이터 : 이 툴은 당신이 제출한 문서의 (x)html doctype을 바탕으로 문서의 어떤 부분이 doctype을 위반했는지 지적해 준다. (즉, 제출한 HTML에서 그곳에 에러가 있다.)
  • W3C 링크 체커 : 이것은 제출한 문서를 전부 훑어 보고서, 모든 링크가 깨지지 않고 제대로 있는지 테스트한다.(깨졌다는 것은, href 값이 가리키고 있는 문서가 존재하지 않는 경우를 말한다.)
  • W3C CSS 밸리데이터 : 아마 금방 눈치챘을 텐데, 이것은 CSS(혹은 HTML/CSS) 문서를 훑어 보고 CSS 스펙을 제대로 지켰는지 체크한다.

이 글에서 첫 번째 것에 대해 말할 텐데, 사용법과 자주 발생하는 유효성 검사 결과를 어떻게 해석하는지를 보여 줄 것이다. 링크 체커(Link Checker)는 아주 명확하다.[명확한 결과를 돌려 주니까 굳이 설명할 필요가 없다는 뜻인 듯] 그리고 CSS 밸리데이터는 이 글과 이 코스의 뒤에 나오는 CSS 관련 글을 읽은 다음에는 어느정도 스스로 이해할 줄 알아야 한다.

이 글의 구조는 다음과 같다 :

  • 에러
  • 밸리데이션이란 무엇인가?
  • 왜 유효성 검사를 하는가?
  • 각각의 브라우저들은 유효성 검사를 통과하지 못하는 HTML을 서로 다르게 해석한다
    • 쿽스모드(Quirksmode)
  • 페이지 유효성 검사 방법
    • W3C HTML 밸리데이터
  • 요약
  • 더 많은 유효성 검사기(Further tools to check out)
  • 연습문제

에러

컴퓨터 프로그래밍을 할 때, 코드 관련해서 크게 두 가지 문제가 있다.

  • 문법적인 오류 – 이건 코드를 작성할 때 실수를 해서 컴퓨터가 프로그램을 제대로 실행하지 못하거나 제대로 컴파일하지 못하는 경우다.
  • 프로그래밍(혹은 로직) 에러 – 이건 프로그래머의 의도가 코드에 온전히 반영되지 않아서 나는 에러다.

대부분의 프로그래밍 언어에서, 첫 번째 에러는 발견하기 정말 쉽다. 에러를 고치기 전에는 프로그램 자체가 실행도 안 되고, 컴파일도 안 되기 때문이다. 이런 버그는 일단 “어라, 왜 안되지?” 하면서 머리를 벅벅 긁다 보면 해결되기 마련이다.(심한 의역;; ─ This makes finding and fixing these types of bugs much easier in those general head-scratching moments of “So why isn’t it doing what I want?”)

HTML은 프로그래밍 언어가 아니다. 문법에 오류가 있다고 웹브라우저가 페이지 여는 거 자체를 거부하는 경우는 없다. (XHTML이 HTML보다 많이 엄격하긴 하지만. ㅡ 최소한 application/xhtml+xml 이나 text/xml 데이터를 의도한다면 ㅡ 그리고 몇몇 doctype은 그런 식으로 사용돼 온 HTML 요소(element)를 거부할 테지만.) 이것은 웹이 빠르게 채택되고 널리 퍼진 가장 큰 이유다.

최초의 웹브라우저 – 월드와이드웹(WorldWideWeb)(링크 타고 들어가면 Tim Berners-Lee가 쓴 글이 나온다)은 HTML을 먼저 배우지 않고도 웹 페이지를 만들 수 있도록 해 주는 에디터기도 했다. 이 에디터는 잘못된 HTML을 생성했다. 이것은 계속 고쳐오긴 했지만, 오늘날 현존하는 모든 웹브라우저에 중요한 전례가 됐다. 즉, 사람들에게 내용을 보여 주는 게 에러를 설명하는 것보다 중요하다는 것이다. [웹브라우저를 사용하는 사람들은] 에러를 이해할 수도 없고, 고칠 위치에 있지도 않[기 때문이]다.

밸리데이션이란 무엇인가?

웹 브라우저가 나쁜(‘유효성 검사를 통과하지 못한’은 우리가 사용하는 용어다) 웹페이지를 허용하고, 최선을 다해서 제작자의 의도를 감안해 렌더링한다고 해도 여전히 HTML이 올바르게 작성됐는지 체크하는 것은 가능하다. 그리고 뒤에 살펴 보겠지만, 그렇게 하는 것이 좋기도 하다. 우리는 이것을 HTML “밸리데이션하기”(유효성 검사하기)라고 부른다.

유효성 검사 프로그램은 웹 페이지에 있는 HTML 코드를 doctype에 있는 룰과 비교하고, 어디가 룰을 어겼는지 말해 준다.

왜 유효성 검사를 하는가?

웹 페이지가 브라우저에서 어떻게 보이느냐가 문제지 유효성 검사를 통과하는지는 문제가 아니라는 느낌이 개발자들 사이에 일반적이다. 유효성 검사는 무 썰듯 확실히 갈리는 게 아니라, 이상적인 목표라는 것이다.

이 런 태도에 일리는 있다. HTML 명세서는 완벽한 게 아니고, 지금은 시간도 많이 흘렀다. 이론의 여지는 있지만, HTML 유효성 검사를 통과하지 못하는 것 중에는 ( 1보다 큰 수로 번호매긴 리스트(ol)를 시작하는 코드처럼) 올바른 것도 있다. 그러나, 다음 말처럼 :

– 룰을 익혀서 어떻게 깨지는지를 확실히 알아라.

네가 HTML 제작자로서 좀더 힘을 들여서라도 HTML 유효성 검사를 해야 할 두 가지 중요한 이유가 있다.

  • 당신도, 당신이 작성한 코드도 항상 완벽하지는 않다. 우리는 모두 실수를 한다. 그리고 당신이 만든 웹페이지는 당신이 실수를 전부 바로잡는다면 더 높은 퀄리티를 유지할 것이다.(즉, 더 오래 유지될 것이다.)
  • 브 라우저는 바뀐다. 미래에는 브라우저가 유효성 검사를 통과하지 못한 코드를 해석(parsing)할 때 지금보다 더 관대해지기 보다는 덜 관대해질 것이다.

유효성 검사는 재밌는 동시에 받아들이기 힘든 방법이다. [그러나] 웹페이지에 있는 버그를 확실히 설명해 주는 조기 경보 시스템이다. 브라우저가 유효성 검사를 통과하지 못하는 HTML을 만나면, [HTML 작성자가] 의도한 것이라고 생각되는 걸로 결과물을 내놓는다. 그리고 서로 다른 브라우저들은 각각 다른 결과를 내놓는다.

각각의 브라우저들은 유효성 검사를 통과하지 못하는 HTML을 서로 다르게 해석한다

유효성 검사를 통과한 HTML은 브라우저 제작사들과 마찬가지로 오직 당신의 지시를 따른다. HTML 명세서는 네가 HTML을 어떻게 작성해야 하는지 알려 준다. 그리고 그게 어떤 식으로 표현되야 하는지도 알려 준다.

최근에는 브라우저들이 표준을 준수한 결과 모든 메이저 브라우저가, 유효성 검사를 통과한 코드에 대해서는 같은 해석을 하게 됐다. 어쨌든, 이것은 거의 항상 HTML에 대한 경우다. HTML은 여기저기를 지원하는 몇몇 다른 점이 있는 또다른 표준이 있다.

하지만 만약 유효성 검사를 통과하지 못하는 코드를 보내면 어떻게 될까? 그러면 무슨 일이 일어날까? 답은, 브라우저 에러 핸들러가 작동해서 [제출된] 코드가 하려고 했던 것을 처리하게 된다는 것이다. 이건 근본적으로 “그래, 이 코드는 유효성 검사를 통과 못하는군. 그럼 지금 이 페이지를 사용자(엔드 유저)한테 어떻게 보여 줄까? 이렇게 허점을 채우자!” 라고 말하는 것이다.

이것 참 좋은 생각 같지 않은가? 페이지에 에러가 남아있는데도, 브라우저가 당신을 위해 그 허점을 채워 준다? 별로 그렇지가 않다. 각 브라우저는 서로 다른 방법으로 그렇게 한다.[허점을 채운다.] 예를 들면,

<p><strong>This text should be bold</p>
<p>Should this text be bold? How does the HTML look when rendered?</p>

<p><a href="#"></strong>This text should be a link</p>
<p>Should this text be a link? How does the HTML look when rendered?</p>

이 코드에서 잘못은, strong 엘리먼트가 블록 엘리먼트 몇 개에 걸쳐서 사용된 것이다. 그리고 앵커 엘리먼트는 닫히지 않았다. 여러 브라우저에서 이걸 렌더링한다면, 서로 완전히 다른 방법으로 이 코드를 해석하게 된다.

  • 오페라는 bold 엘리먼트의 자식 엘리먼트를 만들어 낸다.
  • 파이어폭스는 문단 사이에 마크업에는 보이지 않는 extra bold 엘리먼트를 추가한다.
  • 인터넷 익스플로러는 링크를 만든 앵커 태그 밖으로 “This text should be a link” 라는 텍스트를 밀어 낸다.

이 예의 원본은 Hallvord Steen의 글http://www.thinkvitamin.com/features/dev/same-dom-errors-different-browser-interpretations같은 DOM 에러, 브라우저별로 다른 해석”에서 찾을 수 있다. 이 글을 읽으면 HTML 에러를 좀더 깊이있게 다룰 수 있고, 디버깅 툴에 대한 정보도 얻을 수 있다.

브라우저들의 각기 다른 반응은 잘못된 게 아니다. 브라우저들은 모두 당신이 만든 잘못된 코드의 허점을 채우려고 노력한 것이다. 결국 이거다. 당신이 만든 페이지에서 모든 경우에 유효성 검사를 통과하지 못하는 마크업을 피해라!

쿽스모드 Quirksmode

당신이 알아야 할 또 다른 것은 바로 쿽스모드다. 이것은 브라우저가 잘못된 doctype을 만나거나 doctype이 전혀 없을 때 실행하게 되는 모드다. 이 모드에서, 브라우저는 자기가 할 수 있는 한 최선의 방법으로 이게 유효성 검사를 통과한 코드라면 어떨까를 가정해서 공백을 채운다. 이 모드는 오래된 페이지들을 여전히 보이도록 하기 위해 있는 것이므로, 새로운 페이지를 작성할 때는 절대로 사용하면 안 된다.

페이지 유효성 검사 방법

지금까지 우리는 HTML 유효성 검사의 배경이 되는 이론을 전부 훑어 봤다. 이제 좀더 쉬운 파트로 가자. 바로 실제 유효성 검사다! 맞다. 이게 완전히 정확한 건 아니다. URL을 유효성 검사기에 집어넣고 페이지가 통과하는지 통과하지 못하는지 보는 것은 쉽다. 잘못된 것을 수정하는 과정은 때때로 그리 쉽지는 않다. 에러 메세지가 때로는 암호문 같기 때문이다. 아래에서 몇 가지 예를 보자.

우리가 이 섹션에서 살펴 볼 예제는 다음과 같다.( 여기서 다운로드하거나 볼 수 있다.)

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" lang="en">
  <head>
    <title>Validating your HTML</title>
  </head>
  <body>
    <h2>The tale of Herbet Gruel</h2>
    <p>Welcome to my story. I am a slight whisp of a man, slender and fragile, features wrinkled and worn, eyes sunken into their sockets like rabbits cowering in their burrows. The <em>years have not been kind to me</em>, but yet I hold no regrets, as I have overcome all that sought to ail me, and have been allowed to bide my time, making mischief as I travel to and fro, 'cross the unyielding landscape of the <a href="http://outer-rim-rocks.co.uk" colspan="3">outer rim</a>.</p>

    <h3>Buster</h3>
    <p>Buster is my guardian angel. Before that, he was my dog. Before that, who knows? I lost my dog many moons ago while out hunting geese in the undergrowth. A shot rang out from my rifle, and I called for Buster to collect the goose I had felled. He ran off towards where the bird had landed, but never returned. I never found his body, but I comfort myself with the thought that he did not die; rather he transcended to a higher place, and now watches over me, to ensure my well-being.

    <h3>My possessions</h3>
    <p>A travelling man needs very little to accompany him on the road:</p>
    <ul>
      <li>My hat full of memories</li>
      <li>My trusty walking cane</li>
      <li>A purse that did contain gold at one time</li>
      <li>A diary, from the year 1874<li>
      <li>An empty glasses case</li>
      <li>A newspaper, for when I need to look busy</li>
    </ul>
  </body>

이 간단한 페이지에는, 세 개의 헤딩과, 세 개의 문단, 한 개의 하이퍼링크, 그리고 한 개의 순서없는 목록11 이 있다. 그리고 유효성 검사로 xhtml 1.0 Strict doctype을 사용하도록 설정했다. 이 문서에는 W3C 밸리데이터로 발견할 수 있는 몇몇 에러가 있다.

W3C HTML 밸리데이터

위에서 언급한 것처럼, W3C에는 온라인 밸리데이터가 있다. 여기 보이는 링크를 컨트롤 버튼과 함께 클릭하거나, 오른쪽 클릭한 후 ‘새 탭에서 열기’를 선택하면 볼 수 있다. W3C 온라인 밸리데이터는 밸리데이터와 당신이 예제를 살펴 본 이 글 사이를 왔다갔다 할 수 있게 되는 데 유용하다.

오페라 브라우저에서 오른쪽 클릭을 한 후 “유효성 검사” 옵션을 선택하면 곧장 W3C 밸리데이터로 갈 수 있다.

이 밸리데이터에서 맨 위쪽에 세 개의 탭을 볼 수 있을 것이다.

  • Validate by URI : 유효성 검사를 하고 싶은 페이지가 이미 인터넷에 올라와 있다면, 주소를 집어 넣으면 된다.
  • Validate by File Upload : 유효성 검사를 하고 싶은 HTML 파일을 업로드하면 된다.
  • Validate by Direct Input : 유효성 검사를 하고 싶은 HTML 콘텐츠를 창에 붙여넣기 하면 된다.

당신이 어떤 방법을 사용하든지, 같은 결과를 돌려 줄 것이다. 나는 예제 페이지를 테스트해 보는 가장 쉬운 방법은, 위에 있는 예제 코드 전체를 긁어서 세 번째 탭에다가 붙여 넣는 것이라고 생각한다. 그렇게 하면 그림1 같은 결과를 돌려 줄 것이다.

이건 좀 심각해 보인다. 특히 나는 이 문서에 에러가 17개나 있다고 말한 적이 없다! 절망하지 마라. 이건 실제보다 더 많은 에러를 보고한다. 많은 경우 페이지 맨 위의 에러는 중첩되기 마련이고, [그래서] 더 많은 요소가 닫히지 않거나, 올바르지 않게 중첩된 것처럼 보이게 만든다. 그러면 밸리데이터는 아래쪽으로 갈수록 더 많은 에러를 보고하게 된다. 당신은 단지 에러 메시지가 무엇을 의미하는지 생각하고, 마크업에서 명백한 에러를 찾아야 한다. 아래에 있는 표1은 페이지가 유효성 검사를 통과하도록(validate) 고친 모든 에러들을 보여 준다. 뭐가 잘못됐는지, 내가 세운 논리와 문제 해결 방법에 따라서 [처리한 내용이다.]

에러 메시지 로직 수정 사항
8번 줄, 461번째 글자: “colspan” 어트리뷰트가 없다. 거기에는 colspan 어트리뷰트가 있다. 그리고 이건 밸리데이션을 통과하는 HTML이다. 그럼 왜 없다는 거지? 음… 그럼 아마도 이건 이 엘리먼트를 여기에 쓰면 안 된다는 거 아닐까? 좋아. 이건 a 엘리먼트에용됐고, 이건 틀렸어. a 엘리먼트에서 colspan 어트리뷰트를 제거.
13번 줄, 7번째 글짜: 이 위치에 h3를 사용하면 안 되는 문서형(document type)입니다.; “object”, “applet”, “map”, “iframe”, “button”, “ins”, “del”중 하나의 시작 태그가 없는 것 같습니다. <h3>My possessions</h3> 잠깐, 딱 봐도 이건 이상하다. h3엘리먼트는 제대로 닫혀있다. 그리고 이 위치에 써도 된다. 그러면, 근처에 닫히지 않은 요소가 있다고 생각하면 된다. 헤딩 위에있는 문제의 p 태그를 닫았다.
19번 줄, 40번째 글자: 이 위치에 li를 사용하면 안 되는 문서형입니다; “ul”, “ol”, “menu”, “dir” 중 하나의 시작 태그가 없는 것 같습니다. <li>A diary, from the year 1874<li> 이건 꽤 쉽다. 당신은 그 줄을 잠깐 보고서도 li 태그에 닫는 슬래시(/)가 빠진 것을 알 수 있을 것이다. 문제의 줄에 닫는 슬래시를 추가했다.
23번 줄, 9번째 글자: 생락되면 안 되는 html 태그가 생략됐습니다. 자, 이건 멀리 나갈 것도 없이, 끝나는 html 태그가 없다는 얘기다. 이 에러 메시지 설명은 심지어 “너는 아마 태그 닫는 걸 무시한 것 같다”는 말로 시작한다. 끝나는 html 태그를 추가했다.

이렇게 에러를 고치면, 밸리데이터는 좀더 만족스러운 성공 메시지를 돌려 준다. 아래 그림처럼 말이다.

요약

이 글을 읽은 다음에, 당신은 온라인 밸리데이터로 당신의 HTML 유효성 검사를 하기 좀더 편해졌을 것이다. [그러나] 이건 정말 유효성 검사에 대해서 빙산의 일각에 불과하다. 아래는 좀더 복잡한 유효성 검사기들이다. 당신이 만드는 페이지가 좀더 커지고 복잡해지기 시작할 때 유용할 것이다.
더 많은 유효성 검사기

연습문제

  • 브라우저가 잘못된 HTML을 파싱하면 무슨 일이 일어나는가?
  • 이런 경우 문제는 무엇인가?
  • HTML 4 Strict doctype에서 유효성 검사를 통과한 문서에서 프레임셋을 사용할 경우 어떤 에러가 생기는가?

필자 소개

마크 노만 프랜시스는 웹이 만들어지기 전부터 인터넷에서 일해 왔다. 그의 마지막 일자리는 Yahoo!였다. 그는 거기서 세계 최대의 웹사이트, 최고의 경험, 표준 코딩, 퀄리티를 위한 국제 웹개발 프론트 엔드 아키텍트였다.

Yahoo!에서 일하기 전, 그는 포뮬라 원(Formula One) 매니지먼트, 퍼플 인터랙티브(Purple Interactive)와 시립대학(? City University) 등에서 백엔드 CGI 프로그램과 시스템 아키텍쳐 같은 웹 개발과 관련된 다양한 역할로 일했다. 그는 http://marknormanfrancis.com/ 에서 블로그를 하려고 한다.

이 글과 비슷한 종류의 글은 'HTML' 카테고리에서 더 찾아볼 수 있습니다. 또한, , , 태그로도 검색해 보실 수 있습니다. 북마크를 하시려면 퍼머 링크로 기억해 주세요.
이 글을 다 읽어주셨다면, 댓글을 남겨주세요. 좋았다라는 격려도 좋고, 잘못된 부분을 지적해 주시는 것도 좋습니다. 마음에 드셨다면 아래 Like 버튼을 눌러서 페이스북과 트위터로 소개해 주시면 더욱 좋겠습니다.