XHTML Club

Original Article ↗ Hacker News Discussion ↗

Is HTML a Programming Language?

  • One side insists HTML is purely a markup language: declarative, non-procedural, mainly for structure and presentation, and should simply be called “HTML” without adding “programming language.”
  • Others argue for a broader definition: any formal language that directs machine behavior. They cite features like form constraint validation and <details>/<summary> state toggling as “behavior,” thus programming.
  • A middle view: HTML itself lacks control flow, but in modern stacks (templates, JSX, htmx) HTML fragments are integral to the overall program’s control flow. Still, that doesn’t inherently make HTML a programming language.

XHTML vs HTML, MIME Types, and Validity

  • Several point out the irony that the “XHTML Club” site is served as text/html, so browsers parse it as HTML, not XML; the XML prolog becomes invalid in that context.
  • Only a couple of listed member sites use the proper application/xhtml+xml MIME type.
  • Some like XHTML’s strict parsing and error-catching; others note the practical difficulty and lack of adoption.

Status of XHTML and XHTML5

  • XHTML 1.0/1.1 are described as deprecated; commenters feel XHTML has effectively been abandoned for the web.
  • XHTML5 exists as an HTML5-variant but is not a priority; specs say future HTML features may not be supported in XHTML5, undercutting one of XHTML’s historical advantages.
  • Lack of an XHTML5 DTD means you lose the simple “pure XML” validation story.
  • Browsers give confusing error hints in “view source” even for valid XHTML served as XML.
  • Desire for XHTML persists in niches (e.g., ePub), where strictness and XML tooling remain valuable.

HTML5 and the Living Standard Fight

  • Sharp disagreement over the statement “There is no HTML5”:
    • One camp: “HTML5” is just outdated branding; the real spec is a versionless living standard, and future “HTML6” etc. will never exist.
    • Others counter that HTML5 was a real W3C/WHATWG recommendation and still exists as a historical, technical standard; saying it “doesn’t exist” is misleading.
  • Broader concern: living standards make conformance and change-tracking harder than versioned specs.

Validation, Self-Closing Tags, and Parser Complexity

  • Nostalgia for the early-2000s culture of strict validation and XHTML/W3C badges; some still feel uneasy omitting closing slashes on void elements.
  • Others argue closing slashes in HTML are at best pointless, at worst harmful with unquoted attributes, and can create a false sense of correctness—though many treat it as style and rely on XHTML habits.
  • The HTML parsing spec is described as horrifyingly complex. Some wish browsers had refused such complexity, forcing a simpler design; others are just glad modern parsers hide this from developers.
  • HTML5 defines behavior even for many “invalid” constructs, which improves interoperability but blurs the notion of “invalid HTML.”

Performance, Streaming, and Real-World Use

  • One commenter wants XHTML for simpler, safer emitters but notes no browsers support streaming XHTML parsing, making it impractical for streaming responses.
  • There’s general lament that modern sites ignore structure and validation, favoring heavy JS bundles, many requests, and bloated UIs—seen as a continuation, at scale, of past sloppy markup practices.