15 ms·

XHTML Club

71 points by bradley_taunt 8mo ago

jraph 8mo 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 https://en.wikipedia.org/wiki/Markup_language
- embedding-shape 8mo 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.
  - jraph 8mo ago
    > I dunno, you're being pedantic :) 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 8mo ago
    I'm not sure we can call your parent comment pedantic. They're just being correct. Is it pedantic to say that fish is not a fruit? It's just correct to do so. 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.
  - PaulHoule 8mo ago
    One threshold is "can you write a program that might not complete?" You can't in SQL, which makes it less of a programming language than, say, FORTRAN. If you look at the HTML 5 spec it is clear that it's intended to be a substrate for applications. The HTML 5 spec could be factored into a specification of the DOM, specification of an x-language API for the DOM and a specification for a serialization format as well as bindings of that x-language API to specific languages like Javascript.
    - jraph 8mo ago
      > If you look at the HTML 5 spec it is clear that it's intended to be a substrate for applications That's the saddest thing I've read today. (arguably not a terribly sad day)
      - PaulHoule 8mo ago
        Back when it was fashionable to complain about how every Electron application has 30 MB of bloat I did an eval of all the options for x-platform applications that weren't Electron and came to the conclusion that "they all sucked" except for maybe JavaFX -- and not everybody likes Java as much as I do. Building up to Win 8, Microsoft pushed for grid and flexbox which are the bees knees for laying out applications in HTML. Compare the annoying nag dialogs in MacOS and Windows. MacOS nags you to buy into Apple Music and other unwanted services with 2025 reskins of the 1999 reskins of the modal dialogs from the 1984 Mac Classic. Windows does the same with ads that look like advertising which I find more visually appealing even if the services are unappealing. Every time I think about writing a GUI application that's not a web application I think "this is a waste of time" whereas my web applications keep finding new lives as mobile applications, VR applications, etc.
        jraph 8mo ago
        > Back when it was fashionable to complain about how every Electron application has 30 MB of bloat What, it's not anymore?? And yes, I do end up writing web applications every time too (I haven't bundled them though). I don't want to tie myself to a specific platform, and being able to point users to an URL and bam, they can run the thing, is convenient. I hate that this makes me dependent on tech maintained with Big Tech money though.
  - JimDabell 8mo ago
    > behavior a machine must execute This is not what HTML does. Tags are not instructions, they delimit the start and end of elements. They describe content, they do not specify behaviour. In your pattern example, that is still just a description of what is acceptable input. It doesn’t execute anything. A paper form might specify the format DD / MM / YYYY but that doesn‘t mean the form is executing a program in your brain when you fill it out.
- radicalethics 8mo 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?
  - jraph 8mo ago
    That's not technically HTML anymore. 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 https://news.ycombinator.com/item?id=46743219#46743554
  - direwolf20 8mo ago
    That's basically the design of PHP with different syntax. <?for($i=0;$i<1;$i++){?> <html></html> <?}?> 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 8mo ago
      You could have some client side JavaScript handle your for nodes as well. That's how I imagined what OP described actually. > Nobody uses PHP this way any more though Well… I have bad news. I do, for one :-)
      - PaulHoule 8mo ago
        I ask you then: (1) how do you deal with the template that surrounds a large number of pages on a site? (2) how do you deal with the fact that the average web form might want to display something different based on the form contents (e.g. redraw the form if there's an error, draw something different on success?) (3) do you write anything that returns JSON or other results for AJAX or web services?
- falcor84 8mo 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.
  - jraph 8mo ago
    > React JSX, or Django/Jinja templates 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 8mo ago
    > In this sense, while the html itself doesn't have control flow, it is an integral part of control flow in the larger system 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.
- deleted 8mo ago
  [deleted]
- deleted 8mo ago
  [deleted]
- MrJohz 8mo ago
  Of course HTML is a programming language. It's one of the languages I use every day to program with. I'm not sure what the definition of a programming language would be beyond that. Do you mean "Turing-complete" language? Or maybe "procedural programming language"? I agree HTML isn't either of those, but those aren't the be-all and end-all of programming now, are they?
  - jraph 8mo ago
    I, and most of us, mean a language in which one can express a computer program, which is a set of instructions for a computer to execute. You don't execute an HTML file, you display it, render it. You can't implement fizz buzz in HTML. At best, you mark up its output. With HTML, you don't instruct, you describe. You instruct what to do with JavaScript, or Python, or whatever programming languages you use client or server side. A programming language doesn't need to be procedural, it can be functional, or use another computationally equivalent paradigm. I'm not quite sure it needs to be Turing complete, but possibly. A programming language lets you express to some processor that provides a set of computation primitives what to do with the memory cells you have at your disposal, and in general it lets you deal with input and output. If you consider any language you program with to be a programming language, then CSS, JSON, YAML, XML, markdown (that's what your readme is likely written in) and even English (that's what you use to express the specs, the bugs, maybe your notes / drafts, the comments, possibly the language the singer of the songs you're listening to while programming use) or UML need to be programming languages too. That's not quite useful. "Program with" is too large and would make the "programming" qualifier largely useless. https://en.wikipedia.org/wiki/Programming_language https://en.wikipedia.org/wiki/Programming_language https://en.wikipedia.org/wiki/Computer_program https://en.wikipedia.org/wiki/Computer_program https://en.wikipedia.org/wiki/List_of_programming_languages https://en.wikipedia.org/wiki/List_of_programming_languages https://stackoverflow.com/questions/14512218/is-html5-a-programming-language https://stackoverflow.com/questions/14512218/is-html5-a-prog...
    - MrJohz 8mo ago
      An HTML file is a set of instructions to execute. They're very high-level, declarative instructions for describing a UI, similar to how SQL is high-level declarative instructions for describing a set of data to be loaded, or how Prolog is a high-level declarative set of instructions for describing a set of logical axioms, but they're still instructions. You pass them to an execution engine, and on the basis of the instructions you've written, the engine does something. (See e.g. the section on fourth generation PLs in the second link you gave.) More broadly, I think this discussion is a stupid one. There is no formal, mathematically precise definition of a programming language. There are formal definitions of lots of PL-related things, and for what a language is in general (a combination of syntax and semantics), but there's no formal definition of the term "programming language" that's useful here. So if we're not arguing about a formal definition, then we're arguing about essentially our favourite dictionaries, and how we personally interpret our favourite dictionaries. And that's just not a useful argument at all, it's not even how dictionaries are meant to work! And yet whenever someone dares to write "HTML programming language" or something similar, there is always a comment from someone demanding that the author use their personal dictionary, and correct their changes. And it is deeply grating, because whenever I see this happen: * The original statement is never ambiguous. I have never seen a situation where referring to HTML as a programming language has ever caused some sort of confusion. * The discussion about whether HTML is a programming language is almost always completely irrelevant to the topic at hand, and bringing it up adds no value to the discussion. * The author's definition is usually inconsistent anyway. Which isn't a problem — I don't imagine my mental definition of a programming language is entirely consistent either — but it's dumb watching someone try and correct other people without understanding their own definition enough to be able to respond to clarifying questions. In your original comment, you said "it's not really a debate", and that's completely correct. It's not a debate because there's no right answer. There's not even any value to a right answer. The matter is entirely a question of terminology. And if different choices of terminology make things unclear, then it might be worth clarifying that terminology, but here I don't think the author could have been any clearer at all about what they were trying to communicate.
- recursivedoubts 8mo ago
  consider the following: https://html-lang.org/ https://html-lang.org/
  - jraph 8mo ago
    Oh yes, this is "HTML, the programming language", not HTML (also called "HTML, the markup language" in that page). And it's brilliant :-)
nathell 8mo 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/ https://webkit.org/blog/68/understanding-html-xml-and-xhtml/
- jraph 8mo 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.
- assimpleaspossi 8mo ago
  >>these days it’s actually HTML5. There is no HTML5. It's just a buzzword. https://html.spec.whatwg.org/dev/introduction.html#is-this-html5 https://html.spec.whatwg.org/dev/introduction.html#is-this-h...?
  - jraph 8mo ago
    That's a stretch. Your link says > 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. [1] https://en.wikipedia.org/wiki/HTML5 https://en.wikipedia.org/wiki/HTML5
    - assimpleaspossi 8mo ago
      It's not a technical term. Nowhere in the current HTML standard will you find a versioning of HTML. That's why it's now called a "living standard". You will never find a HTML6 or higher. That note you found is to help with any confusion.
kevincox 8mo 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 8mo 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.
reconnecting 8mo 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 https://www.tirreno.com
- throwaway150 8mo ago
  It does not? HTML 4.01 is not XML. So not XHTML. What's the confusion?
  - reconnecting 8mo ago
    Both technologies are from the same period and share same validation culture from W3.
    - jraph 8mo ago
      > Both technologies are from the same period 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.
      - reconnecting 8mo ago
        How so? HTML 4.01 is from 1999, XHTML 1.0 from 2000. XHTML club mentioned valid XHTML 1.0 Strict (or Transitional), not general XHTML.
- jraph 8mo 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 8mo ago
    It is not “your HTML”, it’s HTML 4.01 from 1999, when XHTML 1.0 is from 2000. The common is the origins of validations that comes from W3 validator (1). Same badges, same limits. 1. https://validator.w3.org/ https://validator.w3.org/
hannob 8mo 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 8mo 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
  - chrismorgan 8mo ago
    If it’s served as XML, then view-source instead highlights the doctype line as an error (“Stray doctype.”).
    - jraph 8mo ago
      I can confirm, I'm seeing this on my XHTML pages that are served as application/html+xml, that's a shame.
  - cxr 8mo ago
al_borland 8mo 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.
- deleted 8mo ago
  [deleted]
- jraph 8mo ago
  Younger but on the same boat. Nothing reasonable, but this just feels unmatched. It itches exactly like an (unclosed parenthesis
  - dang 8mo ago
    There used to be a commenter here who would end all his comments with a closing paren, even though there had not been an opening paren. It led to a surprising number of flamewars! ) Edit: hmm, I couldn't really find any flamewars, but it did lead to objections: https://news.ycombinator.com/item?id=8534213 https://news.ycombinator.com/item?id=8534213 (Oct 2014) https://news.ycombinator.com/item?id=8533381 https://news.ycombinator.com/item?id=8533381 (Oct 2014) https://news.ycombinator.com/item?id=6027549 https://news.ycombinator.com/item?id=6027549 (July 2013) https://news.ycombinator.com/item?id=4990706 https://news.ycombinator.com/item?id=4990706 (Dec 2012) https://news.ycombinator.com/item?id=4963264 https://news.ycombinator.com/item?id=4963264 (Dec 2012) https://news.ycombinator.com/item?id=4943159 https://news.ycombinator.com/item?id=4943159 (Dec 2012) https://news.ycombinator.com/item?id=4881400 https://news.ycombinator.com/item?id=4881400 (Dec 2012) https://news.ycombinator.com/item?id=4765943 https://news.ycombinator.com/item?id=4765943 (Nov 2012)
    - jraph 8mo ago
      Hilarious. To fix this, one would have needed to put an open parenthesis in a sibling comment and hope to get upvoted more than the comment with the closing parent.
    - tptacek 8mo ago
      That's demonic.
GavinAnderegg 8mo 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%2Fanderegg.ca 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.
- jraph 8mo ago
  > I'm still mildly annoyed when I see self-closing tags in HTML Why? That's (mildly) bad for your health.
- direwolf20 8mo 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.
  - GavinAnderegg 8mo ago
    I'm not annoyed by it when people are trying to make XML compatible documents, but effectively no one is. Platforms like WordPress use self-closing image tags everywhere, but almost no one using WordPress cares about document validation. This ends up meaning that the `<img ... />` is just an empty gesture.
- strogonoff 8mo 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).
netsharc 8mo 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 8mo 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).
- JimDabell 8mo ago
  > 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 Apart from the fact that very few people understood CSS back then, there was a stupendous amount of really weird bugs. For instance, I remember having a simple th { font-size: … } rule, and some versions of Netscape 4 somehow managed to apply the font size to all <th> cells except for the third one. So workarounds like extra style attributes were added to fix things like this.
PaulHoule 8mo 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/ https://friendlybit.com/html/why-xhtml-is-a-bad-idea/
- jraph 8mo 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).
  - chrismorgan 8mo ago
    The things that are invalid should all have defined behaviour. For example, a <label> is not allowed to contain two form controls, but is defined as applying to the first such control. As far as parse errors is concerned, https://html.spec.whatwg.org/multipage/parsing.html#parse-errors 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.
    - jraph 8mo ago
      > The things that are invalid should all have defined behaviour 100% agree. And then I guess the philosophical question is "What's invalid when everything is defined?"
      - 8mo ago
jraph 8mo ago
I knew this HN submission would ate my Saturday afternoon and replace any other procrastination activity. Thanks, I hate it.
notnullorvoid 8mo 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 8mo 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 :-)
  - notnullorvoid 8mo ago
    Grateful in part, but I can't help to think that if there was refusal to build parsers for an outlandish spec in the first place then we'd have fixed the problem by now. Using existing parsers only hides the poor design up to a point.
    - jraph 8mo ago
      I'm conflicted on this. I mostly agree with the sentiment, I'd rather have simple parsers and sensible specs, but I'm also happy they do whatever it takes not to break anything (well, they are breaking XSLT…)
    - yomismoaqui 8mo ago
      Nowadays you can use AI to write the parser, so it's the machine the one that suffers I guess. https://friendlybit.com/python/writing-justhtml-with-coding-agents/ https://friendlybit.com/python/writing-justhtml-with-coding-...
robin_reala 8mo ago
XHTML survives in ePub. Recently there was a survey to gather industry feedback for a potential addition of an HTML flavour of ePub to be added to the next version of the spec, but it soon became fairly clear that people saw a lot of value in remaining XHTML-only: https://www.w3.org/blog/2026/epub-and-html-survey-results-and-next-steps/ https://www.w3.org/blog/2026/epub-and-html-survey-results-an...
reconnecting 8mo ago
You might avoid using inline CSS here by replacing <h2 style="font-weight:normal;"> with <font size="5">
yomismoaqui 8mo 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...
firefoxd 8mo 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.
- Elfener 8mo ago
  I think you (or the site decided to) ran it through the html5 validator?

71 points by bradley_taunt 8mo ago

jraph 8mo 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 https://en.wikipedia.org/wiki/Markup_language

embedding-shape 8mo 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.
- jraph 8mo ago
  > I dunno, you're being pedantic :) 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 8mo ago
  I'm not sure we can call your parent comment pedantic. They're just being correct. Is it pedantic to say that fish is not a fruit? It's just correct to do so. 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.
- PaulHoule 8mo ago
  One threshold is "can you write a program that might not complete?" You can't in SQL, which makes it less of a programming language than, say, FORTRAN. If you look at the HTML 5 spec it is clear that it's intended to be a substrate for applications. The HTML 5 spec could be factored into a specification of the DOM, specification of an x-language API for the DOM and a specification for a serialization format as well as bindings of that x-language API to specific languages like Javascript.
  - jraph 8mo ago
    > If you look at the HTML 5 spec it is clear that it's intended to be a substrate for applications That's the saddest thing I've read today. (arguably not a terribly sad day)
    - PaulHoule 8mo ago
      Back when it was fashionable to complain about how every Electron application has 30 MB of bloat I did an eval of all the options for x-platform applications that weren't Electron and came to the conclusion that "they all sucked" except for maybe JavaFX -- and not everybody likes Java as much as I do. Building up to Win 8, Microsoft pushed for grid and flexbox which are the bees knees for laying out applications in HTML. Compare the annoying nag dialogs in MacOS and Windows. MacOS nags you to buy into Apple Music and other unwanted services with 2025 reskins of the 1999 reskins of the modal dialogs from the 1984 Mac Classic. Windows does the same with ads that look like advertising which I find more visually appealing even if the services are unappealing. Every time I think about writing a GUI application that's not a web application I think "this is a waste of time" whereas my web applications keep finding new lives as mobile applications, VR applications, etc.
      - jraph 8mo ago
        > Back when it was fashionable to complain about how every Electron application has 30 MB of bloat What, it's not anymore?? And yes, I do end up writing web applications every time too (I haven't bundled them though). I don't want to tie myself to a specific platform, and being able to point users to an URL and bam, they can run the thing, is convenient. I hate that this makes me dependent on tech maintained with Big Tech money though.
- JimDabell 8mo ago
  > behavior a machine must execute This is not what HTML does. Tags are not instructions, they delimit the start and end of elements. They describe content, they do not specify behaviour. In your pattern example, that is still just a description of what is acceptable input. It doesn’t execute anything. A paper form might specify the format DD / MM / YYYY but that doesn‘t mean the form is executing a program in your brain when you fill it out.
radicalethics 8mo 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?
- jraph 8mo ago
  That's not technically HTML anymore. 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 https://news.ycombinator.com/item?id=46743219#46743554
- direwolf20 8mo ago
  That's basically the design of PHP with different syntax. <?for($i=0;$i<1;$i++){?> <html></html> <?}?> 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 8mo ago
    You could have some client side JavaScript handle your for nodes as well. That's how I imagined what OP described actually. > Nobody uses PHP this way any more though Well… I have bad news. I do, for one :-)
    - PaulHoule 8mo ago
      I ask you then: (1) how do you deal with the template that surrounds a large number of pages on a site? (2) how do you deal with the fact that the average web form might want to display something different based on the form contents (e.g. redraw the form if there's an error, draw something different on success?) (3) do you write anything that returns JSON or other results for AJAX or web services?
falcor84 8mo 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.
- jraph 8mo ago
  > React JSX, or Django/Jinja templates 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 8mo ago
  > In this sense, while the html itself doesn't have control flow, it is an integral part of control flow in the larger system 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.
deleted 8mo ago
[deleted]
deleted 8mo ago
[deleted]
MrJohz 8mo ago
Of course HTML is a programming language. It's one of the languages I use every day to program with. I'm not sure what the definition of a programming language would be beyond that. Do you mean "Turing-complete" language? Or maybe "procedural programming language"? I agree HTML isn't either of those, but those aren't the be-all and end-all of programming now, are they?
- jraph 8mo ago
  I, and most of us, mean a language in which one can express a computer program, which is a set of instructions for a computer to execute. You don't execute an HTML file, you display it, render it. You can't implement fizz buzz in HTML. At best, you mark up its output. With HTML, you don't instruct, you describe. You instruct what to do with JavaScript, or Python, or whatever programming languages you use client or server side. A programming language doesn't need to be procedural, it can be functional, or use another computationally equivalent paradigm. I'm not quite sure it needs to be Turing complete, but possibly. A programming language lets you express to some processor that provides a set of computation primitives what to do with the memory cells you have at your disposal, and in general it lets you deal with input and output. If you consider any language you program with to be a programming language, then CSS, JSON, YAML, XML, markdown (that's what your readme is likely written in) and even English (that's what you use to express the specs, the bugs, maybe your notes / drafts, the comments, possibly the language the singer of the songs you're listening to while programming use) or UML need to be programming languages too. That's not quite useful. "Program with" is too large and would make the "programming" qualifier largely useless. https://en.wikipedia.org/wiki/Programming_language https://en.wikipedia.org/wiki/Programming_language https://en.wikipedia.org/wiki/Computer_program https://en.wikipedia.org/wiki/Computer_program https://en.wikipedia.org/wiki/List_of_programming_languages https://en.wikipedia.org/wiki/List_of_programming_languages https://stackoverflow.com/questions/14512218/is-html5-a-programming-language https://stackoverflow.com/questions/14512218/is-html5-a-prog...
  - MrJohz 8mo ago
    An HTML file is a set of instructions to execute. They're very high-level, declarative instructions for describing a UI, similar to how SQL is high-level declarative instructions for describing a set of data to be loaded, or how Prolog is a high-level declarative set of instructions for describing a set of logical axioms, but they're still instructions. You pass them to an execution engine, and on the basis of the instructions you've written, the engine does something. (See e.g. the section on fourth generation PLs in the second link you gave.) More broadly, I think this discussion is a stupid one. There is no formal, mathematically precise definition of a programming language. There are formal definitions of lots of PL-related things, and for what a language is in general (a combination of syntax and semantics), but there's no formal definition of the term "programming language" that's useful here. So if we're not arguing about a formal definition, then we're arguing about essentially our favourite dictionaries, and how we personally interpret our favourite dictionaries. And that's just not a useful argument at all, it's not even how dictionaries are meant to work! And yet whenever someone dares to write "HTML programming language" or something similar, there is always a comment from someone demanding that the author use their personal dictionary, and correct their changes. And it is deeply grating, because whenever I see this happen: * The original statement is never ambiguous. I have never seen a situation where referring to HTML as a programming language has ever caused some sort of confusion. * The discussion about whether HTML is a programming language is almost always completely irrelevant to the topic at hand, and bringing it up adds no value to the discussion. * The author's definition is usually inconsistent anyway. Which isn't a problem — I don't imagine my mental definition of a programming language is entirely consistent either — but it's dumb watching someone try and correct other people without understanding their own definition enough to be able to respond to clarifying questions. In your original comment, you said "it's not really a debate", and that's completely correct. It's not a debate because there's no right answer. There's not even any value to a right answer. The matter is entirely a question of terminology. And if different choices of terminology make things unclear, then it might be worth clarifying that terminology, but here I don't think the author could have been any clearer at all about what they were trying to communicate.
recursivedoubts 8mo ago
consider the following: https://html-lang.org/ https://html-lang.org/
- jraph 8mo ago
  Oh yes, this is "HTML, the programming language", not HTML (also called "HTML, the markup language" in that page). And it's brilliant :-)

nathell 8mo 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/ https://webkit.org/blog/68/understanding-html-xml-and-xhtml/

jraph 8mo 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.
assimpleaspossi 8mo ago
>>these days it’s actually HTML5. There is no HTML5. It's just a buzzword. https://html.spec.whatwg.org/dev/introduction.html#is-this-html5 https://html.spec.whatwg.org/dev/introduction.html#is-this-h...?
- jraph 8mo ago
  That's a stretch. Your link says > 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. [1] https://en.wikipedia.org/wiki/HTML5 https://en.wikipedia.org/wiki/HTML5
  - assimpleaspossi 8mo ago
    It's not a technical term. Nowhere in the current HTML standard will you find a versioning of HTML. That's why it's now called a "living standard". You will never find a HTML6 or higher. That note you found is to help with any confusion.

kevincox 8mo 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 8mo 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.

reconnecting 8mo 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 https://www.tirreno.com

throwaway150 8mo ago
It does not? HTML 4.01 is not XML. So not XHTML. What's the confusion?
- reconnecting 8mo ago
  Both technologies are from the same period and share same validation culture from W3.
  - jraph 8mo ago
    > Both technologies are from the same period 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.
    - reconnecting 8mo ago
      How so? HTML 4.01 is from 1999, XHTML 1.0 from 2000. XHTML club mentioned valid XHTML 1.0 Strict (or Transitional), not general XHTML.
jraph 8mo 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 8mo ago
  It is not “your HTML”, it’s HTML 4.01 from 1999, when XHTML 1.0 is from 2000. The common is the origins of validations that comes from W3 validator (1). Same badges, same limits. 1. https://validator.w3.org/ https://validator.w3.org/

hannob 8mo 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 8mo 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
- chrismorgan 8mo ago
  If it’s served as XML, then view-source instead highlights the doctype line as an error (“Stray doctype.”).
  - jraph 8mo ago
    I can confirm, I'm seeing this on my XHTML pages that are served as application/html+xml, that's a shame.
- cxr 8mo ago

al_borland 8mo 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.

deleted 8mo ago
[deleted]
jraph 8mo ago
Younger but on the same boat. Nothing reasonable, but this just feels unmatched. It itches exactly like an (unclosed parenthesis
- dang 8mo ago
  There used to be a commenter here who would end all his comments with a closing paren, even though there had not been an opening paren. It led to a surprising number of flamewars! ) Edit: hmm, I couldn't really find any flamewars, but it did lead to objections: https://news.ycombinator.com/item?id=8534213 https://news.ycombinator.com/item?id=8534213 (Oct 2014) https://news.ycombinator.com/item?id=8533381 https://news.ycombinator.com/item?id=8533381 (Oct 2014) https://news.ycombinator.com/item?id=6027549 https://news.ycombinator.com/item?id=6027549 (July 2013) https://news.ycombinator.com/item?id=4990706 https://news.ycombinator.com/item?id=4990706 (Dec 2012) https://news.ycombinator.com/item?id=4963264 https://news.ycombinator.com/item?id=4963264 (Dec 2012) https://news.ycombinator.com/item?id=4943159 https://news.ycombinator.com/item?id=4943159 (Dec 2012) https://news.ycombinator.com/item?id=4881400 https://news.ycombinator.com/item?id=4881400 (Dec 2012) https://news.ycombinator.com/item?id=4765943 https://news.ycombinator.com/item?id=4765943 (Nov 2012)
  - jraph 8mo ago
    Hilarious. To fix this, one would have needed to put an open parenthesis in a sibling comment and hope to get upvoted more than the comment with the closing parent.
  - tptacek 8mo ago
    That's demonic.

GavinAnderegg 8mo 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%2Fanderegg.ca 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.

jraph 8mo ago
> I'm still mildly annoyed when I see self-closing tags in HTML Why? That's (mildly) bad for your health.
direwolf20 8mo 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.
- GavinAnderegg 8mo ago
  I'm not annoyed by it when people are trying to make XML compatible documents, but effectively no one is. Platforms like WordPress use self-closing image tags everywhere, but almost no one using WordPress cares about document validation. This ends up meaning that the `<img ... />` is just an empty gesture.
strogonoff 8mo 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).

netsharc 8mo 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 8mo 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).
JimDabell 8mo ago
> 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 Apart from the fact that very few people understood CSS back then, there was a stupendous amount of really weird bugs. For instance, I remember having a simple th { font-size: … } rule, and some versions of Netscape 4 somehow managed to apply the font size to all <th> cells except for the third one. So workarounds like extra style attributes were added to fix things like this.

PaulHoule 8mo 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/ https://friendlybit.com/html/why-xhtml-is-a-bad-idea/

jraph 8mo 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).
- chrismorgan 8mo ago
  The things that are invalid should all have defined behaviour. For example, a <label> is not allowed to contain two form controls, but is defined as applying to the first such control. As far as parse errors is concerned, https://html.spec.whatwg.org/multipage/parsing.html#parse-errors 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.
  - jraph 8mo ago
    > The things that are invalid should all have defined behaviour 100% agree. And then I guess the philosophical question is "What's invalid when everything is defined?"
    - 8mo ago

jraph 8mo ago

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

notnullorvoid 8mo 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 8mo 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 :-)
- notnullorvoid 8mo ago
  Grateful in part, but I can't help to think that if there was refusal to build parsers for an outlandish spec in the first place then we'd have fixed the problem by now. Using existing parsers only hides the poor design up to a point.
  - jraph 8mo ago
    I'm conflicted on this. I mostly agree with the sentiment, I'd rather have simple parsers and sensible specs, but I'm also happy they do whatever it takes not to break anything (well, they are breaking XSLT…)
  - yomismoaqui 8mo ago
    Nowadays you can use AI to write the parser, so it's the machine the one that suffers I guess. https://friendlybit.com/python/writing-justhtml-with-coding-agents/ https://friendlybit.com/python/writing-justhtml-with-coding-...

robin_reala 8mo ago

XHTML survives in ePub. Recently there was a survey to gather industry feedback for a potential addition of an HTML flavour of ePub to be added to the next version of the spec, but it soon became fairly clear that people saw a lot of value in remaining XHTML-only: https://www.w3.org/blog/2026/epub-and-html-survey-results-and-next-steps/ https://www.w3.org/blog/2026/epub-and-html-survey-results-an...

reconnecting 8mo ago

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

yomismoaqui 8mo 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...

firefoxd 8mo 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.

Elfener 8mo ago
I think you (or the site decided to) ran it through the html5 validator?