XHTML Club

55 pointsposted 8 hours ago
by bradley_taunt

32 Comments

nathell

7 hours ago

It’s ironic that the very site in question, despite claiming XHTML compliance, is served as text/html instead of application/xhtml+xml, so the browser will never parse it as XML.

To quote [0]:

> All those “Valid XHTML 1.0!” links on the web are really saying “Invalid HTML 4.01!”.

Although the article is 20 years old now, so these days it’s actually HTML5.

Edit: Checked the other member sites. Only two are served as application/xhtml+xml.

[0]: https://webkit.org/blog/68/understanding-html-xml-and-xhtml/

jraph

7 hours ago

And this makes the XML prolog invalid, because it's invalid to have it in HTML.

Not having it is XHTML compliant though, so it could just be removed.

hannob

7 hours ago

I used to create a number of simple web pages in XHTML back in the days when we believed XHTML was the future. Recently, while going through and restructuring some of my old "online stuff", I learned that XHTML really isn't in a state that I'd want to use it any more:

* XHTML 1.0 and 1.1 are officially deprecated by the W3C.

* XHTML5 exists as a variant of HTML5. However, it's very clear that it's absolutely not a priority for the HTML5 working groups, and there's a statement that future features will not necessarily be supported by the XHTML5 variant.

* XHTML5 does not have a DTD, so one of the main advantages of XHTML - that you can validate its correctness with pure XML functionality - isn't there.

* If you do a 'view source' in Firefox on a completely valid XHTML 1.0/1.1 page, it'll redline the XML declaration like it's something wrong. Not sure if this is intended or possibly even a bug, but it certainly gives me a 'browser tells me this is not supposed to be there' feeling.

It pretty much seems to me XHTML has been abandoned by the web community. My personal conclusion has been that whenever I touch any of my old online things still written in XHTML, I'll convert them to HTML5.

swiftcoder

6 hours ago

> If you do a 'view source' in Firefox on a completely valid XHTML 1.0/1.1 page, it'll redline the XML declaration like it's something wrong

Is the page actually being served as "application/xhtml+xml"? Most xhtml sites aren't, in which case the browser is indeed interpreting those as invalid declarations in a regular old html document

jraph

6 hours ago

> it's very clear that it's absolutely not a priority for the HTML5 working groups

I wouldn't mind as long as it keeps working, but…

> and there's a statement that future features will not necessarily be supported by the XHTML5 variant.

That's news for me, and unfortunate.

al_borland

7 hours ago

I was in college when XHTML was all the rage and everything we wrote had to pass validation. I still get uncomfortable adding breaks without closing them.

jraph

6 hours ago

Younger but on the same boat. Nothing reasonable, but this just feels unmatched. It itches exactly like an (unclosed parenthesis

firefoxd

an hour ago

Just tested my xhtml website on validator.w3.org , the errors I see triggered me:

> Trailing slash on void elements has no effect and interacts badly with unquoted attribute values.

Unquoted attribute values? So help me I don't see you using unquoted attribute values.

netsharc

6 hours ago

> Validation is ignored, and most modern sites are built with little concern for structure or longevity.

I remember going online with a modem in the 90s. There was a new ISP in town, but their homepage took forever to load. I viewed the source, and whatever page generator they were rendered the page as HTML tables (this was fine back then), and added repetitive style tags to every table cell instead of using CSS (although I wonder if this was before CSS) or not doing so for empty cells, and that their homepage was so bloated and slow to load on dial-up.

I wonder how it is nowadays. But I suppose in the age that accomodates apps like Teams and Slack, who cares?

jraph

6 hours ago

If only the repeated inline styles and abusively nested tables were the issue…

The dozens (or hundreds! have you tried GitHub recently??) HTTP requests.

The JavaScript bundles whose sizes are expressed in 10⁶ bytes.

The UIs that are fully recomputed and redrawn on each small interaction.

The auto playing videos. The images that are comparable to full res pictures (but usually empty of meaning because they are stock or AI generated).

notnullorvoid

6 hours ago

I highly recommend everyone involved in web development to read at least a small proportion of the horrors that are the HTML parser specification. It will leave you yearning for the return of XHTML.

Or you could also read web proposals where the reason for avoiding the ideal implementation is complication of updating HTML parser rules.

Or attempt to use the web features that are already hindered by the HTML parser (custom element table rows).

jraph

6 hours ago

> It will leave you yearning for the return of XHTML.

…or be grateful you can just use an existing HTML5 parser that hides all this stuff to your innocent eyes :-)

kevincox

7 hours ago

I would really like to use XHTML. It would make my HTML emitter much simpler (as I don't need special rules for elements that are self-closing, have special closing or escaping rules and whatever else) and more secure.

However no browsers have implemented streaming XHTML parsers. This means that the performance is notably worse for XHTML and if you rely on streaming responses (I currently do for a few pages like bulk imports) it won't work.

jraph

7 hours ago

> no browsers have implemented streaming XHTML parsers

Dang, I hadn't considered this. That's something to add to the "simplest HTML omitting noisy tags like body and head vs going full XHTML" debate I have with myself.

One for XHTML: I like that the parser catches errors, it often prevent subtle issues.

jraph

7 hours ago

In the linked article:

> you should master the HTML programming¹ language

The footnote reads:

> 1. This is a common debate - but for simplicity sake I'm just calling it this.

It's not really a debate, HTML is a markup language [1], not a programming language: you annotate a document with its structure and its formatting. You are not really programming when you write HTML (the markup is not procedural) (and this is not gatekeeping, there's nothing wrong about this and doesn't make HTML a lesser language).

To avoid the issue completely, you can phrase this as: "you should master HTML" and remove the footnote. Simple, clean, concise, clear. By the way, ML already means "Markup Language", so any "HTML .* language" phrasing can feel a bit off.

[1] https://en.wikipedia.org/wiki/Markup_language

radicalethics

7 hours ago

What happens if I simply add an iterator mechanism to HTML (well, I guess we need variables too)? Is it no longer a markup language here (I won't add anything else):

<for i=0; i<1; i++> <html> </html> </for>

Better question, why don't we upgrade XML to do that?

embedding-shape

7 hours ago

I dunno, you're being pedantic :) Yes yes, the name clearly ends up "Markup Language" so yeah, with a very strict definition of programming languages, HTML is not one of them.

But if we use a broader definition, basically "a formal language that specifies behavior a machine must execute", then HTML is indeed a programming language.

HTML is not only about annotating documents or formatting, it can do things you expect from a "normal" programming language too, for example, you can do constraints validation:

    <input name="token" required pattern="[A-Z]{3}-\d{4}" title="Must match ABC-1234 (3 uppercase letters, hyphen, 4 digits)" placeholder="ABC-1234">
That's neither annotating, just a "document" or just formatting. Another example is using <details> + <summary> and you have users mutating state that reveals different branches in the page, all just using HTML and nothing else.

In the end, I agree with you, HTML ultimately is a markup language, but it's deceiving, because it does more than just markup.

falcor84

7 hours ago

I think that it is a debate, and it depends on the role of HTML in your system.

If all you're doing is using HTML to "annotate a document with its structure and its formatting", then yes, I'll accept that it's not quite programming, but I've not seen this approach of starting with a plain non-html document and marking it up by hand done in probably over two decades. I do still occasionally see it done for marking up blog posts or documentation into markdown and then generating html from it, but even that's a minuscule part of what HTML is used for these days.

Your mileage my vary, but what I and people around me typically do is work on hundreds/thousands of loosely coupled small snippets of HTML used within e.g. React JSX, or Django/Jinja templates or htmx endpoints, in order to dynamically control data and state in a large program. In this sense, while the html itself doesn't have control flow, it is an integral part of control flow in the larger system, and it's extremely likely that I'll break something in the functionality if I carelessly change an element's type or attribute value. In this sense, I'm not putting on a different hat when I'm working on the html, but just working on a different part of the program.

PaulHoule

6 hours ago

Circa '99 a high fraction (50%-ish) of HTML in the field was invalid, so if you were making a new web browser it had to parse invalid HTML the same way as Netscape which was one more reason we didn't get competitive web browsers.

HTML 5 specified exactly how "invalid" HTML is parsed so now there is no such thing as invalid HTML. XHTML was one of those things that never quite worked:

https://friendlybit.com/html/why-xhtml-is-a-bad-idea/

jraph

6 hours ago

> there is no such thing as invalid HTML

There is. There are things that are still considered invalid, like nesting form elements for instance.

(this doesn't take away your argument though, and you were focusing on the parsing aspect).

yomismoaqui

4 hours ago

Is this ragebait?

I lived through the XML hype cycle and god it was awful. I Still have nightmares about some XSLT I had to maintain.

Good riddance...

reconnecting

7 hours ago

Valid pure HTML 4.01 (1) made in 2025 counts?

I don’t thing it’s about luddites as website mentioned. Many professions have tools suggesting that person have extensive experience and in terms of web development, XHTML 1.0 or old standards of HTML are such.

1. https://www.tirreno.com

throwaway150

7 hours ago

It does not? HTML 4.01 is not XML. So not XHTML. What's the confusion?

jraph

7 hours ago

The XML part of XHTML is an important feature which HTML 4.01 doesn't have tough.

Writing valid HTML should be a bare minimum (I know it isn't!).

reconnecting

5 hours ago

You might avoid using inline CSS here by replacing <h2 style="font-weight:normal;"> with <font size="5">

GavinAnderegg

7 hours ago

In the early 2000s I was 100% sold on the idea of strict XHTML documents and the semantic web. I loved the idea that all web pages could be XML documents which easily provided their data for other sources. If you marked your document with, an XHTML 1.0 Strict or XHTML 1.1 doctype, a web browser was supposed to show an error if the page contained an XML error. Problem was, it was a bit of a pain to get this right, so effectively no one cared about making compliant XHTML. It was a nice idea, but it didn't interact well with the real world.

Decades later, I'm still mildly annoyed when I see self-closing tags in HTML. When you're not trying to build a strict XML document, they're no longer required. Now I read them as a vestigial reminder of the strict XHTML dream.

EDIT: I just checked, and my site (at least the index page) still validates! https://validator.nu/?showsource=yes&doc=https%3A%2F%2Fander...

EDIT2: Hey, look, if you still want to use self-closing tags where they're not required: go nuts! I'm just explaining why I don't use them anymore.

strogonoff

6 hours ago

As someone who has gotten into the idea of semantic Web long after XHTML was all the rage[0], I somewhat resent that semantic Web and XML are so often lumped together[1]. After all, XML is just one serialisation mechanism for linked data.

[0] I don’t dislike XHTML. The snob in me loves the idea. Sure, had XHTML been The Standard it would have been so much more difficult to publish my first website at the age of 14 that I’m not sure I would have gotten into building for Web at all, but is it necessarily a good thing if our field is based on technology so forgiving to malformed input that a middle school pupil can pass for an engineer? and while I do omit closing tags when allowed by the spec, are the savings worth remembering these complicated rules for when they can be omitted, and is it worth maintaining all this branching that allows parsers to handle invalid markup, when barely any HTML is hand-written these days?

[1] Usually it is to the detriment of the former: the latter tends to be ill-regarded by today’s average Web developer used to JSON (even as they hail various schema-related additions on top of JSON that essentially try to make it do things XML can, but worse).

jraph

6 hours ago

> I'm still mildly annoyed when I see self-closing tags in HTML

Why? That's (mildly) bad for your health.

direwolf20

6 hours ago

You're annoyed when people are trying to keep the dream alive?

Since HTML5 specifies how to handle all parse errors, and the handling of an XML self-closing tag is to ignore it unless it's part of an unquoted attribute value, it's valid HTML5.

jraph

6 hours ago

I knew this HN submission would ate my Saturday afternoon and replace any other procrastination activity. Thanks, I hate it.