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/
Not having it is XHTML compliant though, so it could just be removed.
There is no HTML5. It's just a buzzword. https://html.spec.whatwg.org/dev/introduction.html#is-this-h...?
> Is this HTML5?
> In short: Yes.
See also [1].
That HTML5 was used in marketing doesn't make the technical term disappear. HTML5 is a bit more precise than HTML, it refers to the living standard that's currently in use, as opposed to HTML 4.01 and the previous versions of HTML.
You might be right, but we don't know yet. Microsoft said that for Windows 10.
You might also be right that the current Living Standard specification doesn't really call it HTML5, but you'll find many people writing HTML for a living say HTML5 to refer to it, and telling them that HTML5 doesn't exist doesn't really help and is a bit wrong too if you have a descriptive approach to languages.
The next version of html should be able to do all the http verbs -- get, put, patch, post, delete online, reactively without having to use a form.
There has to be a way to figure this out, even if it requires a transition period. The best time to plant a tree was twenty years ago, the second best time is now. These things belong in the core HTML standards, not a js library you need to include in your code.
Oh that and better controls and better defaults but I guess that is something individual web browsers can implement on their own?
Yes, they could, but you want a standard that makes them all implement stuff in a compatible way… :-)
Assuming you are right and HTML5 doesn't exist. What would be the actual bad outcomes of the following?
- believing HTML5 exists
- silently choosing to understand what someone mentioning HTML5 obviously meant
Versioned standards allow you to know that you are compliant to that version of the specification, and track the changes between versions -- i.e. what additional functionality do I need to implement.
With "living standards" you need to track the date/commit you last checked and do a manual diff to work out what has changed.
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.
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.
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 or old standards of HTML are such.
Not really, XHTML is as current as HTML 5.
XHTML 1.0 is older and is indeed (more or less?) the XML variant of HTML 4.01.
XHTML club mentioned valid XHTML 1.0 Strict (or Transitional), not general XHTML.
Writing valid HTML should be a bare minimum (I know it isn't!).
Same badges, same limits.
but what you are describing is XHTML 1.0, not XHTML in general.
HTML5 has its XHTML variant too, sometimes called XHTML 5.
Where do you see this?
I see that they do use XHTML 1.0 Strict but I don't see this requirement written.
Brad, we need your clarification here, it's critical, we need you to tell us which one of us is wrong! :-)
XHTML Members(1):
Current websites that are valid XHTML 1.0 Strict (or Transitional)
Back to tirreno website, it is a pure transitional HTML 4.01 without JS or CSS, thus more or less same challenges to make it W3 valid (2) in our days. Have a look.
1. https://xhtml.club/members.html
2. https://validator.w3.org/check?uri=https://www.tirreno.com/&...
* 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.
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
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.
Decades later, I'm still mildly annoyed when I see self-closing tags in HTML. They're no longer required and they remind me 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...
Why? That's (mildly) bad for your health.
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.
[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).
https://www.w3.org/TR/xmlschema-2/
even though a lot of tools and standards (I'm looking at you SPARQL) don't really support them. My favorite serialization for RDF is Turtle:
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?
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).
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:
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).
As far as parse errors is concerned, https://html.spec.whatwg.org/multipage/parsing.html#parse-er... says:
> This specification defines the parsing rules for HTML documents, whether they are syntactically correct or not. Certain points in the parsing algorithm are said to be parse errors. The error handling for parse errors is well-defined (that's the processing rules described throughout this specification), but user agents, while parsing an HTML document, may abort the parser at the first parse error that they encounter for which they do not wish to apply the rules described in this specification.
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•1h ago
> 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
embedding-shape•1h ago
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:
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.
jraph•1h ago
It might be, I'm usually not, but this is all xhtml.club and this footnote are about, might as well be correct :-)
Constraint validation is still descriptive (what is allowed)
All details and summary are doing is conveying information on what's a summary and what's the complete story, and it has this hidden / shown behavior.
In any case, you will probably find something procedural / programming like in HTML, but it's not the core idea of the language, and if you are explaining what HTML is to a newbie, I feel like you should focus to the essential. Then we can discuss the corners between more experienced people.
In the end, all I'm saying is: you can just avoid issues and just say "HTML" without further qualifying it.
throwaway150•1h ago
If anything, it is the act of stretching the definition of "programming language" so much that it includes HTML as a programming language that we should call pedantic.
radicalethics•1h ago
<for i=0; i<1; i++> <html> </html> </for>
Better question, why don't we upgrade XML to do that?
jraph•1h ago
But if you disagree with this, or somehow work around this statement by replacing your for element with some "for-loop" custom element (it is valid HTML to add custom tags with dashes in their names), my stronger argument is at https://news.ycombinator.com/item?id=46743219#46743554
direwolf20•23m ago
Nobody uses PHP this way any more though — people treat it like Python or Node and write the entire codebase inside a big <? block
JSP is similar with different syntax again — nobody uses JSP either
I think ASP too but I never used that
jraph•22m ago
> Nobody uses PHP this way any more though
Well… I have bad news.
I do, for one :-)
PaulHoule•11m ago
mimasama•13m ago
XSLT which is an application of XML allows you to do a for-each: https://developer.mozilla.org/en-US/docs/Web/XML/XSLT/Refere...
falcor84•1h ago
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.
jraph•1h ago
Those are not HTML. PHP neither, even when used as a templating language for HTML.
> htmx endpoints
Not really familiar with htmx, but I would say this is HTML augmented with some additional mechanisms. I don't know how I would describe this augmented HTML, but I'm not applying my "not programming" statement to htmx (I probably could, but I haven't given enough thoughts to do it).
> 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.
I agree with this actually. I wouldn't consider that writing HTML (or CSS) is really a separate activity when I'm building some web app.
throwaway150•56m ago
That's correct but I don't see what it has got to do with the question of whether HTML is a programming language or not.
Strings do not have control flow but strings are integral part of larger programs that have control flow. So what? That doesn't make strings any closer to being programming languages.