NARADESIGN

웹표준, 웹접근성, 유니버설디자인, HTML, CSS, UI, UX, UD


DTD에 따른 FIELDSET & LEGEND 요소 사용법.

본문 건너 뛰기

안녕하세요? 오늘은 HTML DTD에 따른 FIELDSETLEGEND 요소의 다른 사용법에 대하여 공유드리고자 합니다.

  • FIELDSET 요소는 하나의 전송양식(FORM)을 의미 단위로 그룹핑하는 요소로서, 회원가입 페이지의 전송양식을 예로 든다면 ‘필수입력, 선택입력’ 등과 같이 의미구조에 따라 전송할 내용을 그룹핑(또는 분할)하는 역할을 하고 있습니다.
  • LEGEND 요소는 FIELDSET 요소에 대한 캡션(또는 제목)을 제공하여 양식의 이해를 돕는 역할을 하고 있습니다.

혹시 W3C Markup Validation Service 도구를 사용하면서 FIELDSET 요소 안쪽에 어떤 HTML요소는 허락하지 않는다는 오류를 만나보신 적이 없으신지요?
만난적이 없으시다면 아래 경우 중 한 가지 경우에 해당되실 것 같습니다.

  1. HTML 4.01(ST) 문서에서 FIELDSET과 LEGEND의 용법을 정확하게 알고 사용하고 있다. (존경합니다^^)
  2. HTML 4.01(ST) 문서에 대한 Validation Check를 해본적이 없다. (네, 저도 한동안은 뭐..)
  3. Validation Check는 반드시 진행하지만 주로 XHTML 1.0(ST)을 사용한다. (부럽습니다~)
  4. FIELDSET 요소를 사용하지 않거나, 평소에 오류따위는 무시하면서 살고 있다. 대수냐. (… 이리오슈~ 냉큼오슈!)

* ST : DTD의 표준모드(Strict) 또는 호환모드(Transitional)를 모두 일컬음.

HTML 4.01 문서에서 FIELDSET 요소를 사용할 때 FIELDSET의 자식으로서 어떤 HTML요소는 허락하지 않는다는 오류를 만나셨다면 그것은 HTML 4.01에서 FIELDSET과 LEGEND를 적절하게 마크업하지 못했기 때문일 수 있습니다. 하지만 그것이 여러분들의 잘못이라고는 생각하지 않습니다. W3C의 HTML 4.01 스펙 명세서에서 이것을 충분히 설명하지 않았기 때문이라고 생각합니다.

결론부터 말씀드리면 FIELDSET과 LEGEND의 사용법은 DTD에 따라 차이가 있습니다.

HTML 4.01의 경우 FIELDSET 사용시 LEGEND 요소는 반드시 첫 번째 자식(first-child)으로 마크업 되어야 합니다.

LEGEND요소를 FIELDSET의 첫 번째 자식으로 마크업 하지 않는 경우 W3C Validator는 LEGEND 속성이 비었다는 경고 대신에 아래와 같은 오류 메시지를 출력합니다.

  • 현재의 DTD는 이 자리에 "XXX"요소를 허락하지 않아!
  • "FIELDSET"의 닫기 태그가 여기서 나오면 안될껄?

LEGEND요소를 빼먹었다는 언급은 하지 않았지만 두 오류 메시지가 모두 틀린말은 아닙니다. 왜냐하면 LEGEND요소는 FIELDSET의 첫 번째 자식으로 존재해야 하는데 LEGEND가 등장하지 않았음으로 "XXX"라는 요소가 올 자리가 아니라는 사실도 맞고, FIELDSET이 닫히긴 했지만 뭔가 수상하다고 알려주고 있기 때문입니다.
 
이 사실을 모르셨던 분들의 경우가 더 많다고 생각되는데 그 이유인즉은, HTML 4.01 에서 FIELDSET이 나오면 LEGEND가 첫 번째 자식으로 나와야 한다고 명시적으로 설명하지 않았기 때문입니다. (또, 모르죠 웹 표준 만랩 되시는 분들이 보는 문서에는 기술되어 있는지. 하지만 제가 참조하고 있는 HTML 4.01 명세에는 그런 표현이 없는것 같습니다. 혹시 알고 계시면 알려주세요^^)

XHTML 1.0의 경우 FIELDSET 사용시 LEGEND 요소는 생략해도 됩니다.

제가 참조하는 HTML/XHTML 스펙 명세서에서는 관련 내용을 찾을 수 없었기에 W3C의 공개된 메일링 리스트에서 검색된 질답중 Masayasu Ishikawa 라는 분의 답변을 인용하면 아래와 같습니다. 메일 주소가 xxx@w3.org 형식으로 되어 있기에 급 신뢰가 가서 그분의 답변 일부를 인용합니다.

This is one of several places where XHTML 1.0 cannot approximate the definition of HTML 4.01 due to the difference between SGML and XML. XML doesn’t allow the content model like the FIELDSET content model in HTML 4.01, so in order to approximate the definition, XHTML 1.0 had to loosen the content model.

이것은 SGML과 XML간 차이에서 기인하는 것으로 XHTML 1.0을 HTML 4.01과 일치시킬 수 없었던 몇 가지 사례중 하나이다. XML은 HTML 4.01의 FIELDSET과 같은 콘텐츠 모델을 허용하지 않는다. XHTML을 XML의 정의에 일치시키도록 하기 위하여 XHTML 1.0은 FIELDSET 콘텐츠 모델에 대하여 느슨해져야만 했다.

So the semantics hasn’t changed, but the XHTML 1.0 DTDs cannot enforce this restriction due to the limitation of XML 1.0. XML Schema could cope with this problem better, though.

의미는 변하지 않았지만 XHTML 1.0은 XML 1.0의 제한 때문에 이것을 강제할 수 없었다. XML 스키마는 이 문제를 좀 더 개선해서 극복해야 한다고 생각한다.

내용을 이해하는게 쉽지는 않았지만 확실한것은 HTML 4.01과 XHTML 1.0의 FIELDSET/LEGEND 문법이 이렇게 다르고 XHTML 1.0에서는 XML과 콘텐츠 모델을 최대한 일치시키기 위하여 LEGEND 요소를 강제하지 않음으로서 오히려 이 콘텐츠 모델에서만큼은 느슨해지게 되었다 라는 사실입니다.

참조 URI

W3C home >  Mailing lists >  Public >  www-html@w3.org >  February 2002
Re: FIELDSET, LEGEND, HTML, & XHTML
http://lists.w3.org/Archives/Public/www-html/2002Feb/0054.html

글의 오류나 추가정보에 대한 코멘트 언제든 환영합니다. ^^

분류: 웹 접근성,웹 표준 | 2008년 4월 2일, 13:36 | 정찬명 | 댓글: 12개 |
트랙백URI - http://naradesign.net/wp/2008/04/02/137/trackback/

12개의 댓글이 있습니다.

  1. 겐도 댓글:

    HTML 4.01 DTD에서 보면 #PCDATA까지 변형까지 해 가며 매우 구린(;;) 형태를 취하고 있군요. fieldset 다음에 화이트 스페이스만 허용된 후 legend가 나오고 %flow가 오거나 말거나 식입니다.

    [!–
    #PCDATA is to solve the mixed content problem,
    per specification only whitespace is allowed there!
    –]
    [!ELEMENT FIELDSET – – (#PCDATA,LEGEND,(%flow;)*) — form control group –]

    이것이 XHTML 1.0 에서는 정말 XML의 문제로 도망갈 수 밖에 없었습니다.

    [!–
    The fieldset element is used to group form fields.
    Only one legend element should occur in the content
    and if present should only be preceded by whitespace.
    –]
    [!ELEMENT fieldset (#PCDATA | legend | %block; | form | %inline; | %misc;)*]

    생략은 됩니자만 넣으려면 html 4.01처럼 fieldset과 legend 사이엔 공백만 허용됩니다.

  2. 정찬명 댓글:

    역시, 겐도님! 겐도님의 추가설명과 추가번역으로 사건 전모를 이해하는데 많은 도움이 된것 같습니다. 감사합니다.

  3. Outsider 댓글:

    글을 읽다가 질문사항이 생겨서요….
    초급개발자인데 웹표준을 준수하려고 여러 모로 시도는 하고 있는데요.
    저는 보통 XHTML 1.0 Transitional을 사용하고 있는데요 특별한 이유가 있는 건 아니고 표준준수를 하려고 하다보니 html 4.01보다는 xhtml 1.0이 더 철저(?)한것 같아서 따르고 있는데요.
    중간부분에 3번에 xhtml을 쓰는 사람을 부럽다고 표현하신 의미가 궁금합니다. dtd를 비교해서 쓰는건 아니지만 xhtml이라서 크게 쓰기 어렵다거나 하진 않아서요. 보통은 html 4.01을 더 많이 쓰나요?
    그리고 validation check얘기를 하셨는데 에디터(저는 aptana를 쓰고 있습니다.)에서 지원해주는 syntax check말고 w3c등에서 제공하는 validation check를 얘기하시는 건가요?

    오긴 자주오는데 글은 댓글은 처음 남겨 보네요.. 모르는게 너무 많아서요.. ^^

  4. 정찬명 댓글:

    HTML을 쓰거나 XHTML을 쓰거나 DTD를 제대로 선언하기만 한다면 어떤것을 사용해도 무방하다고 생각합니다. HTML과 XHTML 사이에서 어떤 DTD를 쓰는것이 현실적으로 더 매력적인 장점을 지니고 있는지 생각해 볼때 어느 한쪽의 우월함을 주장할만한 뚜렷한 무엇이 없기 때문이라고 생각합니다.

    단지 저도 Outsider님과 같이 XHTML이 더 엄격하고 최신의 DTD이기 때문에 좋은 선택이라고 막연히 생각할 뿐 입니다. XHTML문서는 XML과 함께 사용할 때 장점으로 작용하지만 실제로는 그렇게 사용하는 경우가 드물기 때문에 현실적으로 두 DTD간에 차이가 거의 없는것이나 마찬가지 라고 생각합니다.

    지금 다시 생각해 보면 부럽다고 표현한 것에는 ‘그럼 XHTML이 더 좋은것인가?’ 라는 오해를 불러일으킬 수 있는 표현 같습니다. 제가 부러워한 것은 한 가지 DTD만 줄곧 사용하는것 입니다. 왜냐하면 제가 지금 하고있는 일은 그렇지 않기 때문입니다.

    Validation Check는 W3C의 검사결과를 말한것이 맞습니다. 굳이 다른 도구이면 안될것은 없지만 도구마다 오류를 출력하는 수준이 다를 수 있고 W3C의 검증결과를 기준으로 삼는것이 가장 정확하다고 판단하기 때문입니다. Aptana의 Syntax Check는 제가 아직 사용해 보지 않아서 잘 모르겠지만 W3C와 오류수준이 일치하는지는 직접 오류가 많은 페이지를 한번씩 돌려보면서 확인해 보시면 될 것 같습니다.

    너무 겸손하십니다 ^^; 좋은 하루 되세요~!

  5. wystan 댓글:

    상당히 흥미로운 문제네요. (X)HTML 권고안의 의도(시멘틱)를 DTD가 제대로 지원하지 못할 수도 있다는 사실을 처음 알았습니다.

    관련 정보를 찾아보니 HTML의 기반이 되는 SGML(Standard Serialized Markup Language)과 XML의 DTD 선언에 차이가 있더군요. 요소(element)를 선언할 때 SGML에서는 Mixed Content(텍스트와 요소 컨텐츠를 모두 포함할 수 있는)가 들어갈 경우에도 컨텐츠의 순서와 빈도를 자유롭게 지정할 수 있지만, XML에서는 무조건 | 기호로 표현되는 or로 연결해야 하고 반드시 컨텐츠 목록의 첫 번째 위치에 들어간다고 하네요. 또, 빈도 표현에 있어서 전체 반복으로만 사용해야 한다는 제약도 있습니다. 다시 말해서 SGML에서는 (#PCDATA, (element)*)가 가능하지만 이 선언을 XML DTD로 바꾸면 (#PCDATA | element)* 형태로밖에 변환이 되지 않는다고 합니다(관련 링크: Converting an SGML DTD to XML).

    따라서, HTML에서는 legend 요소의 순서와 빈도를 지정할 수 있지만(,로 연결되었으므로 순서가 지정되었고, 빈도 표현이 없으므로 무조건 한 번 나와야 합니다) XHTML DTD에서는 DTD 자체 한계로 위치나 빈도에 상관없이 legend 요소가 쓰여도 파서가 유효한 마크업으로 판단합니다. 물론, HTML DTD도 완벽하지가 않아서 legend 요소 앞에 whitespace가 아닌 다른 텍스트 컨텐츠가 올 경우에도 파서가 유효하다고 인식합니다. 역시 DTD의 한계 때문에요.

    SGML의 컨텐츠 모델이 훨씬 자유롭지만 Mixed Content가 사용되면서 컨텐츠의 순서와 빈도를 지정하는 경우(Mixed Content를 허용하는 요소 대부분은 이런 제약이 없습니다. p 요소처럼 텍스트나 하위 요소 어느 것이든 포함하기만 하면 되니까요) 심각한 파서 버그(Pernicious Mixed Content)가 발생할 수 있는데 이 문제가 XML의 Mixed Content 처리 방식 단순화에 큰 영향을 주었다고 하네요. 또한, 이런 단순화로 인해 컨텐츠 모델 표현력이 제한되었다는 점을 지적하는 글(Mixed content considered harmful)도 찾을 수가 있었습니다.

    정확히 이해할 수는 없지만 정찬명님의 문제 제기를 통해서 흥미로운 사실을 많이 알게 되었습니다. 좋은 정보 알려주셔서 고맙습니다. ^^

  6. 정찬명 댓글:

    wsystan님, 댓글 감사합니다. HTML도 깊이 파고들수록 어렵다는 생각이 드네요. ㅡㅡ; 한편 댓글쓰기 하실때 HTML 코드 사용 때문에 번거롭게 글을 두번 작성하도록 미리 충분히 알려드리지 못해서 죄송하네요. 댓글 작성시 HTML 코드 사용에 대한 설명을 조만간 보충하도록 하겠습니다. 사용자의 실수는 UI에 즉각 반영해서 같은 실수를 하지 않도록 고쳐야겠죠 ^^ 오늘도 활기찬 하루 되세요. (__)

  7. 황준상 댓글:

    onmouseover와 onmouseout이 html상에 존재해도 됩니까? 항상 다 스크립트 파일로 빼려고 노력하고 있었는데.. 꼭 그럴필요가 없나보네요..

  8. 정찬명 댓글:

    onmouseover, ~out이 본문의 내용과 어떤 관련이 있는지 모르겠지만 말씀하신 대로 되도록 외부로 빼는게 좋겠지요. 하지만 HTML 안에 존재한다고 해서 문제가 되지는 않는다고 생각합니다.

  9. 바나나죠 댓글:

    사소한 궁금증인데요. legend 안에 블록요소 태그가 들어가도 상관이 없을가요?
    개인정보입력

    이런 방식으로 사용해도 문제가 없을까요?

  10. 바나나죠 댓글:

    위에 소스를 꺽쇠를 괄호로 변경을안했었네요

    [fieldset]
    [legend] [h3] 정보입력 [/h3] [/legend]
    ……………………………………
    [/fieldset]

  11. 정찬명 댓글:

    @바나나죠
    legend 요소 내부에는 텍스트 또는 인라인 요소만 자식으로 올 수 있습니다. h3는 블럭 요소라서 유효하지 않게 됩니다.

  12. 바나나죠 댓글:

    네. 답변 감사합니다. :-)

댓글 쓰기

전송된 글이 나타나지 않는다면 필터링 된 것입니다. dece24앳gmail.com 으로 메일 주세요.
(X)HTML 코드 사용이 가능하지만 소스 코드 출력을 원하시면 <꺽쇠>는 [괄호]로 변환하여 작성해 주세요.

필수 아님

필수 아님