Seconded. I spend a whole lot of effort making my early 2000s websites emit compliant XHTML because it seemed like the right thing to do, and the way we were inevitably heading. And then I — and apparently almost everyone else, too, at the same time — realized it was a whole lot of busywork with almost nothing to show for it. The only thing XHTML ever added to the mix was a giant error message if you forget to write "<br/>" instead of "<br>".

Know what? Life's too short to lose time to remembering to close a self-closing tag.

About the time XHTML 1.1 came along, we collectively bailed and went to HTML5, and it was a breath of fresh air.

I actually rather like XML(asterisk) But this is one of it's warts, It wants to be two things, A markup language, it's in the name and arguably where it should have stayed, and an object notation. This is where you start to question some of XML's fundamentals, stuff like why is it redundant? When do you stick data in attributes? Or is it better to nest tags all the way down?

Asterisk: except namespaces, I loathe those, you are skipping happily along chewing through your XML, xpathing left and right, and then find out some psychopath has decided to use namespaces, and now every thing has become super awkward and formal.

I don’t recall Google being the ones to kill XHTML. Got any references to back that claim up?

XML died because it sucks. Everyone who had to deal with it back in the day jumped to YAML and/or JSON as quickly as they could. Google didn't cause that, but because they're a search engine they followed it.

The Semantic Web was never going to win. It does not make sense on a fundamental level.

XHTML's failure had nothing to do with it, and is basically unrelated. Even if xhtml won i fail to see how that would have helped semantic web in any way shape or form.

Right, both sort of suck at streaming, something about being closed form tree structures would be my guess(strictly speaking, you need to close the tree to serialize it, so no clean way to append data in real time, best you can do is to leave the structure open and send fragments). Having said that, I am not really sure what a good native streaming format would look like. Best guess is something flatter, closer to CSV.

Part of the problem was it came in an era before we really understood programming, as a collective. We didn't even really know how to encapsulate objects properly, and you saw it in poor database schema designs, bizarre object inheritance patterns, poorly organised APIs, even the inconsistent method param orders in PHP. It was everywhere. Developers weren't good at laying out even POCOs.

And those bizarre designs went straight into XML, properties often in attributes, nodes that should have been attributes, over nesting, etc.

And we blamed XML for the mess where often it was just inexperience in software design as an industry that was the real cause. But XML had too much flexibility compared to the simplicity of the later JSON, meaning it helped cause the problem. JSON 'solved' the problem by being simpler.

But then the flip side was that it was too strict and starting one in code was a tedious pita where you had to specify a schema even though it didn't exist or even matter most of the time.

HTML was conceived as a language for marking up a document that was primarily text; XML took the tags and attributes from that and tried to turn it into a data serialization and exchange format. But it was never really well suited to that, and it's obvious from looking XML-RPC or SOAP payloads that there were fundamental gaps in the ability of XML to encode type and structure information inline:

    <?xml version="1.0"?>
    <methodCall>
        <methodName>math.add</methodName>
        <params>
            <param>
                <value><int>5</int></value>
            </param>
            <param>
                <value><int>7</int></value>
            </param>
        </params>
    </methodCall>

Compared to this, JSON had string and number types built in:

    {
        "jsonrpc": "2.0",
        "method": "math.add",
        "params": [5, 7],
        "id": 1
    }

I don't think this is the only factor, but I think XML had a lot of this kind of cognitive overhead built in, and that gave it a lot of friction when stacked up against JSON and later yaml... and when it came to communicating with a SPA, it was hard to compete with JS being able to natively eval the payload responses.

> developers used it and did not like it.

This makes sense.

However, there are two ways to address it:

1) Work towards a more advanced system that addresses the issues (for example, RDF/Turtle – expands XML namespaces to define classes and properties, represents graphs instead of being limited to trees unlike XML and JSON)

2) Throw it away and start from scratch. First, JSON. Then, JSON schema. Jq introduces a kind of "JSONPath". JSONL says hi to XML stream readers. JSONC because comments in config files are useful. And many more primitives that existed around XML were eventually reimplemented.

Note how the discussion around removing XSLT 1 support similarly has two ways forward: yank it out or support XSLT 3.

I lean towards Turtle replacing XML over JSON, and for XSLT 3 to replace XSLT 1 support in the browsers.

The simplest explanation is that attributes were a mistake. They add another layer to the structure and create confusion as to where data is best stored within it.

XML without attributes probably would have seen wide and ready adoption.

While i think a lot of xml was a bad idea, some of the issues are not instrinsically the fault of XML but some really poor design decisions by people making xml based languages.

They tended to be design by comittee messes that included every possible use case as an option.

Anyone who has ever had the misfortune of having to deal with SAML knows what i'm talking about. Its a billion line long specification, everyone only implements 10% of it, and its full of hidden gotchas that will screw up your security if you get them wrong. (Even worse, the underlying xml-signature spec is literally the worst way to do digital signatures possible. Its so bad you'd think someone was intentionally sabotaging it)

In theory this isn't xml's fault, but somehow XML seems to attract really bad spec designers.

XHTML was too rigid - as a user agent it should try to render a document, rather than tell the user: "tough, the developer screwed up".

So XHTML lost to the much more forgiving HTML.

There was an idea to make a forgiving XML for web use cases: https://annevankesteren.nl/2007/10/xml5 but it never got traction.

For those unaware of XForms: https://www.youtube.com/watch?v=2yYY7GJAbOo

Making your data easy to scrape is part of the point (or just more generally work with). If you're building your web presence, you want people to easily be able to find the data on your site (unless your goal is platform lockin).

The entire point of XSLT is to separate your data from its presentation. That's why it made it easy to scrape. You could return your data in a more natural domain model and transform it via a stylesheet to its presentation.

And in doing so it is incredibly concise (mostly because XPath is so powerful).

could you share some examples please? i am interested in trying this out.

that's neat. i don't like inline js though. i'd like to be able to load it from a separate file so that i can reuse it on multiple pages.

i am thinking of something like

index.html

    <div><navigation/></div>

index.js

    function navigation() {
        document.querySelector('navigation').replaceWith('<a href="...">...')
    }

or maybe

    let customnodes = {
        navigation: '<a href="...">...',
        ...
    }

then add a function that iterates over customnodes and makes the replacements. even better if i could just iterate over all defined functions. (there is a way, i just didn't take the time to look it up) then the functions could be:

    function navigation() {
        return '<a href="...">...'
    }

and the iterator would wrap that function with the appropriate document.querySelector('navigation').replaceWith call.