5 ms·

The HTML that browsers accept is loosely defined The HTML specification has a grammar and defines whats allowed - a subset/derivation of XHTML/SGML and their i

The HTML that browsers accept is loosely defined The HTML specification has a grammar and defines whats allowed - a subset/derivation of XHTML/SGML and their ilk There are a bunch of test template files in the test/ folder that demonstrate what kinds of errors are caught.

lucideer 9y ago
> The HTML that browsers accept is loosely defined This has changed since the advent of the HTML5 specification, the primary purpose of which was to retroactively describe existing browser HTML parsing behaviours and to document and specify them comprehensively in all of their complexity. The wisdom of this abominably complex approach may be questionable, but it's certainly no longer "loosely" defined. I'd be curious as to whether this implements HTML5...
- taeric 9y ago
  I remember the promise of xhmtl and the sad reality that, by and large, nobody actually cared about well formed documents. The specification allowing for "implicit" tags is something that just doesn't make any bloody sense to me. It feels like someone looked at all warnings in a compiler and said, I'll just explicitly define exactly how I want each warning to behave, so that it is no longer dangerous behavior.
  - tannhaeuser 9y ago
    HTML always had tag omission and "self-closing" elements - these are features from its SGML roots. A formal SGML grammar for modern W3C HTML 5.1 can be found at [1] (my project). [1]: http://sgmljs.net/blog/blog1701.html http://sgmljs.net/blog/blog1701.html
    - lucideer 9y ago
      I don't think the gp was saying this is a new thing, just an old thing that never made sense to her/him. That looks like a very nice resource though, thank you.
      - taeric 9y ago
        Indeed. And to be fair, I'm actually somewhat ok with self closing tags. Though, I can't easily see why I'd want tags that can't self close.
        tannhaeuser 9y ago
        To be clear, HTML's "self-closing elements" are img, meta, and others which never have content nor end-element tags. These are based on SGML empty elements, and HTML merely tolerates the XML-style form <img ... /> but does not allow <img ...></img> though parser recovery might be able to deal with it, and WebSGML can formally reject or accept it. Apart from empty elements, HTML's tag inference can also be formalized using SGML. Tag inference is what makes this <title>Title</title> <p>Body Text a valid HTML document and be treated as though <html <head> <title>Title</title> </head> <body> <p>Body Text</p> </body> </html> had been written.
        taeric 9y ago
        Right, the "self-closing elements" don't actually bother me. I do slightly prefer the <foo /> form, but in general I don't care. What used to baffle me was I couldn't do a "<div />" as that wasn't allowed. And I couldn't think of a good reason to care on that. (It seemed you had to go out of your way to disallow that, for no apparent reason.) The tag inference, I just don't get. I can /almost/ understand the example you used, but the examples include crap like: <table> <thead> <tr> <tr> Where the second "<tr>" is actually part of the inferred "<tbody>". Just, why? Edit: And to be perfectly clear, I do expect most of this to be handled for me by whatever framework I'm using nowdays. And, I don't actually generate documents directly that much. For docs, I typically go with LaTeX or friends. (Honestly, probably org-mode moreso, but even that is light nowdays.)
        tannhaeuser 9y ago
        Well, in my paper, like you, I'm criticizing (tag omission in) HTML5's table content models, and discourage aggressive use of it ([1]), so probably I'm not the one to defend it ;) Even the HTML specification text itself got its tables wrong ([2]; also explained in [1]). [1]: <http://sgmljs.net/docs/html5.html#start--and-end-element-tag-omission-in-table-content> http://sgmljs.net/docs/html5.html#start--and-end-element-tag... [2]: <https://github.com/whatwg/html/commit/6e305c457e42276bf275b8432302a32c929b0eb8> https://github.com/whatwg/html/commit/6e305c457e42276bf275b8...
  - lucideer 9y ago
    > It feels like someone looked at all warnings in a compiler and said, I'll just explicitly define exactly how I want each warning to behave, so that it is no longer dangerous behavior. I get the impression you're saying this in a (rightfully) despairing tone as if it only seems that way, and noone in their right mind would actually do that in reality. But this is actually the stated mission of the HTML editor. This was literally his intent with HTML5. That is what it is.
    - taeric 9y ago
      Sorry, I knew that was the intent of HTML5. What I don't get is how it was a sane goal. I was likening it to as if someone decided to just redefine all of the various ways that people used things incorrectly to be correct. To my knowledge, nobody is trying to do that. Look at the tortuous ways they deal with the various missing tags of a table. My favorite is how they work to make it permissible to have a THEAD with an implicit TBODY that follows it. Just, why!? I think this is important for browser vendors, to an extent. I also think we can try to do better.
      - bzbarsky 9y ago
        > My favorite is how they work to make it permissible to have a THEAD with an implicit TBODY that follows it. Just, why!? Are you asking why the HTML4 spec initially allowed this? There were likely several reasons (I wasn't involved in the working group at the time). Some of the reasons: 1) Tables without <tbody> or <thead> at all, with <tr> in the <table> directly were already all over the place before HTML4 appeared. They needed to keep those allowed, both asa practical matter and to make authoring less verbose in cases when there is no thead/tfoot. 2) Their syntax definition method (SGML) allowed for this by making <tbody> start and end tags optional, which they therefore did. The outcome is that <tbody> has optional start/end tags in HTML 4, and <table><thead></thead><tr></tr></table> ends up with an implicit <tbody>. Now we come to HTML5. We're not using SGML anymore, so we _could_ disallow missing tbody when there's a thead/tfoot, but still allow it if there are no headers/footers. But in the intervening 10 years, there's a ton of content that was created that relies on the HTML4 behavior, and browsers all implement the HTML4 behavior. What is the argument for changing that behavior? > I think this is important for browser vendors, to an extent. What was important to browser vendors, with HTML5, was having a standard that actually specified the behaviors needed for de-facto compat with existing content, so they could stop (buggily) reverse-engineering each other to figure out how to handle the corner cases. This was the stated intent of the spec. Is this the goal you consider "not sane"? Note that some of the authoring behaviors involved are still considered incorrect in HTML5 (though leaving out <tbody> is not one of them): misnesting your tags will cause your HTML to not be valid HTML5, and a validator will flag that. It's just that HTML5 specifies what browsers should do even in the face of incorrect behavior like misnesting tags, because it turned out that people were doing that even though it was invalid and depending on the resulting behavior of browsers. > I also think we can try to do better. What do you think should be the goal of a spec for "HTML"?
- rep_movsd 9y ago
  Syntactially, I believe I have implemenetd HTML5 It parses out a pretty large example HTML file without any trouble
- rep_movsd 9y ago
  Browsers seem to be happy with <br/> for example, which is actually deprecated and a HTML 4 thing
  - gsnedders 9y ago
    <br/> isn't an HTML 4 thing (it's an SGML thing, and hence goes back to the IIIR HTML draft and the original HTML (2!) standard): it has a very different meaning that most people think; it's the NET syntax (of the SHORTTAG feature of SGML), and is a br tag followed by a literal ">". The feature even gets mentioned in the HTML 4 spec: https://www.w3.org/TR/html4/appendix/notes.html#h-B.3.7 https://www.w3.org/TR/html4/appendix/notes.html#h-B.3.7 Of course, browsers never actually implemented this, which led to the ability to write "polyglot" markup which was both (de-facto) HTML and (de-jure) XHTML simultaneously.
    - tannhaeuser 9y ago
      nit: it's a WebSGML thing eg. an XML feature factored in to the revised SGML spec for accomodating XML-style empty elements, which was necessary so that XML could be DTD-less, yet still have a compact idiom for empty elements. Classic SGML only had a shortform syntax such as <elmt/content of elmt/ and WebSGML introduced NETC and EMPTYRM to extend this into a (rather idiosyncratic) way of achieving support for XML-style empty elements within the SGML framework.
bzbarsky 9y ago
The current HTML specification defines parsing precisely. It doesn't use a grammar; it defines a state machine directly instead.

lucideer 9y ago

> The HTML that browsers accept is loosely defined This has changed since the advent of the HTML5 specification, the primary purpose of which was to retroactively describe existing browser HTML parsing behaviours and to document and specify them comprehensively in all of their complexity. The wisdom of this abominably complex approach may be questionable, but it's certainly no longer "loosely" defined. I'd be curious as to whether this implements HTML5...

taeric 9y ago
I remember the promise of xhmtl and the sad reality that, by and large, nobody actually cared about well formed documents. The specification allowing for "implicit" tags is something that just doesn't make any bloody sense to me. It feels like someone looked at all warnings in a compiler and said, I'll just explicitly define exactly how I want each warning to behave, so that it is no longer dangerous behavior.
- tannhaeuser 9y ago
  HTML always had tag omission and "self-closing" elements - these are features from its SGML roots. A formal SGML grammar for modern W3C HTML 5.1 can be found at [1] (my project). [1]: http://sgmljs.net/blog/blog1701.html http://sgmljs.net/blog/blog1701.html
  - lucideer 9y ago
    I don't think the gp was saying this is a new thing, just an old thing that never made sense to her/him. That looks like a very nice resource though, thank you.
    - taeric 9y ago
      Indeed. And to be fair, I'm actually somewhat ok with self closing tags. Though, I can't easily see why I'd want tags that can't self close.
      - tannhaeuser 9y ago
        To be clear, HTML's "self-closing elements" are img, meta, and others which never have content nor end-element tags. These are based on SGML empty elements, and HTML merely tolerates the XML-style form <img ... /> but does not allow <img ...></img> though parser recovery might be able to deal with it, and WebSGML can formally reject or accept it. Apart from empty elements, HTML's tag inference can also be formalized using SGML. Tag inference is what makes this <title>Title</title> <p>Body Text a valid HTML document and be treated as though <html <head> <title>Title</title> </head> <body> <p>Body Text</p> </body> </html> had been written.
        taeric 9y ago
        Right, the "self-closing elements" don't actually bother me. I do slightly prefer the <foo /> form, but in general I don't care. What used to baffle me was I couldn't do a "<div />" as that wasn't allowed. And I couldn't think of a good reason to care on that. (It seemed you had to go out of your way to disallow that, for no apparent reason.) The tag inference, I just don't get. I can /almost/ understand the example you used, but the examples include crap like: <table> <thead> <tr> <tr> Where the second "<tr>" is actually part of the inferred "<tbody>". Just, why? Edit: And to be perfectly clear, I do expect most of this to be handled for me by whatever framework I'm using nowdays. And, I don't actually generate documents directly that much. For docs, I typically go with LaTeX or friends. (Honestly, probably org-mode moreso, but even that is light nowdays.)
        tannhaeuser 9y ago
        Well, in my paper, like you, I'm criticizing (tag omission in) HTML5's table content models, and discourage aggressive use of it ([1]), so probably I'm not the one to defend it ;) Even the HTML specification text itself got its tables wrong ([2]; also explained in [1]). [1]: <http://sgmljs.net/docs/html5.html#start--and-end-element-tag-omission-in-table-content> http://sgmljs.net/docs/html5.html#start--and-end-element-tag... [2]: <https://github.com/whatwg/html/commit/6e305c457e42276bf275b8432302a32c929b0eb8> https://github.com/whatwg/html/commit/6e305c457e42276bf275b8...
- lucideer 9y ago
  > It feels like someone looked at all warnings in a compiler and said, I'll just explicitly define exactly how I want each warning to behave, so that it is no longer dangerous behavior. I get the impression you're saying this in a (rightfully) despairing tone as if it only seems that way, and noone in their right mind would actually do that in reality. But this is actually the stated mission of the HTML editor. This was literally his intent with HTML5. That is what it is.
  - taeric 9y ago
    Sorry, I knew that was the intent of HTML5. What I don't get is how it was a sane goal. I was likening it to as if someone decided to just redefine all of the various ways that people used things incorrectly to be correct. To my knowledge, nobody is trying to do that. Look at the tortuous ways they deal with the various missing tags of a table. My favorite is how they work to make it permissible to have a THEAD with an implicit TBODY that follows it. Just, why!? I think this is important for browser vendors, to an extent. I also think we can try to do better.
    - bzbarsky 9y ago
      > My favorite is how they work to make it permissible to have a THEAD with an implicit TBODY that follows it. Just, why!? Are you asking why the HTML4 spec initially allowed this? There were likely several reasons (I wasn't involved in the working group at the time). Some of the reasons: 1) Tables without <tbody> or <thead> at all, with <tr> in the <table> directly were already all over the place before HTML4 appeared. They needed to keep those allowed, both asa practical matter and to make authoring less verbose in cases when there is no thead/tfoot. 2) Their syntax definition method (SGML) allowed for this by making <tbody> start and end tags optional, which they therefore did. The outcome is that <tbody> has optional start/end tags in HTML 4, and <table><thead></thead><tr></tr></table> ends up with an implicit <tbody>. Now we come to HTML5. We're not using SGML anymore, so we _could_ disallow missing tbody when there's a thead/tfoot, but still allow it if there are no headers/footers. But in the intervening 10 years, there's a ton of content that was created that relies on the HTML4 behavior, and browsers all implement the HTML4 behavior. What is the argument for changing that behavior? > I think this is important for browser vendors, to an extent. What was important to browser vendors, with HTML5, was having a standard that actually specified the behaviors needed for de-facto compat with existing content, so they could stop (buggily) reverse-engineering each other to figure out how to handle the corner cases. This was the stated intent of the spec. Is this the goal you consider "not sane"? Note that some of the authoring behaviors involved are still considered incorrect in HTML5 (though leaving out <tbody> is not one of them): misnesting your tags will cause your HTML to not be valid HTML5, and a validator will flag that. It's just that HTML5 specifies what browsers should do even in the face of incorrect behavior like misnesting tags, because it turned out that people were doing that even though it was invalid and depending on the resulting behavior of browsers. > I also think we can try to do better. What do you think should be the goal of a spec for "HTML"?
rep_movsd 9y ago
Syntactially, I believe I have implemenetd HTML5 It parses out a pretty large example HTML file without any trouble
rep_movsd 9y ago
Browsers seem to be happy with <br/> for example, which is actually deprecated and a HTML 4 thing
- gsnedders 9y ago
  <br/> isn't an HTML 4 thing (it's an SGML thing, and hence goes back to the IIIR HTML draft and the original HTML (2!) standard): it has a very different meaning that most people think; it's the NET syntax (of the SHORTTAG feature of SGML), and is a br tag followed by a literal ">". The feature even gets mentioned in the HTML 4 spec: https://www.w3.org/TR/html4/appendix/notes.html#h-B.3.7 https://www.w3.org/TR/html4/appendix/notes.html#h-B.3.7 Of course, browsers never actually implemented this, which led to the ability to write "polyglot" markup which was both (de-facto) HTML and (de-jure) XHTML simultaneously.
  - tannhaeuser 9y ago
    nit: it's a WebSGML thing eg. an XML feature factored in to the revised SGML spec for accomodating XML-style empty elements, which was necessary so that XML could be DTD-less, yet still have a compact idiom for empty elements. Classic SGML only had a shortform syntax such as <elmt/content of elmt/ and WebSGML introduced NETC and EMPTYRM to extend this into a (rather idiosyncratic) way of achieving support for XML-style empty elements within the SGML framework.

bzbarsky 9y ago

The current HTML specification defines parsing precisely. It doesn't use a grammar; it defines a state machine directly instead.