HTML : 선택적인 닫기 태그를 포함 또는 제외 하시겠습니까?


149

일부 HTML 1 닫기 태그는 선택 사항입니다 . 예 :

</HTML>
</HEAD>
</BODY>
</P>
</DT>
</DD>
</LI>
</OPTION>
</THEAD>
</TH>
</TBODY>
</TR>
</TD>
</TFOOT>
</COLGROUP>

참고 : 포함 금지 된 닫기 태그와 혼동하지 마십시오 . 예 :

</IMG>
</INPUT>
</BR>
</HR>
</FRAME>
</AREA>
</BASE>
</BASEFONT>
</COL>
</ISINDEX>
</LINK>
</META>
</PARAM>

참고 : xhtml HTML과 다릅니다. xhtml은 xml 형식이며 모든 요소에는 닫는 태그가 필요합니다 . 닫는 태그는 HTML에서 금지 되어 있지만에 필수 입니다 xhtml.

선택적인 닫기 태그입니다

  • 이상적으로 포함되어 있지만 잊어 버린 경우 수락합니다. 또는
  • 이상적으로 포함되어 있지 않지만 입력하면 수락합니다.

즉, 해야 내가 그들을 포함, 또는 내가해야 하지 를 포함?

요소 태그는 선택 사항 인 폐쇄에 대한 HTML 4.01 사양 회담 ,하지만 그들을 포함되지로, 또는 바람직 포함하는 것이 바람직인지 말을하지 않습니다.

반면, DevGuru의 임의 기사는 다음 과 같이 말합니다 .

끝 태그는 선택 사항입니다. 그러나 포함하는 것이 좋습니다.

내가 묻는 이유는 호환성상의 이유로 선택 사항 임을 알고 있기 때문입니다 . 그들이 할 수 있다면 그들은 ( 필수 | 금지 ) 만들었을 것 입니다.

다시 말하면 HTML 1, 2, 3은 이제 선택적인 닫는 태그와 관련하여 무엇을 했습니까? HTML 5의 기능은 무엇입니까? 그리고 무엇을해야 나는 합니까?

노트

HTML에서 일부 요소가된다 금지 닫는 태그를 가지고에서. 당신은 그것에 동의하지 않을 수도 있지만, 그것은 사양이며, 논쟁의 여지가 없습니다. 선택적인 닫기 태그와 의도가 무엇인지 묻고 있습니다.

각주

HTML 4.01 1 개


4
어려운 질문 ... W3C의 권장 사항 중 일부는 심지어 둘 다 할 예 포함 : w3.org/TR/html401/struct/global.html#id-and-class를 첫 번째 예 폐쇄가 </p>태그와 두 번째를 생략을!
Richard JP Le Guen

그냥 명확하게 - HTML5에서 금지 된 태그의 경우, "명시 적"/ XML 유효한 해결책은 그들을 종료하는 />등, <meta charset="utf-8" />비록 <meta charset="utf-8">유효 HTML5는?
cboettig

@cboettig 예. <meta charset="utf-8" />이다 유효하지 않은 HTML을, 그것을 해야한다<meta charset="utf-8">. 다른 손에 <meta charset="tuf-8">있다 무효 XHTML은, 그것은 있어야<meta charset="utf-8" />
이안 보이드

@IanBoyd 정말? HTML5에서? 수개 국어 HTML / XHTML에 대한 초안 W3C 설명서는 사용 말한다 <meta charset="UTF-8"/>닫는 태그로. 그렇지 않으면 어떻게 polyglot 또는 xhtml이 html5 및 xml로 검증 될 수 있습니까?
cboettig

@cboettig 당신이 맞아요. Polyglot Markup (예 : HTML 호환 XHTML 문서 ) 유효한 HTML 4.01 일 수 없습니다 . HTML5 (여전히 진행중인 작업)에는 Void 요소 (종료 태그를 가질 수없는 요소) 라는 개념 이 있습니다 . 아마도 대부분의 브라우저는 완만하고 마크 업 오류를 용서할 것입니다.
Ian Boyd

답변:


49

선택 사항은 모두 종료 태그가 없어도 끝 부분에서 의미 적으로 명확해야합니다. EG 는 바로 앞에 하나가 없으면 <li>암시 </li>합니다.

금지 된 종료 태그 뒤에는 즉시 종료 태그가 표시되므로 <img src="blah" alt="blah"></img>매번 입력해야하는 중복이 발생합니다 .

옵션 태그는 더 읽기 쉽고 업데이트 가능한 코드에 적합하기 때문에 거의 항상 선택적 태그를 사용합니다.


18
나는 지금 그것을 참조하십시오. <LI>총알과 같습니다. 아무도 글 머리 기호 전체를로 감싸고 싶지 않을 것입니다 <LI>...</LI>. 따라서 LI마크 업 중에 사람들이 자연스럽게 쓰는 것과 일치합니다. 단락 <P>처리 (단락)도 마찬가지입니다. 워드 프로세싱에서는 단락 시작 부분에 단락 표시 를 추가합니다 . 그리고 모든 사람의 끝에도 아닙니다. 따라서이 해석에서 닫는 태그는 선택 사항이며 보통 사람은이를 가지고 있다고 생각하지 않기 때문입니다. 또한 요소 자체에는 내용이 없습니다 . 요소 내용입니다.
Ian Boyd

8
에 의해 당신은 무엇을 의미합니까 나는 거의 항상 사용하는 옵션 태그 - 당신은 당신이 뜻 을 포함 종료 태그를, 또는 당신은 그것을 떠나 ? (난 당신이 인상을 가지고 포함 난 당신의 대답을 읽을 때, 그것을 -하지만 이상 코멘트 이안 보이드는 나에게 당신이 인상 준다 제외 를.)
KajMagnus

3
@IanBoyd 그리고 마지막 단락?
Pacerier

22
@Pacerier 사람들은 수백 년 동안 텍스트 단락을 작성해 왔습니다. 단락이 끝날 때 아무도 혼동하지 않았습니다.
Ian Boyd

4
: 실제 참조 문서를 찾기 위해 노력하는 동안이 답을 찾을 사람들을위한 HTML5에 대한 관련 링크 w3.org/TR/html5/syntax.html#optional-tags
마이크 'POMAX'Kamermans

59

명시 적 태그가 도움이되는 경우가 있지만 때로는 불필요한 페 도토리입니다.

HTML 스펙은 태그를 생략 할 수있는 유효시기를 명확하게 지정하므로 항상 오류는 아닙니다.

예를 들어, 필요하지 않습니다 </body></html>. 아무도 넣어 기억<tbody> 명시 적으로 (XHTML이 예외를 낸 시점 .

</head><body>실제로 검색하는 DOM 조작 스크립트 가없는 한 필요하지 않습니다 <head>(암시적인 종료에 대한 규칙 <head>이 놀라 울 수 있기 때문에 명시 적으로 닫는 것이 좋습니다).

중첩 된 목록은 실제로는없는 </li>경우에 더 좋습니다 . 왜냐하면 잘못된 목록을 만드는 것이 더 어렵 기 때문입니다.ul > ul . 트리 입니다.

유효한:

<ul>
  <li>item
  <ul>
    <li>item
  </ul>
</ul>

유효하지 않습니다 :

<ul>
  <li>item</li>
  <ul>
    <li>item</li>
  </ul>
</ul>

또한 모든 요소를 ​​닫으려고하는지 여부에 관계없이 종료 태그가 암시됩니다. 종료 태그를 넣어도 자동으로 구문 분석이 더 강력 해지지는 않습니다.

<p>foo <p>bar</p> baz</p>

다음과 같이 파싱합니다 :

<p>foo</p><p>bar</p> baz

문서를 확인할 때만 도움이 될 수 있습니다.


4
잠깐, 왜 <p>foo <p>bar</p> baz</p>두 개의 중첩 p태그 로 구문 분석되지 않습니까?
Eric

19
때문에 <P>소자 블록 레벨 요소를 포함 할 수없고, <P>블록 레벨 요소이다. ( w3.org/TR/REC-html40/struct/text.html#edef-P ) "P 요소는 단락을 나타내며 블록 수준 요소 (P 자체 포함)를 포함 할 수 없습니다."
Ian Boyd

1
@IanBoyd CSS 규칙에 관계없이 블록 레벨 요소를 포함 할 수 없습니까?
Pacerier

6
@Pacerier CSS는 어떤 식 으로든 DOM에 영향을 줄 수 없습니다. DOM이 먼저 구문 분석 된 후 CSS가이를 표시합니다. CSS block표시는 HTML의 블록 수준 내용과는 완전히 다릅니다 (대부분의 HTML 블록 수준 요소는 기본적으로 CSS 블록으로 표시됩니다).
Kornel

2
@ anton1980 아니요, 동일하지 않습니다. 생략 된 선택적 닫는 태그 처리는 명확하게 지정되며 모든 호환 브라우저에서 안정적으로 작동합니다. OTOH 메이크업 <t>은 다음과 같이 작동하지 않습니다 <title>.
Kornel

18

다양한 모순을 이해하기 위해 HTML 기록에 도움이되는 몇 가지 링크를 여기에 추가하고 있습니다. 이것은 귀하의 질문에 대한 답변이 아니지만 이러한 다양한 요약을 읽은 후에 더 많이 알게 될 것입니다.

Dive Into HTML5의 일부 발췌 :

[T] 그는 "브로큰"HTML 마크 업이 여전히 웹 브라우저에서 작동했다는 사실로 인해 제작자는 깨진 HTML 페이지를 만들었습니다. 깨진 페이지가 많이 있습니다. 일부 추정에 따르면 오늘날 웹에서 HTML 페이지의 99 % 이상이 오류가 하나 이상 있습니다. 그러나 이러한 오류로 인해 브라우저가 눈에 띄는 오류 메시지를 표시하지 않으므로 아무도 수정하지 않습니다.

W3C는이 문제를 웹의 근본적인 문제로 보았고이를 해결하기 시작했습니다. 1997 년에 출판 된 XML은 고객을 용서하는 전통에서 벗어 났으며 XML을 소비 한 모든 프로그램은 소위 "잘 구성된"오류를 치명적인 것으로 처리해야한다고 규정했습니다. 그리스의 지도자 드라코 (Draco) 가 그의 법을 상대적으로 경미하게 위반 한 것에 대해 사형을 제정 한 후 첫 번째 오류에 실패했다는이 개념은“dracoian error handling”으로 알려졌다 . W3C가 HTML을 XML 어휘로 재구성했을 때, 그들은 새로운 application/xhtml+xmlMIME 유형으로 제공되는 모든 문서는 드라코 니안 오류 처리의 대상이되어야한다고 규정했다. XHTML 페이지 […]에 단일 형식 오류 만있는 경우 웹 브라우저는 처리를 중지하고 최종 사용자에게 오류 메시지를 표시 할 수 있습니다.

이 아이디어는 보편적으로 인기가 없었습니다. 기존 페이지에서 99 %의 예상 오류율, 최종 사용자에게 오류를 표시 할 가능성, XHTML 1.0 및 1.1의 새로운 기능이 부족하여 비용을 정당화하기 때문에 웹 작성자는 기본적으로 무시했습니다 application/xhtml+xml. 그렇다고 XHTML을 완전히 무시한 것은 아닙니다. 아, 가장 확실하지 않습니다. XHTML 1.0 사양의 부록 C는 전세계 웹 제작자들에게 다음과 같은 허점을 주었다.“XHTML 구문과 비슷한 것을 사용하되 text/htmlMIME 유형으로 계속 제공하십시오 .” 바로 수천 명의 웹 개발자가 XHTML 구문으로“업그레이드”했지만 텍스트 / html MIME 유형으로 계속 제공했습니다.

오늘날에도 수백만 개의 웹 페이지가 XHTML이라고 주장합니다. 그들은 첫 번째 줄, 사용 소문자 태그 이름, 속성 값 주위에 사용 따옴표에 XHTML의 문서 타입으로 시작하고, 같은 빈 요소 후 후행 슬래시를 추가 <br />하고 <hr />. 그러나이 페이지들 중 아주 적은 부분 ​​만이 application/xhtml+xmlXML의 드라코 니안 오류 처리를 유발 하는 MIME 유형 과 함께 제공됩니다 . text/htmldoctype, 구문 또는 코딩 스타일에 관계없이 MIME 유형으로 제공되는 모든 페이지 는 "용서하는"HTML 구문 분석기를 사용하여 구문 분석되어 마크 업 오류를 자동으로 무시하고 페이지가 있어도 최종 사용자 (또는 다른 사람)에게 경고하지 않습니다. 기술적으로 고장났습니다.

XHTML 1.0은 이러한 허점을 포함했지만 XHTML 1.1은이를 막았으며, 최종적으로 완성되지 않은 XHTML 2.0은 드라코 니안 오류 처리를 요구하는 전통을 이어갔습니다. 그렇기 때문에 XHTML 1.0이라고 주장하는 수십억 페이지가 있고 XHTML 1.1 (또는 XHTML 2.0)이라고 주장하는 소수만이 있습니다. 정말 XHTML을 사용하고 있습니까? MIME 유형을 확인하십시오. (실제로, 사용중인 MIME 유형을 모르는 경우에도 여전히 사용하고 있음을 거의 보증 할 수 있습니다 text/html.) MIME 유형이 application/xhtml+xml인 페이지를 제공하지 않는 경우 소위 "XHTML" 이름 만있는 XML입니다.

진화하는 HTML 및 HTML 양식을 제안한 사람들은 두 가지 선택에 직면했다. 그들은 후자를 선택하고 whatwg.org도메인을 등록했으며 2004 년 6 월에 WHAT 워킹 그룹이 탄생했습니다 .

[T] 그는 워킹 그룹이 몇 가지 다른 일을 조용히하고 있었다. 그중 하나는 처음에는 Web Forms 2.0 이라고 불리는 사양 으로 HTML 양식에 새로운 유형의 컨트롤을 추가했습니다. 웹 양식에 대한 자세한 내용은 A Form of Madness에서 확인할 수 있습니다. 또 다른 하나는 "Web Applications 1.0"이라는 초안 사양으로 , 직접 모드 드로잉 캔버스 와 같은 주요 새로운 기능과 플러그인없이 오디오 및 비디오에 대한 기본 지원이 포함되었습니다 .

2009 년 10 월 W3C는 XHTML의 2 워킹 그룹을 종료 하고 자신의 결정을 설명하기 위해이 성명을 발표했다 :

W3C가 2007 년 3 월에 HTML 및 XHTML 2 실무 그룹을 발표했을 때, 우리는 XHTML 2 시장을 지속적으로 모니터링 할 것이라고 지시했습니다. W3C는 HTML의 미래에 대해 커뮤니티에 분명한 신호의 중요성을 인식하고 있습니다.

우리는 수년간 XHTML 2 워킹 그룹이 기여한 가치를 인정하지만 참가자들과 논의한 후 W3C 경영진은 워킹 그룹 헌장이 2009 년 말에 만료되고 갱신하지 않기로 결정했습니다.

이기는 것이 배송되는 것입니다.


12

내가 묻는 이유는 호환성상의 이유로 선택 사항임을 알고 있기 때문입니다. 그리고 가능하다면 그들은 (필수 | 금지) 만들었을 것입니다.

흥미로운 추론입니다. 내가 읽은 내용은 태그가 확실하게 유추 될 수있을 때마다 태그는 선택 사항이라는 것입니다. 디자인은 의도가 빠르고 쉽게 작성되도록하는 것이 었습니다.

HTML 1, 2, 3은 이제 선택적인 닫는 태그와 관련하여 수행 한 작업입니다.

HTML 2 용 DTD 는 원본 HTML DTD 와 함께 옵션으로 시작 및 종료 태그가 있는 RFC에 RFC에 포함되어 있습니다.

HTML 3은 버려졌으며 (브라우저 전쟁 덕분에) 당시의 웹 상태를 설명하도록 설계된 HTML 3.2로 대체되었습니다.

HTML 5의 기능은 무엇입니까?

HTML 5는 처음부터 "우박 길 포장"에 맞춰졌습니다.

그리고 어떻게해야합니까?

아, 이제는 주관적이고 논쟁의 여지가 있습니다 :)

어떤 사람들은 독자적인 눈앞에 있기 때문에 명확한 태그가 가독성과 유지 관리에 더 좋다고 생각합니다.

어떤 사람들은 유추 된 태그가 편집기를 어지럽히 지 않기 때문에 가독성과 유지 관리 성이 더 좋다고 생각합니다.


1
+1 나는 "신뢰하게 추론되었다"는 생각을하지 않았다. 그래서 어떤 식 으로든 의도가 전혀 없다는 생각을 옹호합니다. 사양이 기존 HTML 내용 및 HTML 사양과 가능한 한 호환되도록 시도하고 있다고 가정했습니다.
Ian Boyd

미안, 데이브, 나는 그것을 명반에 줬다. 그는 담당자가 필요합니다 :) 그러나 당신은 더 링크되고 인용 된 내용으로 동일한 아이디어를 가지고 있습니다. 그러나 좋은 대답입니다.
Ian Boyd

8

HTML 5의 기능은 무엇입니까?

이 질문에 대한 답변은 W3C 실무 초안에 있습니다 : http://www.w3.org/TR/html5/syntax.html#syntax-tag-omission

그리고 어떻게해야합니까?

스타일의 문제입니다. 나는 끝 태그를 생략하지 않으려 고 노력합니다. 왜냐하면 나는 그것이 엄격하고 필요한 태그를 생략 하지 않도록 도와주기 때문 입니다.


HTML 5 사양 초안 링크 및 해당 섹션에 +1 그러나 html 5는 어떤 식 으로든 말하지 않습니다.
Ian Boyd

6

불필요한 경우에는 그대로 두십시오.

그것이 목적을 제공하는 경우 (IDE 나 눈을 감는 것과 같이 사소한 목적으로도), 그대로 두십시오.

잘 정의 된 사양에서는 동작에 영향을 미치지 않는 선택적 항목을 보는 경우가 거의 없습니다. 물론 "코멘트"를 제외하고. 그러나 HTML 사양은 디자인 사양이 아니며 현재 주요 구현 상태에 대한 문서입니다. 따라서 HTML에서 항목이 선택적이고 목적이없는 것 같으면 선택적인 특성이 특정 브라우저의 기발한 문서 일 것이라고 추측 할 수 있습니다.

위에 링크 된 HTML-5 스펙 RFC 섹션을 보면 선택적 태그가 주석의 존재와 이상하게 링크되어 있음을 알 수 있습니다! 저자가 디자인 모자를 쓰고 있지 않다는 것을 알려 주어야합니다. 대신 주요 구현에서 "특별한 문서화"게임을하고있다. 따라서 우리는이 점에서 스펙을 너무 심각하게 받아 들일 수 없습니다.

해결책은 : 땀 흘리지 마십시오. 실제로 중요한 것으로 이동하십시오. :)


5

가장 좋은 대답은 가독성이나 오류 감지를 위해 닫는 태그를 포함시키는 것입니다. 그러나 생성 된 HTML (예 : 데이터 테이블)이 많은 경우 선택적 태그를 생략하여 상당한 대역폭을 절약 할 수 있습니다.


2
Richard : 구조가 깊게 중첩 된 경우 닫는 태그가 의도에 대한 자세한 정보를 제공하므로 오류를 찾기가 훨씬 쉽습니다.
Gabe

1
"닫는 태그는 의도에 대한 자세한 정보를 제공합니다."가이 질문에 대한 가장 간결한 답변이라고 생각합니다. 어떤 식 으로든 좋은 이유를 주장합니다.
squarecandy

4

내 권장 사항은 대부분의 선택적 닫기 태그와 함께 사용할 수있는 모든 선택적 속성을 생략하는 것입니다. 많은 IDE가 불만을 제기하므로 일부를 생략하지 못할 수도 있지만 일반적으로 파일 크기가 작고 클러 터가 적을수록 좋습니다. 코드 생성기가 있으면 크기를 줄이면 끝 태그를 생략 할 수 있습니다. 일반적으로 어떤 식 으로든 중요하지 않습니다.

그러나 그것이 중요 할 때 행동하십시오. 최근의 일부 작업에서 열린 태그에 대해 생성 된 최종 및 중복 값 속성을 대부분 제거하여 렌더링 된 HTML의 크기를 1.5MB에서 800KB로 줄일 수있었습니다. 요소의 텍스트는 값. 약 200 개의 태그가 있습니다. 나는 이것을 다른 방식으로 완전히 구현할 수는 있지만 더 많은 작업 ($ $ $)이 될 것이므로 페이지의 반응 속도를 쉽게 만들 수 있습니다.

호기심으로 인해 필요하지 않은 속성 주위의 따옴표를 제거하면 20KB를 절약 할 수 있지만 IDE (Visual Studio)는 마음에 들지 않습니다. 또한 ASP.NET이 생성하는 정말 긴 ID가 내 파일의 20 %를 차지한다는 사실에 놀랐습니다.

우리가 HTML의 모든 부분을 엄격하게 유효하게 만들 수 있다는 생각은 처음부터 잘못 인도되었으므로 귀하와 고객에게 가장 적합한 것은 무엇이든하십시오. 내가 보거나 사용한 대부분의 도구는 xhtml을 생성한다고 말하지만 실제로는 100 % 작동하지 않으며, 엄격하게 준수해도 아무런 이점이 없습니다.


선택적인 종료 태그를 생략하는 것은 거의 불가능하지만 속성에서 따옴표를 생략하는 것은 좋지 않은 생각입니다. 그런 식으로 사이트를 일부 브라우저에서 침입 할 위험이 있습니다. 800kb html 파일이 있다면 심각하게 잘못한 것입니다.
Christoph

2
@Christoph : HTML 사양에 따라 선택적 종료 태그 ( </p>또는 같은 </li>)를 생략 해도 좋습니다. 브라우저가이를 이해하지 못하면 브라우저에 문제가있는 것입니다.
Konrad Borowski

2

개인적으로 저는 XHTML의 팬이며 ghoppe와 마찬가지로 "끝 태그는 생략하지 않아도되므로 필요한 태그를 생략하지 않아도됩니다."

그러나

의도적으로 HTML 4.n을 사용하는 경우 유효성과 반대되는 형식의 개념이 XML 개념이므로 문서를 사용하면 문서를 더 쉽게 사용할 수 있다고 주장 할 수 없습니다. 특정 닫기 태그를 금지 합니다. 따라서 유일한 문제는 타당성이됩니다. 그리고 그것이없는 경우에도 여전히 유효하다면 ... 대역폭을 절약 할 수 있습니다.


2

종료 태그를 사용하면 동작이 형제 요소에 의존하지 않기 때문에 조각을보다 쉽게 ​​처리 할 수 ​​있습니다. 이 이유만으로도 충분히 매력적이어야합니다. 더 이상 모 놀리 식 HTML 문서를 다루는 사람이 있습니까?


1

C #과 같은 일부 중괄호 언어에서는 두 줄만 있으면 if 문에서 중괄호를 생략 할 수 있습니다. 예를 들어 ...

if ([조건])
    [코드]

그러나 당신은 이것을 할 수 없습니다 ...

if ([조건])
    [코드]
    [코드]

세 번째 줄은 if 문의 일부가 아닙니다. 가독성이 떨어지고 버그가 쉽게 소개되어 찾기가 어려울 수 있습니다.

같은 이유로 모든 태그를 닫습니다. img 태그와 같은 태그는 별도의 닫는 태그가 아닌 닫혀 있어야합니다.


너무 까다로운 HTML의 예를 들어 주시겠습니까? 내 경험상 선택적 종료 태그는 그리 기만적이지 않습니다.
Kornel

몇 년 전에 IE7에 문제가 있었는데 기억 해둔 li없이 포함 된 텍스트와 별도의 줄에서 여는 li 태그를 찾았습니다. IE7은 모든 글 머리 기호를 하나의 큰 글 머리 기호처럼 취급했습니다. 태그와 텍스트를 한 줄에 배치하거나 태그를 닫으면 문제가 해결됩니다. 그러나 지금은 이것을 재현 할 수 없으므로 아마도 CSS와 관련이있을 것입니다. 하지만 나는 이것을 "캐나다에있는 여자 친구가있다"고 생각한다고 당신을 비난하지 않을 것입니다. 이야기.
MiguelR

0

HTML 파서를 작성하는 경우 선택적인 닫는 태그가 포함 된 HTML 또는 그렇지 않은 HTML을 구문 분석하는 것이 더 쉬울까요? 선택적인 닫기 태그가 있으면 닫기 태그의 위치를 ​​추론 할 필요가 없기 때문에 더 쉬울 것이라고 생각합니다.

따라서 브라우저의 HTML 파서에 대한 작업을 줄이면서 페이지를 더 빠르게 렌더링 할 수 있다는 이론에 따라 항상 선택적인 닫기 태그를 포함시킵니다.


1
동의하지 않습니다. 유효성과 반대되는 올바른 형식의 개념은 XML 전용 개념이며 닫기 태그가 금지 된 요소가있는 경우 관련이 없습니다 .
Richard JP Le Guen

1
이해하지만 HTML 태그가없는 경우에도 렌더링 된 DOM 요소에는 시작과 끝이 모두 있습니다. <li>닫는 태그가없는 태그 를 포함하면 어느 시점에서 브라우저는 요소가 끝나는 위치를 결정하고 그 시점에 종료 태그를 놓은 것처럼 행동해야합니다. 이것은 상대적으로 사소한 양의 논리 일 수 있지만 "일부"는 여전히 "없음"이상이며 선택적 종료 태그를 제외하면 브라우저를 포함하는 것보다 더 많은 작업을 수행한다고 가정하는 것은 합리적이라고 생각하지 않습니다.
Joel Mueller

흥미로운 점이지만 여전히 동의하지 않습니다. 닫기 태그는 선택 사항이므로 유효성 검사 규칙에 따라 암시 적이므로 파서가 유효성 검사에 따라 닫기 태그 있어야 하는 지점에 도달하면 소비 작업이 논쟁의 여지가 없음 닫는 태그 (있는 경우)가 느려질까요?
Richard JP Le Guen

@Richard-특정 브라우저에서의 실제 구현에 달려 있다고 생각하지만 요소를 끝내려는 위치에 대해 명시 적으로 명시하는 것이 브라우저가 그것을 알아 내도록 지시하는 것보다 성능이 나빠질 것이라는 생각에 어려움을 겪고 있습니다. 당신.
Joel Mueller

@RichardJPLeGuen 나는 규칙이 어떻게 보이는지에 달려 있다고 생각합니다. 를 닫고 </table>스택에을 포함 <table><tbody><tr><td>시키면를 일치시킬 때까지 모든 것을 닫을 수 있습니다 <table>. <p>시계가 아닌 상황에서 여는 것과 비슷합니다. 그러나 더 어려운 경우가있을 수 있습니다.
maaartinus

-1

코드를 더 읽기 쉽고 유지 보수하기 쉽게 만든다고 생각하십시오.

개인적으로 나는 항상 닫 기울어 것 <td>하고 <tr>,하지만 난 신경 쓰지 않을 것입니다 <li>.


1
나는 원래의 디자인 결정에 대한 지침을 원했고, 가능 하다면 x를 했을 것으로 기대했다.
Ian Boyd

무엇의 차이입니다 <td>그리고 <li>그건 당신이 신경 쓰지한다 <li>? 나에게는 약간의 차이가 있습니다.
ghoppe

기술적 차이는 없습니다. 순전히 주관적입니다. td와 tr을 닫으면 HTML을 더 잘 읽을 수 있다고 생각합니다. 그러나 나는 li의 필요성을 느낀 적이 없습니다.
Matthew Wilson

-2

금지 된 닫기 유형의 경우 다음과 같은 구문을 <img />사용하십시오. />으로 XML에서 허용되는 태그를 닫으십시오.


1
HTML4에서는 작동하지 않습니다 (약간 다른 무언가를 수행하는 모호한 SGML 구문과 일치합니다). HTML5에서는 허용되지만 의미가 없습니다.
Kornel
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.