6 ms·

Looking back at XHTML I am reminded again and again that the best technical solution often loses out. Instead we have HTML5 which contains nothing that couldn'

by jpgvm 5y ago

Looking back at XHTML I am reminded again and again that the best technical solution often loses out. Instead we have HTML5 which contains nothing that couldn't have been easily expressed in XHTML but have none of it's strictness that would have enabled much simpler and better browser implementations. The arguments against XHTML amounted to "but wahh it should still work even if the syntax is wrong". Thing is none of the major proponents of XHTML were advocating for exterminating the existing doctypes and their associated quirks modes. People could continue to use that but XHTML would be there, ready for the advent of non-shit programming to hit the web. People are starting to come around the ideas of strictness in programming languages again with Typescript and co rapidly gaining in popularity. It's just such a massive shame the entire Web community forced this massive wheel-reinventing cycle on us for no damn reason, completely ignoring the lessons learnt -literally everywhere- else.

abraae 5y ago
It's the cycle of innovation. Like a cat retching up a hair ball. It repeats over and over, until finally something is coughed up. Except in technology it takes years instead of seconds. Just like MongoDB gaining mindshare - because webscale - only for people to realise those relationships and structured types were actually quite good at keeping your data clean.
stickfigure 5y ago
HN folks whine about browser monoculture but it was this decision (and thousands more like it, but this one is pretty big) that meant you cannot have a simple browser implementation. Any 2nd year CS student could write an X(HT)ML parser. Writing an HTML5 parser requires FAANG resources.
- jazzyjackson 5y ago
  Could you elaborate at all on what makes HTML5 so much more difficult to parse?
  - mynameismon 5y ago
    From what I know and have read, disregard for the strictness that comes with XML and XHTML makes HTML5 parsers handle tons of edge cases (https://wiki.whatwg.org/wiki/HTML_vs._XHTML https://wiki.whatwg.org/wiki/HTML_vs._XHTML)
  - josefx 5y ago
    For example HTML has quite a few special cases around self/implicit closing elements and many browsers/websites around did not fully agree on how that should work. So not only do you have to implement and verify these closing rules, you have to gracefully handle every page that gets them wrong either because past browsers got them wrong or because these special cases are so pointless that no one sane actually memorizes them.
  - Macha 5y ago
    Invalid XHTML: Throw an error, yell at the user, who should just be the author since broken XHTML shouldn't have been allowed make it to the end user. "Invalid" HTML5: Please refer to section X.Y for the heuristics to apply in this scenario. "Invalid" HTML4: Uhh, just do whatever? But probably you need to do whatever the other browsers do. Implementing the other behaviours is more work than not implementing them, and may be more difficult if your internal data structures don't match those of the browser for which it was originally introduced as expedient or even emergent behaviour.
    - spiralx 5y ago
      HTML5 is expressible as valid SGML with some exceptions such as ARIA and data-* attributes. And SGML, which is a super-set of XML, has rules for both optional elements - e.g. HEAD - and for elements with optional closing tags - e.g. P. http://sgmljs.net/docs/html5.html http://sgmljs.net/docs/html5.html
      - Macha 5y ago
        Part of the XML motivation was for something simpler than SGML. SGML has no opinions on rendering, since it's just a generic markup language. Nor does it have opinions on "what do with a hr that's a direct descendant of the table despite not being permitted", to pick the first example from the spec (it should be treated as a preceding sibling).
- cxr 5y ago
  > Writing an HTML5 parser requires FAANG resources. No it doesn't. The HTML5 parsing algorithm is well-defined, and parsing it according to the spec is not an order of magnitude more difficult than properly handling XML according to its spec. What makes browsers difficult does not come from the part that involves ingesting the initial response payload and building it into a tree in a spec-compliant way—what makes things difficult is all the other stuff involved with creating and maintaining a browser.
deleted 5y ago
[deleted]
KronisLV 5y ago
You know, as someone stuck using XHTML within the Java ecosystem for web apps, i'd say that it's reasonably easy and nice to work with. However, i'd also like to suggest that custom tags, at least when implemented in the ways that are popular in those particular technologies (JSF/PrimeFaces) are bad both from a usability and maintainability perspective - it took many years for React to come around and make components easy to create and utilize. XHTML with the semantics of React would be way better. That said, i'm also stuck in the middle of migrating older versions of frameworks (Spring) to newer ones (Spring Boot) and it's proving to be extremely cumbersome and feels like it'll be impossible to get right without spending multiple months on the migration. Most of the older technologies are considered "dead" nowadays for a reason, though at the same time i agree that they can hold a certain wisdom.
- Cthulhu_ 5y ago
  > XHTML with the semantics of React would be way better. Isn't Web Components an attempt at something like that?
  - pjmlp 5y ago
    Yes, and if XTHML handn't been thrown away, we would have them much sooner based on "XML Fragments".
- vintermann 5y ago
  "Actually pretty decent ideas, but completely botched on implementation elsewhere" is a story that we've heard many times in the Java world... I remember the OSGI folks elation as Eclipse turned to OSGI from their custom plug in system, turn to dismay as they saw how it was actually used.
  - DonHopkins 5y ago
    Whereas TCL was a beautiful and perfect implementation of a very silly idea. Remember in 1994 just before Java, when Sun hired TCL's developer John Ousterhout, then unilaterally announced that TCL would be the official scripting language of web browsers? https://en.wikipedia.org/wiki/John_Ousterhout https://en.wikipedia.org/wiki/John_Ousterhout http://www.softpanorama.org/People/Ousterhout/index.shtml http://www.softpanorama.org/People/Ousterhout/index.shtml And that triggered RMS into posting his controversial "Why you should not use TCL" announcement, which kicked off the Great TCL War of 1994: https://news.ycombinator.com/item?id=12025218 https://news.ycombinator.com/item?id=12025218 https://vanderburg.org/old_pages/Tcl/war/ https://vanderburg.org/old_pages/Tcl/war/ "Java is a DSL for taking large XML files and converting them to stack traces" -Andrew Back https://twitter.com/9600/status/90729345307521024?lang=en https://twitter.com/9600/status/90729345307521024?lang=en
vbezhenar 5y ago
XHTML is supported, you can use it, major browsers did not deprecate it. And forcing it through developers throat - I'm not sure if it's a wise decision. In the end developers would just stay in HTML 4.
- Thiez 5y ago
  I'm not so sure they would stay in HTML4. Currently HTTPS is being "forced" by having features that are only available over HTTPS (such as, but not limited to, HTTP/2 and HTTP/3) and this has been fairly helpful. XHTML adoption could have been encouraged using similar tactics, and most developers would have gone along.
zozbot234 5y ago
XHTML5 is a thing, it is still there. You can use it in all modern browsers (no IE) and it adds support for XML namespaces to the HTML5 featureset.
BurnGpuBurn 5y ago
I remember working a lot with XML a decade ago. XML was large and clumsy and had problems like undefinable ordering of elements for instance. And I haven't actually encountered a single parser library that did not have some strange issue which made it behave outside the spec. Not to mention editors that happily show "<tag\>" while in reality the file reads "<tag></tag>". Good luck debugging the parser with that one. My bad experience with the XML standard is probably the reason why I never bothered with XHTML. Sure, cool idea, but XML, so meh.
- bryanrasmussen 5y ago
 >Not to mention editors that happily show "<tag\>" while in reality the file reads "<tag></tag>" I believe you mean tag/ as every parse I know of would choke on tag\. if it is tag/ the XML spec says there is no difference between these two scenarios, thus most tools and libraries will serialize as tag/ (I say most because maybe somebody silly somewhere did differently)
 - Per_Bothner 5y ago
 The difference between <tag></tag> and <tag/> is important if you're trying to write "polyglot" xml/html that can be parsed by either an xml parser or an html parser. For example is not valid HTML, but a plain is not valid XML. However works as either. On the other hand, an empty span has to be written .
- NackerHughes 5y ago
 > undefinable ordering of elements Could you elaborate a bit more on that? By my understanding, order of elements in XML is significant, and child elements are kept in an ordered list.

by jpgvm 5y ago

abraae 5y ago

It's the cycle of innovation. Like a cat retching up a hair ball. It repeats over and over, until finally something is coughed up. Except in technology it takes years instead of seconds. Just like MongoDB gaining mindshare - because webscale - only for people to realise those relationships and structured types were actually quite good at keeping your data clean.

stickfigure 5y ago

HN folks whine about browser monoculture but it was this decision (and thousands more like it, but this one is pretty big) that meant you cannot have a simple browser implementation. Any 2nd year CS student could write an X(HT)ML parser. Writing an HTML5 parser requires FAANG resources.

jazzyjackson 5y ago
Could you elaborate at all on what makes HTML5 so much more difficult to parse?
- mynameismon 5y ago
  From what I know and have read, disregard for the strictness that comes with XML and XHTML makes HTML5 parsers handle tons of edge cases (https://wiki.whatwg.org/wiki/HTML_vs._XHTML https://wiki.whatwg.org/wiki/HTML_vs._XHTML)
- josefx 5y ago
  For example HTML has quite a few special cases around self/implicit closing elements and many browsers/websites around did not fully agree on how that should work. So not only do you have to implement and verify these closing rules, you have to gracefully handle every page that gets them wrong either because past browsers got them wrong or because these special cases are so pointless that no one sane actually memorizes them.
- Macha 5y ago
  Invalid XHTML: Throw an error, yell at the user, who should just be the author since broken XHTML shouldn't have been allowed make it to the end user. "Invalid" HTML5: Please refer to section X.Y for the heuristics to apply in this scenario. "Invalid" HTML4: Uhh, just do whatever? But probably you need to do whatever the other browsers do. Implementing the other behaviours is more work than not implementing them, and may be more difficult if your internal data structures don't match those of the browser for which it was originally introduced as expedient or even emergent behaviour.
  - spiralx 5y ago
    HTML5 is expressible as valid SGML with some exceptions such as ARIA and data-* attributes. And SGML, which is a super-set of XML, has rules for both optional elements - e.g. HEAD - and for elements with optional closing tags - e.g. P. http://sgmljs.net/docs/html5.html http://sgmljs.net/docs/html5.html
    - Macha 5y ago
      Part of the XML motivation was for something simpler than SGML. SGML has no opinions on rendering, since it's just a generic markup language. Nor does it have opinions on "what do with a hr that's a direct descendant of the table despite not being permitted", to pick the first example from the spec (it should be treated as a preceding sibling).
cxr 5y ago
> Writing an HTML5 parser requires FAANG resources. No it doesn't. The HTML5 parsing algorithm is well-defined, and parsing it according to the spec is not an order of magnitude more difficult than properly handling XML according to its spec. What makes browsers difficult does not come from the part that involves ingesting the initial response payload and building it into a tree in a spec-compliant way—what makes things difficult is all the other stuff involved with creating and maintaining a browser.

deleted 5y ago

[deleted]

KronisLV 5y ago

You know, as someone stuck using XHTML within the Java ecosystem for web apps, i'd say that it's reasonably easy and nice to work with. However, i'd also like to suggest that custom tags, at least when implemented in the ways that are popular in those particular technologies (JSF/PrimeFaces) are bad both from a usability and maintainability perspective - it took many years for React to come around and make components easy to create and utilize. XHTML with the semantics of React would be way better. That said, i'm also stuck in the middle of migrating older versions of frameworks (Spring) to newer ones (Spring Boot) and it's proving to be extremely cumbersome and feels like it'll be impossible to get right without spending multiple months on the migration. Most of the older technologies are considered "dead" nowadays for a reason, though at the same time i agree that they can hold a certain wisdom.

Cthulhu_ 5y ago
> XHTML with the semantics of React would be way better. Isn't Web Components an attempt at something like that?
- pjmlp 5y ago
  Yes, and if XTHML handn't been thrown away, we would have them much sooner based on "XML Fragments".
vintermann 5y ago
"Actually pretty decent ideas, but completely botched on implementation elsewhere" is a story that we've heard many times in the Java world... I remember the OSGI folks elation as Eclipse turned to OSGI from their custom plug in system, turn to dismay as they saw how it was actually used.
- DonHopkins 5y ago
  Whereas TCL was a beautiful and perfect implementation of a very silly idea. Remember in 1994 just before Java, when Sun hired TCL's developer John Ousterhout, then unilaterally announced that TCL would be the official scripting language of web browsers? https://en.wikipedia.org/wiki/John_Ousterhout https://en.wikipedia.org/wiki/John_Ousterhout http://www.softpanorama.org/People/Ousterhout/index.shtml http://www.softpanorama.org/People/Ousterhout/index.shtml And that triggered RMS into posting his controversial "Why you should not use TCL" announcement, which kicked off the Great TCL War of 1994: https://news.ycombinator.com/item?id=12025218 https://news.ycombinator.com/item?id=12025218 https://vanderburg.org/old_pages/Tcl/war/ https://vanderburg.org/old_pages/Tcl/war/ "Java is a DSL for taking large XML files and converting them to stack traces" -Andrew Back https://twitter.com/9600/status/90729345307521024?lang=en https://twitter.com/9600/status/90729345307521024?lang=en

vbezhenar 5y ago

XHTML is supported, you can use it, major browsers did not deprecate it. And forcing it through developers throat - I'm not sure if it's a wise decision. In the end developers would just stay in HTML 4.

Thiez 5y ago
I'm not so sure they would stay in HTML4. Currently HTTPS is being "forced" by having features that are only available over HTTPS (such as, but not limited to, HTTP/2 and HTTP/3) and this has been fairly helpful. XHTML adoption could have been encouraged using similar tactics, and most developers would have gone along.

zozbot234 5y ago

XHTML5 is a thing, it is still there. You can use it in all modern browsers (no IE) and it adds support for XML namespaces to the HTML5 featureset.

BurnGpuBurn 5y ago

I remember working a lot with XML a decade ago. XML was large and clumsy and had problems like undefinable ordering of elements for instance. And I haven't actually encountered a single parser library that did not have some strange issue which made it behave outside the spec. Not to mention editors that happily show "<tag\>" while in reality the file reads "<tag></tag>". Good luck debugging the parser with that one. My bad experience with the XML standard is probably the reason why I never bothered with XHTML. Sure, cool idea, but XML, so meh.

bryanrasmussen 5y ago
>Not to mention editors that happily show "<tag\>" while in reality the file reads "<tag></tag>" I believe you mean tag/ as every parse I know of would choke on tag\. if it is tag/ the XML spec says there is no difference between these two scenarios, thus most tools and libraries will serialize as tag/ (I say most because maybe somebody silly somewhere did differently)
- Per_Bothner 5y ago
 The difference between <tag></tag> and <tag/> is important if you're trying to write "polyglot" xml/html that can be parsed by either an xml parser or an html parser. For example is not valid HTML, but a plain is not valid XML. However works as either. On the other hand, an empty span has to be written .
NackerHughes 5y ago
> undefinable ordering of elements Could you elaborate a bit more on that? By my understanding, order of elements in XML is significant, and child elements are kept in an ordered list.