6 ms·

One of the many, many reasons I think the fact that the big vendors did not accept XHTML 2.0 and instead wanted HTML 5 was probably influenced by the that it ma

One of the many, many reasons I think the fact that the big vendors did not accept XHTML 2.0 and instead wanted HTML 5 was probably influenced by the that it makes it almost impossible for smaller vendors to developer their own new independent engine. XHTML 2.0 and even 1.1 was a very good opportunity to throw all that away.

kitsunesoba 4y ago
It's an unpopular opinion perhaps, but I think infinite backwards compatibility for web HTML/CSS/JS will need to be broken eventually… at some point the cruft becomes too much to wade through and number of optimizations that are unrealizable as a result too great to ignore. If nothing else there will probably need to be a mode that pages can opt into that breaks anything older than a certain cutoff point in exchange for a performance boost.
- dento 4y ago
  This is already occurred, in some limited from. See quicks mode [1], for instance. Also there is WebAssembly, which should be the replacement for JS. At some point a good-enough UI toolkit for it will be written, and then that could replace HTML/CSS. https://developer.mozilla.org/en-US/docs/Web/HTML/Quirks_Mode_and_Standards_Mode https://developer.mozilla.org/en-US/docs/Web/HTML/Quirks_Mod...
  - Dalewyn 4y ago
    For the younger greenhorns among us: Once upon a time, we used to declare what version of HTML a page was written in with the doctype tag at the very top of the file. Certain versions of HTML thus declared, incorrectly formed doctypes, or more often the absence of the doctype declaration altogether, would tell most rendering engines to enter Quirks Mode and render the page with backwards compatibility as the highest priority.
    - Timwi 4y ago
      > we used to declare what version of HTML a page was written in with the doctype tag at the very top of the file. Um, we still do that. It's just that the doctype for HTML 5 is very short and doesn't mention the version number explicitly. (It's `<!DOCTYPE html>`.)
      - deleted 4y ago
        [deleted]
- CJefferson 4y ago
  I haven’t seen an browser devs suggest there are large performance boosts that could be unlocked by throwing away backwards compatibility. Can you point me to any?
  - kitsunesoba 4y ago
    I can’t point to any examples, but it’s hard to imagine that a page being able to tell the browser for example, “hey, the only layout methods used in this page are flexbox and grid” wouldn’t enable code paths with far less guesswork, caveats, etc — the ruleset in that situation is so much more simple.
    - CJefferson 4y ago
      Browsers already do quite a bit of this -- for example one easy way to hurt performance is to have events that trigger on scrolling ( https://developer.chrome.com/docs/devtools/rendering/performance/ https://developer.chrome.com/docs/devtools/rendering/perform... ). However, the current way to fix this is "don't do that". I'm not sure it would be faster for a page to announce it won't do things in advance, than the page just not do them, and then the existing fast paths get used.
      - nicoburns 4y ago
        It might be nice to have a mode where you opt into having the slow-path code ignored (/it's behaviour modified) in case you use it accidentally.
        deleted 4y ago
        [deleted]
tannhaeuser 4y ago
XHTML 1.1 had a chance, and there were many (and there are still quite some) sites containing "approved W3C XHTML" badges and served as xhtml. XHTML is just HTML restricted to the XML syntax - that is, using just the XML subset of SGML features as opposed to regular HTML using full SGML with tag inference/omission and attribute shortforms. W3C dropped the ball with XHTML 2.0 though, which, rather than just simplifying syntax, attempted to innovate using wildly unproven features such as XForms. HTML 5 eliminated vendors big (MS) and small (Opera). I guess unless we want to assume Opera were digging their own grave by actively engaging in HTML5 and WHATWG, we have to conclude HTML parsing wasn't the hard part next to the complexity of CSS layout (with the boom of responsive layout in the smartphone era) and competitive JS performance vs Chrome's v8 engine.
- gsnedders 4y ago
  > I guess unless we want to assume Opera were digging their own grave by actively engaging in HTML5 and WHATWG, we have to conclude HTML parsing wasn't the hard part As someone who was around the WHATWG from relatively on, and worked at Opera over the period when it moved to Chromium, I'd strongly suggest that HTML5 was a _massive_ win for Opera: instead of spending countless person hours reverse-engineering other browsers to be compatible with existing web content, things like HTML parsing become "implement what the spec says" (which also implicitly made it match other browsers). Many of the new features in the HTML5 spec of that period were things that either were already basically supported (in SVG especially) or were relatively minor additions; I don't think they played a significant role either. There's a good reason why Opera was heavily invested in the WHATWG, and it's the fact that by having a spec implemented cross-browser defining how to parse HTML and how cross-page navigation works you eliminate one of the biggest competitive advantages more major browsers have: web compatibility, both through legacy content targetting the browser specifically and also web developers being more likely to test in those browsers. (And to be clear—this would've been true for any form of error handling, including XML-style draconian error handling; but the long-tail of existing content needed to be supported, so even if major sites had migrated to XML you still needed to define how to handle the legacy content.) The downfall of Presto is arguably mostly one of mismanagement and wrong priorities decisions being made; I don't think Presto was unsaveable, and I don't think the Presto team was so significantly under-resourced it couldn't compete.

kitsunesoba 4y ago

It's an unpopular opinion perhaps, but I think infinite backwards compatibility for web HTML/CSS/JS will need to be broken eventually… at some point the cruft becomes too much to wade through and number of optimizations that are unrealizable as a result too great to ignore. If nothing else there will probably need to be a mode that pages can opt into that breaks anything older than a certain cutoff point in exchange for a performance boost.

dento 4y ago
This is already occurred, in some limited from. See quicks mode [1], for instance. Also there is WebAssembly, which should be the replacement for JS. At some point a good-enough UI toolkit for it will be written, and then that could replace HTML/CSS. https://developer.mozilla.org/en-US/docs/Web/HTML/Quirks_Mode_and_Standards_Mode https://developer.mozilla.org/en-US/docs/Web/HTML/Quirks_Mod...
- Dalewyn 4y ago
  For the younger greenhorns among us: Once upon a time, we used to declare what version of HTML a page was written in with the doctype tag at the very top of the file. Certain versions of HTML thus declared, incorrectly formed doctypes, or more often the absence of the doctype declaration altogether, would tell most rendering engines to enter Quirks Mode and render the page with backwards compatibility as the highest priority.
  - Timwi 4y ago
    > we used to declare what version of HTML a page was written in with the doctype tag at the very top of the file. Um, we still do that. It's just that the doctype for HTML 5 is very short and doesn't mention the version number explicitly. (It's `<!DOCTYPE html>`.)
    - deleted 4y ago
      [deleted]
CJefferson 4y ago
I haven’t seen an browser devs suggest there are large performance boosts that could be unlocked by throwing away backwards compatibility. Can you point me to any?
- kitsunesoba 4y ago
  I can’t point to any examples, but it’s hard to imagine that a page being able to tell the browser for example, “hey, the only layout methods used in this page are flexbox and grid” wouldn’t enable code paths with far less guesswork, caveats, etc — the ruleset in that situation is so much more simple.
  - CJefferson 4y ago
    Browsers already do quite a bit of this -- for example one easy way to hurt performance is to have events that trigger on scrolling ( https://developer.chrome.com/docs/devtools/rendering/performance/ https://developer.chrome.com/docs/devtools/rendering/perform... ). However, the current way to fix this is "don't do that". I'm not sure it would be faster for a page to announce it won't do things in advance, than the page just not do them, and then the existing fast paths get used.
    - nicoburns 4y ago
      It might be nice to have a mode where you opt into having the slow-path code ignored (/it's behaviour modified) in case you use it accidentally.
      - deleted 4y ago
        [deleted]

tannhaeuser 4y ago

XHTML 1.1 had a chance, and there were many (and there are still quite some) sites containing "approved W3C XHTML" badges and served as xhtml. XHTML is just HTML restricted to the XML syntax - that is, using just the XML subset of SGML features as opposed to regular HTML using full SGML with tag inference/omission and attribute shortforms. W3C dropped the ball with XHTML 2.0 though, which, rather than just simplifying syntax, attempted to innovate using wildly unproven features such as XForms. HTML 5 eliminated vendors big (MS) and small (Opera). I guess unless we want to assume Opera were digging their own grave by actively engaging in HTML5 and WHATWG, we have to conclude HTML parsing wasn't the hard part next to the complexity of CSS layout (with the boom of responsive layout in the smartphone era) and competitive JS performance vs Chrome's v8 engine.

gsnedders 4y ago
> I guess unless we want to assume Opera were digging their own grave by actively engaging in HTML5 and WHATWG, we have to conclude HTML parsing wasn't the hard part As someone who was around the WHATWG from relatively on, and worked at Opera over the period when it moved to Chromium, I'd strongly suggest that HTML5 was a _massive_ win for Opera: instead of spending countless person hours reverse-engineering other browsers to be compatible with existing web content, things like HTML parsing become "implement what the spec says" (which also implicitly made it match other browsers). Many of the new features in the HTML5 spec of that period were things that either were already basically supported (in SVG especially) or were relatively minor additions; I don't think they played a significant role either. There's a good reason why Opera was heavily invested in the WHATWG, and it's the fact that by having a spec implemented cross-browser defining how to parse HTML and how cross-page navigation works you eliminate one of the biggest competitive advantages more major browsers have: web compatibility, both through legacy content targetting the browser specifically and also web developers being more likely to test in those browsers. (And to be clear—this would've been true for any form of error handling, including XML-style draconian error handling; but the long-tail of existing content needed to be supported, so even if major sites had migrated to XML you still needed to define how to handle the legacy content.) The downfall of Presto is arguably mostly one of mismanagement and wrong priorities decisions being made; I don't think Presto was unsaveable, and I don't think the Presto team was so significantly under-resourced it couldn't compete.