Comment by jpgvm | Hacker News Reader

Comment by jpgvm | Hacker News Reader

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.

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.

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.

Could you elaborate at all on what makes HTML5 so much more difficult to parse?

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)

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.

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.

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

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).

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

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.

> XHTML with the semantics of React would be way better.

Isn't Web Components an attempt at something like that?

Yes, and if XTHML handn't been thrown away, we would have them much sooner based on "XML Fragments".

"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.

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

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://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

Well, all major Java CMS are now based on OSGI as extensibility model.

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.

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

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 <br></br> is not valid HTML, but a plain <br> is not valid XML. However <br/> works as either. On the other hand, an empty span has to be written <span></span>.

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

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.

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.

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.

Reply on news.ycombinator.com