Comment by KronisLV | Hacker News Reader

Comment by KronisLV | Hacker News Reader

Parent Full thread

> The WHATWG was founded by individuals of Apple, the Mozilla Foundation, and Opera Software in 2004, after a W3C workshop. Apple, Mozilla and Opera were becoming increasingly concerned about the W3C’s direction with XHTML, lack of interest in HTML, and apparent disregard for the needs of real-world web developers. So, in response, these organisations set out with a mission to address these concerns and the Web Hypertext Application Technology Working Group was born.

Darn it, XHTML could have been so good if it got mass adoption! It would simplify parsing content and personally, working with XHTML is sane and easy (albeit in a somewhat dated Java stack with JSF/PrimeFaces, which build upon it). It also gets rid of the inconsistent tags in HTML which can remain open, which i think is a good thing.

Then again, i also like XML, maybe to the point of sometimes preferring it over JSON (or at i would if the ecosystem would be there - WSDL was leaps and bounds ahead of OpenAPI/Swagger, but seems like the interest in XML died down), so i don't doubt that many don't feel that way about all of it.

HTML5 has an XML serialization, so if you really must you can use XHTML5 today.

But I think for most people it is in general a bad idea. XHTML parsed as XML means that anything that mashes together strings to generate a webpage, like much of webdev, is prone to generating invalid XML due to bugs in the code, and this in turn leads to catastrophic failure where the page doesn’t just have errors but fails to render entirely. During the period where people were swayed by the XHTML proponents’ arguments it was commonplace for me to visit a website and see only an XML parsing error.

XHTML parsed according to custom rules that are forgiving for errors yet consistent and straightforward to implement would have been a good idea, but nobody implemented it to my knowledge. Luckily HTML5 does specify such a forgiving parsing system, where pretty much any random sequence of bytes can be parsed consistently.

Not only that, XHTML already had the ground work for web components.

XML is pretty much alive in the .NET and Java ecosystems.

There is nothing easy about XHTML. Or rather it is only easy if you ignore the essential parts of it.

The sell of the time to jQuery webmasters was:

XHTML's complexity is too much to deal with and the WHATWG is going to keep all this unnecessary stuff out so you won't lose control to generalized tools like an IDE and systems that favors formally educated language/tool writers, i.e. schema validators and, as we see now, transpilers.

The end result is still everyone using an IDE perhaps due to more irregular features after WHATWG encouraging a framework, but at any rate demonstrating XHTML was not the real source of webmaster stress and future angst.

So now you have more complexity, a still pointlessly irregular format that needs to identify it's magical elements, and, (to get back on topic,) features that must be implemented first in 2 browsers to become standard.

All of this is brought to you by employees of Apple and the other vendors. If WebKit isn't one of the 2 implementations most people choose to work with when pushing a standard then Safari is the dead implementation due to a constellation of choices all made with Apple's support and approval.

Only if one insists in writing it using vi.

Let's not go there.

Show us a vi plugin that can do as well as IDEs and UI designers for edit XML, including validation and XSLT debugging.

I wasn't going there, but then with such an interesting reply I might.

Reply on news.ycombinator.com