3 ms·

> 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 a

> 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 <p> 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
    SGML itself has link process declarations, an additional type of declaration set that can appear in an SGML prolog next to DTDs and that can be used to remap elements (in SGML you can have multiple DTDs and LPDs, pipeline LPDs, and so on). sgmljs uses this and adds templating to capture attributes at call sites for passing these into templates as regular entities, allowing for parametric macro expansion. Basically, if you have eg <div bla=x> in your main doc, you can make SGML expand it using <!DOCTYPE div SYSTEM [ <!ENTITY bla SYSTEM> ]> <div> <p>Value of bla is &bla</p> </div> honoring escaping/sanitizing etc. LPDs can apply rules in a context-dependent way using an automaton capturing much of core CSS. Now, for arbitrary markup manipulation (XSLT is Turing-complete), don't tell the HN crowd that SGML has/had Scheme-based DSSSL (precursor of XSLT) ;) My opinion, having done large, nontrivial XSLT projects (including extracting the DTD grammar rules you see on the site from spec text) is that the more complex it gets, the more a general-purpose language with unit testing etc becomes a better choice over XSLT. Edit: much luck with your browser project! Don't hesitate to use my code or ask questions (here or on StackOverflow tagged sgml)

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
  SGML itself has link process declarations, an additional type of declaration set that can appear in an SGML prolog next to DTDs and that can be used to remap elements (in SGML you can have multiple DTDs and LPDs, pipeline LPDs, and so on). sgmljs uses this and adds templating to capture attributes at call sites for passing these into templates as regular entities, allowing for parametric macro expansion. Basically, if you have eg <div bla=x> in your main doc, you can make SGML expand it using <!DOCTYPE div SYSTEM [ <!ENTITY bla SYSTEM> ]> <div> <p>Value of bla is &bla</p> </div> honoring escaping/sanitizing etc. LPDs can apply rules in a context-dependent way using an automaton capturing much of core CSS. Now, for arbitrary markup manipulation (XSLT is Turing-complete), don't tell the HN crowd that SGML has/had Scheme-based DSSSL (precursor of XSLT) ;) My opinion, having done large, nontrivial XSLT projects (including extracting the DTD grammar rules you see on the site from spec text) is that the more complex it gets, the more a general-purpose language with unit testing etc becomes a better choice over XSLT. Edit: much luck with your browser project! Don't hesitate to use my code or ask questions (here or on StackOverflow tagged sgml)