HTML : 선택적인 닫기 태그를 포함 또는 제외 하시겠습니까?
일부 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 개
선택 사항은 모두 종료 태그가 없어도 끝 부분에서 의미 적으로 명확해야합니다. EG 는 바로 앞에 하나가 없으면 <li>암시 </li>합니다.
금지 된 종료 태그 뒤에는 즉시 종료 태그가 표시되므로 <img src="blah" alt="blah"></img>매번 입력해야하는 중복이 발생합니다 .
옵션 태그는 더 읽기 쉽고 업데이트 가능한 코드에 적합하기 때문에 거의 항상 선택적 태그를 사용합니다.
명시 적 태그가 도움이되는 경우가 있지만 때로는 불필요한 교육자입니다.
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>
And keep in mind that end tags are implied whether you try to close all elements or not. Putting end tags won't automatically make parsing more robust:
<p>foo <p>bar</p> baz</p>
will parse as:
<p>foo</p><p>bar</p> baz
It can only help when you validate documents.
I am adding some links here to help you with the history of HTML, for you to understand the various contradictions. This is not the answer to your question, but you will know more after reading these various digests.
- How Did We Get Here? – Dive Into HTML5
- The History of the Web
- Brief History of HTML
- HTML’s History – HTML WG Wiki
Some excerpts from Dive Into HTML5:
[T]he fact that “broken” HTML markup still worked in web browsers led authors to create broken HTML pages. A lot of broken pages. By some estimates, over 99% of HTML pages on the web today have at least one error in them. But because these errors don’t cause browsers to display visible error messages, nobody ever fixes them.
The W3C saw this as a fundamental problem with the web, and they set out to correct it. XML, published in 1997, broke from the tradition of forgiving clients and mandated that all programs that consumed XML must treat so-called “well-formedness” errors as fatal. This concept of failing on the first error became known as “draconian error handling,” after the Greek leader Draco who instituted the death penalty for relatively minor infractions of his laws. When the W3C reformulated HTML as an XML vocabulary, they mandated that all documents served with the new
application/xhtml+xmlMIME type would be subject to draconian error handling. If there was even a single well-formedness error in your XHTML page […] web browsers would have no choice but to stop processing and display an error message to the end user.This idea was not universally popular. With an estimated error rate of 99% on existing pages, the ever-present possibility of displaying errors to the end user, and the dearth of new features in XHTML 1.0 and 1.1 to justify the cost, web authors basically ignored
application/xhtml+xml. But that doesn’t mean they ignored XHTML altogether. Oh, most definitely not. Appendix C of the XHTML 1.0 specification gave the web authors of the world a loophole: “Use something that looks kind of like XHTML syntax, but keep serving it with thetext/htmlMIME type.” And that’s exactly what thousands of web developers did: they “upgraded” to XHTML syntax but kept serving it with a text/html MIME type.Even today, millions of web pages claim to be XHTML. They start with the XHTML doctype on the first line, use lowercase tag names, use quotes around attribute values, and add a trailing slash after empty elements like
<br />and<hr />. But only a tiny fraction of these pages are served with theapplication/xhtml+xmlMIME type that would trigger XML’s draconian error handling. Any page served with a MIME type oftext/html— regardless of doctype, syntax, or coding style — will be parsed using a “forgiving” HTML parser, silently ignoring any markup errors, and never alerting end users (or anyone else) even if the pages are technically broken.XHTML 1.0 included this loophole, but XHTML 1.1 closed it, and the never-finalized XHTML 2.0 continued the tradition of requiring draconian error handling. And that’s why there are billions of pages that claim to be XHTML 1.0, and only a handful that claim to be XHTML 1.1 (or XHTML 2.0). So are you really using XHTML? Check your MIME type. (Actually, if you don’t know what MIME type you’re using, I can pretty much guarantee that you’re still using
text/html.) Unless you’re serving your pages with a MIME type ofapplication/xhtml+xml, your so-called “XHTML” is XML in name only.
[T]he people who had proposed evolving HTML and HTML forms were faced with two choices: give up, or continue their work outside of the W3C. They chose the latter, registered the
whatwg.orgdomain, and in June 2004, the WHAT Working Group was born.
[T]he WHAT working group was quietly working on a few other things, too. One of them was a specification, initially dubbed Web Forms 2.0, which added new types of controls to HTML forms. (You’ll learn more about web forms in A Form of Madness.) Another was a draft specification called “Web Applications 1.0,” which included major new features like a direct-mode drawing canvas and native support for audio and video without plugins.
In October 2009, the W3C shut down the XHTML 2 Working Group and issued this statement to explain their decision:
When W3C announced the HTML and XHTML 2 Working Groups in March 2007, we indicated that we would continue to monitor the market for XHTML 2. W3C recognizes the importance of a clear signal to the community about the future of HTML.
While we recognize the value of the XHTML 2 Working Group’s contributions over the years, after discussion with the participants, W3C management has decided to allow the Working Group’s charter to expire at the end of 2009 and not to renew it.
The ones that win are the ones that ship.
The reason i ask is because you just know it's optional for compatibility reasons; and they would have made them (mandatory | forbidden) if they could have.
That's an interesting inference. My reading of it is that just about any time a tag could be reliably inferred, the tag is optional. The design suggests that the intention was to make it quick and easy to write.
What did HTML 1, 2, 3 do with regards to these, now optional, closing tags.
The DTD for HTML 2 is embedded in the RFC which, along with the original HTML DTD, has optional start and end tags all over the place.
HTML 3 was abandoned (thanks to the browser wars) and replaced with HTML 3.2 (which was designed to describe the then current state of the web).
What does HTML 5 do?
HTML 5 was geared towards "paving the cowpaths" from the outset.
And what should i do?
Ah, now that is subjective and argumentative :)
Some people think that explicit tags are better for readability and maintainability by virtue of being in front of the readers eyes.
Some people think that inferred tags are better for readability and maintainability by virtue of not cluttering up the editor.
What does HTML 5 do?
The answer to this question is in the W3C Working Draft: http://www.w3.org/TR/html5/syntax.html#syntax-tag-omission
And what should i do?
It's a matter of style. I try to never omit end tags because it helps me to be rigorous and not omit tags that are necessary.
If it is superfluous, leave it out.
If it serves a purpose (even a seemingly trivial purpose, such as appeasing your IDE or appeasing your eyes), leave it in.
It's rare in a well-defined spec to see optional items that do not affect behavior. With the exception of "comments", of course. But the HTML spec is less of a design spec, and more of a document of the state of current major implementations. So when an item is optional in HTML and it seems to serve no purpose, we may guess that optional nature is merely documentation of a quirk in specific browser.
Looking at the HTML-5 spec RFC section linked above, you see that the optional tags are strangely linked to the presence of comments! That should tell you that the authors are not wearing design hats. They are instead playing the game of "document the quirks" in major implementations. So we can't take the spec too seriously in this respect.
So, the solution is: Don't sweat it. Move on to something that actually matters. :)
I think the best answer is to include closing tags for readability or error detection. However, if you have lots of generated HTML (say, tables of data), you could save significant bandwidth by omitting optional tags.
My recommendation is that you omit most optional close tags, and all optional attributes that you can get away with. Many IDEs will complain so you may not be able to get away with omitting some of these but it is generally better for smaller file size and less clutter. If you have code generators definitely omit end tags there because you can get some good size reduction from it. Usually it doesn't really matter one way or the other.
But when it does matter then act on it. On some recent work of mine I was able to reduce the size of my rendered HTML from 1.5 MB to 800 KB by eliminating most of the generated end and redundant value attributes for the open tag, where the text of the element was the same as the value. I have about 200 tags. I could implement this some other way entirely, but that would be more work ($$$), so this allows me to easily make the page more responsive.
Just out of curiosity I found that if I removed quotes around attributes that didn't need them I could save 20 KB, but my IDE (Visual Studio) doesn't like it. I also was surprised to find that the really long ID that ASP.NET generates account for 20% of my file.
The idea that we could ever get any relevant fraction of HTML strictly valid was misguided in the first place, so do whatever works best for you and your customers. Most tools that I have ever seen or used will say they generate xhtml, but they don't really work 100%, and there isn't any benefit to strict adherence anyway.
Personally, I'm a fan of XHTML and, like ghoppe, "I try to never omit end tags because it helps me to be rigorous and not omit tags that are necessary."
but
If you're deliberately using HTML 4.n, one can't argue that including them makes it easier to consume the document, as the notion of well-formedness as opposed to validity is an XML concept, and you lose that benefit when you forbid certain close tags. So the only issue becomes validity... and if it's still valid without them... you might as well save the bandwidth, no?
Using end tags makes dealing with fragments easier because their behaviour is not dependant on sibling elements. This reason alone should be compelling enough. Does anyone deal with monolithic html documents anymore?
In some curly bracket languages like C#, you can omit the curly braces around an if statement if its only two lines long. for example...
if ([condition])
[code]
but you can't do this...
if ([condition])
[code]
[code]
the third line won't be a part of the if statement. it hurts readability, and bugs can be easily introduced, and be difficult to find.
for the same reasons, i close all tags. tags like the img tag do still need to be closed, just not with a separate closing tag.
If you were writing an HTML parser, would it be easier to parse HTML that included optional closing tags, or HTML that doesn't? I think the optional closing tags being present would make it easier, as I wouldn't have to infer where the closing tag should be.
For that reason, I always include the optional closing tags - on the theory that my page might render faster, as I'm creating less work for the browser's HTML parser.
Do whatever you feel makes the code more readable and maintainable.
Personally I would always be inclined to close <td> and <tr>, but I would never bother with <li>.
For forbidden closing types use syntax like: <img /> With the /> to close the tag which is accepted in xml
참고URL : https://stackoverflow.com/questions/3008593/html-include-or-exclude-optional-closing-tags
'programing tip' 카테고리의 다른 글
| 오류 발생 ( 'msg') vs 새 오류 발생 ( 'msg') (0) | 2020.06.12 |
|---|---|
| 이 확인란은 어떻게 작동하며 어떻게 사용합니까? (0) | 2020.06.12 |
| 장고 모델 사용자 정의 save () 메소드에서 새 객체를 어떻게 식별해야합니까? (0) | 2020.06.10 |
| Log4net이 로그 파일을 쓰지 않습니다 (0) | 2020.06.10 |
| List <>에서 마지막 요소를 어떻게 찾을 수 있습니까? (0) | 2020.06.10 |