46 ms·

As somebody who does a lot of xml, I'm weirded out by the idea that the root tags are optional. I mean, get certain child elements and attributes being optiona

by Pxtl 10y ago

As somebody who does a lot of xml, I'm weirded out by the idea that the root tags are optional. I mean, get certain child elements and attributes being optional, but the parent ones? That's.... hard.

throwanem 10y ago
It reminds me, and not favorably, of all the old laziness that made browsers' DOM parsers such nightmares of special cases upon special cases, and all the extra effort to deal with that which was so much the norm last decade. Perhaps this isn't a regression, but it certainly feels like one.
- Sharlin 10y ago
  That's a big part of what HTML 5 is about, to codify existing practice when it was realized that trying to push strict standards was fighting against windmills. Nobody would ever push their web pages to the browser as application/xhtml because the user getting a validation error instead of a working page due to any slight infraction would have been catastrophically poor UX. Thus, even "XHTML" pages were sent as text/html and parsed by browsers as tag soup - pretty much defeating the purpose of XHTML. Browsers accepting tag soup is just a manifestation of the Robustness Principle [1]: "Be conservative in what you send, be liberal in what you accept" [1] https://en.wikipedia.org/wiki/Robustness_principle https://en.wikipedia.org/wiki/Robustness_principle
  - jpalomaki 10y ago
    Would it allow some performance optimizations on browser if it could assume the content is valid xhtml and simply barf if it is not, instead of trying to make sense of it?
    - gsnedders 10y ago
      Not really. Ultimately, once you get beyond the HTML parser you're just working on a DOM and other data structures derived from it. And unless you made the DOM much stricter, you could always end up with an invalid (i.e., doesn't match the schema) tree through use of scripting, so you still need to handle it.
      - emn13 10y ago
        It probably would make the parser simpler, however, which may well be faster. And xhtml is closer to the dynamic dom in semantics than html, by virtue of not having self-closing issues or nestability issues (i.e., you express nesting a button in a button with the dom and xhtml, but not html).
        gsnedders 10y ago
        It wouldn't really make the parser much simpler. Your state machine goes to having a branch for a character c leading to a fatal error instead of having a branch for a character c leading to something getting added to the DOM. Honestly, the biggest gain I'd expect perf wise is better cache locality for the parser. (Also, I'll point out that HTML allows the parser to abort at any parse error it defines, the first time it hits that parse error. So you can implement a relatively strict HTML parser that rejects content and have it comply with the spec.)
        emn13 10y ago
        HTML also defines extremely flexible error recovery that is de-facto required. There's no way a browser's getting away without it when the competition allows such documents, and there's so much legacy content around. I wouldn't expect huge perf increases, but there are a few minor non-local effects such as self-closing tags that imply more branches than strictly necessary. It's not going to add up to much of anything, that's for sure. A simpler spec might, however, leave more complexity-budget for clever optimizations, but that's pretty speculative. The kind of thing I'm thinking about here is that when the language is fairly restrictive, you can consider using SIMD operations to match content cleverly; e.g. you might find the closing quote of an attribute four-chars at a time. Those kind of tricks require interplay decoding and parsing and are typically way to complicated in all but the simplest of cases. In any case, this is drifting off topic: perf is not a primary reason to aim for simplicity, it's just a possible windfall.
        gsnedders 10y ago
  - bonoboTP 10y ago
    But this style guide wants you to be liberal in what you send.
    - luchs 10y ago
      Not really liberal - leaving out those tags is perfectly fine according to the specification and all compliant browsers will create the same DOM from it.
  - Hurtak 10y ago
    Why didn't they decide to keep the strictness, but only in dev mode? Lets say after you checked some checkbox in browser settings or if you had dev tools opened.
    - gsnedders 10y ago
      "keep the strictness" from what, though? Presto-Opera reported parse errors in the dev tools, for example (parse errors have a clear, unambiguous definition even in the current HTML spec). DTD validation? As far as I'm aware, it would only be keeping it at a spec level—no implementation aside from validators ever implemented it. There's nothing stopping a browser from noting any validation error, though (and note they wouldn't just happen at parse time—they could happen following any DOM modification).
hannob 10y ago
To me it makes total sense. I mean why would you have a root tag? You already know it's an HTML file due to the mime type. It's redundant information with no meaning.
- ht85 10y ago
  Your comment seems based on the article suggesting humans should handwrite HTML like this, which I don't think is the intention here. Somebody else posted about the spec description of open <p> tags and there is no way you'd want to have that in mind when writing markup, just close the tag. This would be like a more powerful form of removing trailing comas, which is "neater", but is extremely painful whenever you're refactoring and moving things around. You say the HTML tag has no meaning, but it has the advantage of being explicit instead of implicit, as well as universal. There are situations where implicit is better, because the explicit way feels like a big waste of time and demotivates developers. There is also a lot of value in conventions, as all the efforts around coding standard and linting tools show. It forces different people to work more similarly, using an established way to do things instead of their own quirks, facilitating collaboration and sometimes educating them about the features and caveats of whatever they're using. I've never been annoyed writing <html>, <head>, which happens a handful of times in the lifetime of a project that I'll spend thousand of hours on. Again, I don't think any of this is relevant here, as those optional tags would be cleaned up at build or rendering time, and reinserted by the browser / parser. This seems like an awful lot of computation to save a few bytes though, but maybe processing power is that cheap nowadays.
  - hannob 10y ago
    Well, I don't need to remember all of them, I can just remember the ones that I find convenient and use them. In the end the validator will tell me whether I messed something up. While you're right that I won't write <html>, <head> very often I can very well imagine that skipping </td> and </tr> is convenient in many situations.
  - deleted 10y ago
    [deleted]
Sharlin 10y ago
It's weird if you're accustomed to XML, but most file formats, even those representing hierarchical data, don't have a root-level "wrapper". Most file formats have a header followed by one or more data sections possibly followed by a footer. Of course, in a hierarchical document format the run-time binary representation will constitute a tree, but there's no intrinsic reason for a serialized format to be isomorphic to the run-time format, as long as possible missing pieces can be inferred on deserialization.
TheRealPomax 10y ago
As someone who used to work a lot with XML, I was annoyed to bits by XML parsers forcing me to always use tags that a parser could trivially infer from the target document model. Especially since XML was (and still is) for data transmission, and absolutely not for data storage, it always struck me as an incredibly wasteful approach to transmission data packing.

by Pxtl 10y ago

As somebody who does a lot of xml, I'm weirded out by the idea that the root tags are optional. I mean, get certain child elements and attributes being optional, but the parent ones? That's.... hard.

throwanem 10y ago

It reminds me, and not favorably, of all the old laziness that made browsers' DOM parsers such nightmares of special cases upon special cases, and all the extra effort to deal with that which was so much the norm last decade. Perhaps this isn't a regression, but it certainly feels like one.

Sharlin 10y ago
That's a big part of what HTML 5 is about, to codify existing practice when it was realized that trying to push strict standards was fighting against windmills. Nobody would ever push their web pages to the browser as application/xhtml because the user getting a validation error instead of a working page due to any slight infraction would have been catastrophically poor UX. Thus, even "XHTML" pages were sent as text/html and parsed by browsers as tag soup - pretty much defeating the purpose of XHTML. Browsers accepting tag soup is just a manifestation of the Robustness Principle [1]: "Be conservative in what you send, be liberal in what you accept" [1] https://en.wikipedia.org/wiki/Robustness_principle https://en.wikipedia.org/wiki/Robustness_principle
- jpalomaki 10y ago
  Would it allow some performance optimizations on browser if it could assume the content is valid xhtml and simply barf if it is not, instead of trying to make sense of it?
  - gsnedders 10y ago
    Not really. Ultimately, once you get beyond the HTML parser you're just working on a DOM and other data structures derived from it. And unless you made the DOM much stricter, you could always end up with an invalid (i.e., doesn't match the schema) tree through use of scripting, so you still need to handle it.
    - emn13 10y ago
      It probably would make the parser simpler, however, which may well be faster. And xhtml is closer to the dynamic dom in semantics than html, by virtue of not having self-closing issues or nestability issues (i.e., you express nesting a button in a button with the dom and xhtml, but not html).
      - gsnedders 10y ago
        It wouldn't really make the parser much simpler. Your state machine goes to having a branch for a character c leading to a fatal error instead of having a branch for a character c leading to something getting added to the DOM. Honestly, the biggest gain I'd expect perf wise is better cache locality for the parser. (Also, I'll point out that HTML allows the parser to abort at any parse error it defines, the first time it hits that parse error. So you can implement a relatively strict HTML parser that rejects content and have it comply with the spec.)
        emn13 10y ago
        HTML also defines extremely flexible error recovery that is de-facto required. There's no way a browser's getting away without it when the competition allows such documents, and there's so much legacy content around. I wouldn't expect huge perf increases, but there are a few minor non-local effects such as self-closing tags that imply more branches than strictly necessary. It's not going to add up to much of anything, that's for sure. A simpler spec might, however, leave more complexity-budget for clever optimizations, but that's pretty speculative. The kind of thing I'm thinking about here is that when the language is fairly restrictive, you can consider using SIMD operations to match content cleverly; e.g. you might find the closing quote of an attribute four-chars at a time. Those kind of tricks require interplay decoding and parsing and are typically way to complicated in all but the simplest of cases. In any case, this is drifting off topic: perf is not a primary reason to aim for simplicity, it's just a possible windfall.
        gsnedders 10y ago
- bonoboTP 10y ago
  But this style guide wants you to be liberal in what you send.
  - luchs 10y ago
    Not really liberal - leaving out those tags is perfectly fine according to the specification and all compliant browsers will create the same DOM from it.
- Hurtak 10y ago
  Why didn't they decide to keep the strictness, but only in dev mode? Lets say after you checked some checkbox in browser settings or if you had dev tools opened.
  - gsnedders 10y ago
    "keep the strictness" from what, though? Presto-Opera reported parse errors in the dev tools, for example (parse errors have a clear, unambiguous definition even in the current HTML spec). DTD validation? As far as I'm aware, it would only be keeping it at a spec level—no implementation aside from validators ever implemented it. There's nothing stopping a browser from noting any validation error, though (and note they wouldn't just happen at parse time—they could happen following any DOM modification).

hannob 10y ago

To me it makes total sense. I mean why would you have a root tag? You already know it's an HTML file due to the mime type. It's redundant information with no meaning.

ht85 10y ago
Your comment seems based on the article suggesting humans should handwrite HTML like this, which I don't think is the intention here. Somebody else posted about the spec description of open <p> tags and there is no way you'd want to have that in mind when writing markup, just close the tag. This would be like a more powerful form of removing trailing comas, which is "neater", but is extremely painful whenever you're refactoring and moving things around. You say the HTML tag has no meaning, but it has the advantage of being explicit instead of implicit, as well as universal. There are situations where implicit is better, because the explicit way feels like a big waste of time and demotivates developers. There is also a lot of value in conventions, as all the efforts around coding standard and linting tools show. It forces different people to work more similarly, using an established way to do things instead of their own quirks, facilitating collaboration and sometimes educating them about the features and caveats of whatever they're using. I've never been annoyed writing <html>, <head>, which happens a handful of times in the lifetime of a project that I'll spend thousand of hours on. Again, I don't think any of this is relevant here, as those optional tags would be cleaned up at build or rendering time, and reinserted by the browser / parser. This seems like an awful lot of computation to save a few bytes though, but maybe processing power is that cheap nowadays.
- hannob 10y ago
  Well, I don't need to remember all of them, I can just remember the ones that I find convenient and use them. In the end the validator will tell me whether I messed something up. While you're right that I won't write <html>, <head> very often I can very well imagine that skipping </td> and </tr> is convenient in many situations.
- deleted 10y ago
  [deleted]

Sharlin 10y ago

It's weird if you're accustomed to XML, but most file formats, even those representing hierarchical data, don't have a root-level "wrapper". Most file formats have a header followed by one or more data sections possibly followed by a footer. Of course, in a hierarchical document format the run-time binary representation will constitute a tree, but there's no intrinsic reason for a serialized format to be isomorphic to the run-time format, as long as possible missing pieces can be inferred on deserialization.

TheRealPomax 10y ago

As someone who used to work a lot with XML, I was annoyed to bits by XML parsers forcing me to always use tags that a parser could trivially infer from the target document model. Especially since XML was (and still is) for data transmission, and absolutely not for data storage, it always struck me as an incredibly wasteful approach to transmission data packing.