5 ms·

+1 for XHTML. I never understood why people think it's a good idea to avoid closing elements. It's like a dangling brace to me... it nags me and it just doesn't

+1 for XHTML. I never understood why people think it's a good idea to avoid closing elements. It's like a dangling brace to me... it nags me and it just doesn't look right. How is it seen as acceptable practice?

vbezhenar 6y ago
It's not a good idea to close all elements in HTML because browser does not care about your closing elements, they'll be closed automatically regardless of whether you closed them or not. And your closed elements will be opened automatically. List: <ul><li>item1</li></ul> of items becomes List: <ul><li>item1</li></ul> of items and that's probably not what you wanted. So you have to understand auto-closing behaviour either way. And if you understand it, you can just spare yourself from closing them. Now with XHTML, that's a different thing. But I think that ship sailed many years ago and HTML is a preferred way to go nowadays.
- dataflow 6y ago
 Wow, today I learned! I didn't realize that transformation would take place. I wonder how many people writing HTML are aware of these... your comment basically made me realize I in fact simply don't know HTML. Thanks!
- runarberg 6y ago
 Your linter should warn you about these. E.g. if you use prettier the first `` will be automatically closed on auto-format before the `<ul>`, and the second (closing) `` will cause a parsing error.
 - sergeykish 6y ago
 Sometimes we want <ul> inside [1]. It works in DOM, it works in XHTML. And before "you should not want to do it" argument GML (SGML predecessor) had paragraph without indentation so text can continue after list [2]. > The pc tag identifies a paragraph continuation -- that is, one or more sentences related by their subject matter to a paragraph which has been interrupted by an address, example, figure, list, or long quotation. > Usage: The paragraph continuation can occur after the sequence consisting of a paragraph unit followed by an address, example, figure, list, or long quotation. :p.The subject of a paragraph might be continued through :sl :li.an address, a list, :li.an example or figure, or :li.a long quotation, :esl :pc.and continue to be discussed in flowing text. The discussion could continue indefinitely through To long to quote entirely [3], unfortunately IBM destroyed online version [1] https://www.google.com/search?q=list+inside+paragraph+site%3Astackoverflow.com https://www.google.com/search?q=list+inside+paragraph+site%3... [2] SH20-9160-0 DCF Generalized Markup Language GML Users Guide, First Edition (July 1978) [3] http://sergeykish.com/gml-element-pc http://sergeykish.com/gml-element-pc
- deleted 6y ago
 [deleted]
- cookiengineer 6y ago
 > they'll be closed automatically regardless of whether you closed them or not. Actually that is not really true. It is defined per html5 spec what is closed automatically when another open node is being parsed. The element always had a weird flow-root behaviour, that is why it is always closed automatically. Rather than that iirc mostly form relevant elements are also closed automatically, like optgroup, option, select, input and such. Additionally it's only table (same problem with flow root) and body, pretty much. I can understand that a lot of people are confused why that is. But the reason is not the difference of XML vs SGML per se (xhtml will simply break if a p is within a p)... it's the flow root model and the difference in behaviours of layouting that is specified here, not the notation structure. So SGML was the better choice, to allow all php crapsites that never test their html validity to still run rather than forcing the enduser to (fix?) the xml. I mean, at some point opera didn't even work on bbcode based forum software(s), so people quickly started abandoning it.
 - tannhaeuser 6y ago
 FWIW, there's a complete SGML DTD capturing these and all other HTML rules for tag omission/inference with extensive docs at my site [1]. [1]: http://sgmljs.net/docs/html52.html http://sgmljs.net/docs/html52.html
 - cookiengineer 6y ago
 Woah this is actually very nice, very nice indeed. I'm currently building my own HTML5 parser for my browser stealth [1] and I aim to be spec-compliant with it, and this might come in very handy for testing against. What I kind of miss with SGML as a feature is something similar to XSLT stylesheets that can transform chunks of a website into another chunk. Currently I'm kind of reinventing the wheel here due to my optimizer having the idea to "upgrade" websites on the fly before they get to the client. If all websites were XHTML1.1 strict based, that part would have been so much easier. [1] https://github.com/tholian-network/stealth https://github.com/tholian-network/stealth
 - tannhaeuser 6y ago
- Mikhail_Edoshin 6y ago
 It's only because there's a known structure for HTML. A block-level element cannot be within another block, but you have to know that "p" and "ul" are block-level. Explicit closing does not require you to know the structure and thus makes the processing simpler. It's as in JavaScript: you can omit the ";" at the end of a statement and the parser will figure it out, but it only makes the parser more complex and introduces subtle differences you have to learn. If JS parser were more strict, it would be simpler both internally and conceptually.
 - wayvey 6y ago
 The second sentence is wrong: there's nothing wrong with nested block elements, but you never nest block elements inside inline elements. For example <div> elements are block-level and they are nested all the time. There are some exceptions though such as your example of an <ul> in a . The tag only permits "phrasing content" within itself, and <ul> isn't considered phrasing content. MDN definition of phrasing content: https://developer.mozilla.org/en-US/docs/Web/Guide/HTML/Content_categories#Phrasing_content https://developer.mozilla.org/en-US/docs/Web/Guide/HTML/Cont...
 - Mikhail_Edoshin 6y ago
 Thanks for the correction (I don't really know the HTML flow model and was guessing it.)
- lucideer 6y ago
 > you have to understand auto-closing behaviour either way You do, if you use HTML, but my read of the above two comments was that they would've preferred if the world had stuck on the XHTML path. > Now with XHTML, that's a different thing. But I think that ship sailed many years ago and HTML is a preferred way to go nowadays. Actually, XHTML is a (little-known) part of the HTML5 spec.[0], so going the strict path is still an option. In the past, this would've required complex content-negotiation for media-type backward-compat but that's no longer an issue unless a non-neglible % of your visitors are using IE8. The only remaining issue is that of draconian error handling, which is an issue browsers definitely would have fixed the UX of had the mainstream stayed on the XHTML track, but sadly that never happened. Still, good modern support for server-side validation of well-formed XML documents means this is also less of an issue than it once was (though tbh, still a significant issue imo). W3 have also put together a more informal guide to modern XHTML considerations within the HTML5 spec. https://dev.w3.org/html5/html-polyglot/html-polyglot.html https://dev.w3.org/html5/html-polyglot/html-polyglot.html [0] https://html.spec.whatwg.org/multipage/xhtml.html https://html.spec.whatwg.org/multipage/xhtml.html

vbezhenar 6y ago

It's not a good idea to close all elements in HTML because browser does not care about your closing elements, they'll be closed automatically regardless of whether you closed them or not. And your closed elements will be opened automatically. List: <ul><li>item1</li></ul> of items becomes List: <ul><li>item1</li></ul> of items and that's probably not what you wanted. So you have to understand auto-closing behaviour either way. And if you understand it, you can just spare yourself from closing them. Now with XHTML, that's a different thing. But I think that ship sailed many years ago and HTML is a preferred way to go nowadays.

dataflow 6y ago
Wow, today I learned! I didn't realize that transformation would take place. I wonder how many people writing HTML are aware of these... your comment basically made me realize I in fact simply don't know HTML. Thanks!
runarberg 6y ago
Your linter should warn you about these. E.g. if you use prettier the first `` will be automatically closed on auto-format before the `<ul>`, and the second (closing) `` will cause a parsing error.
- sergeykish 6y ago
 Sometimes we want <ul> inside [1]. It works in DOM, it works in XHTML. And before "you should not want to do it" argument GML (SGML predecessor) had paragraph without indentation so text can continue after list [2]. > The pc tag identifies a paragraph continuation -- that is, one or more sentences related by their subject matter to a paragraph which has been interrupted by an address, example, figure, list, or long quotation. > Usage: The paragraph continuation can occur after the sequence consisting of a paragraph unit followed by an address, example, figure, list, or long quotation. :p.The subject of a paragraph might be continued through :sl :li.an address, a list, :li.an example or figure, or :li.a long quotation, :esl :pc.and continue to be discussed in flowing text. The discussion could continue indefinitely through To long to quote entirely [3], unfortunately IBM destroyed online version [1] https://www.google.com/search?q=list+inside+paragraph+site%3Astackoverflow.com https://www.google.com/search?q=list+inside+paragraph+site%3... [2] SH20-9160-0 DCF Generalized Markup Language GML Users Guide, First Edition (July 1978) [3] http://sergeykish.com/gml-element-pc http://sergeykish.com/gml-element-pc
deleted 6y ago
[deleted]
cookiengineer 6y ago
> they'll be closed automatically regardless of whether you closed them or not. Actually that is not really true. It is defined per html5 spec what is closed automatically when another open node is being parsed. The element always had a weird flow-root behaviour, that is why it is always closed automatically. Rather than that iirc mostly form relevant elements are also closed automatically, like optgroup, option, select, input and such. Additionally it's only table (same problem with flow root) and body, pretty much. I can understand that a lot of people are confused why that is. But the reason is not the difference of XML vs SGML per se (xhtml will simply break if a p is within a p)... it's the flow root model and the difference in behaviours of layouting that is specified here, not the notation structure. So SGML was the better choice, to allow all php crapsites that never test their html validity to still run rather than forcing the enduser to (fix?) the xml. I mean, at some point opera didn't even work on bbcode based forum software(s), so people quickly started abandoning it.
- tannhaeuser 6y ago
 FWIW, there's a complete SGML DTD capturing these and all other HTML rules for tag omission/inference with extensive docs at my site [1]. [1]: http://sgmljs.net/docs/html52.html http://sgmljs.net/docs/html52.html
 - cookiengineer 6y ago
 Woah this is actually very nice, very nice indeed. I'm currently building my own HTML5 parser for my browser stealth [1] and I aim to be spec-compliant with it, and this might come in very handy for testing against. What I kind of miss with SGML as a feature is something similar to XSLT stylesheets that can transform chunks of a website into another chunk. Currently I'm kind of reinventing the wheel here due to my optimizer having the idea to "upgrade" websites on the fly before they get to the client. If all websites were XHTML1.1 strict based, that part would have been so much easier. [1] https://github.com/tholian-network/stealth https://github.com/tholian-network/stealth
 - tannhaeuser 6y ago
Mikhail_Edoshin 6y ago
It's only because there's a known structure for HTML. A block-level element cannot be within another block, but you have to know that "p" and "ul" are block-level. Explicit closing does not require you to know the structure and thus makes the processing simpler. It's as in JavaScript: you can omit the ";" at the end of a statement and the parser will figure it out, but it only makes the parser more complex and introduces subtle differences you have to learn. If JS parser were more strict, it would be simpler both internally and conceptually.
- wayvey 6y ago
 The second sentence is wrong: there's nothing wrong with nested block elements, but you never nest block elements inside inline elements. For example <div> elements are block-level and they are nested all the time. There are some exceptions though such as your example of an <ul> in a . The tag only permits "phrasing content" within itself, and <ul> isn't considered phrasing content. MDN definition of phrasing content: https://developer.mozilla.org/en-US/docs/Web/Guide/HTML/Content_categories#Phrasing_content https://developer.mozilla.org/en-US/docs/Web/Guide/HTML/Cont...
 - Mikhail_Edoshin 6y ago
 Thanks for the correction (I don't really know the HTML flow model and was guessing it.)
lucideer 6y ago
> you have to understand auto-closing behaviour either way You do, if you use HTML, but my read of the above two comments was that they would've preferred if the world had stuck on the XHTML path. > Now with XHTML, that's a different thing. But I think that ship sailed many years ago and HTML is a preferred way to go nowadays. Actually, XHTML is a (little-known) part of the HTML5 spec.[0], so going the strict path is still an option. In the past, this would've required complex content-negotiation for media-type backward-compat but that's no longer an issue unless a non-neglible % of your visitors are using IE8. The only remaining issue is that of draconian error handling, which is an issue browsers definitely would have fixed the UX of had the mainstream stayed on the XHTML track, but sadly that never happened. Still, good modern support for server-side validation of well-formed XML documents means this is also less of an issue than it once was (though tbh, still a significant issue imo). W3 have also put together a more informal guide to modern XHTML considerations within the HTML5 spec. https://dev.w3.org/html5/html-polyglot/html-polyglot.html https://dev.w3.org/html5/html-polyglot/html-polyglot.html [0] https://html.spec.whatwg.org/multipage/xhtml.html https://html.spec.whatwg.org/multipage/xhtml.html