Tags to make HTML work like you expect

Original Article ↗ Hacker News Discussion ↗

HTML boilerplate, Open Graph, and meta tags

  • Several commenters reference HTML5 Boilerplate as their go‑to starter, noting it even includes Facebook’s Open Graph (og:*) tags.
  • Debate over Open Graph: some see it as “proprietary Facebook cruft,” others counter that many successful standards began as company inventions and OGP is widely used despite a poor, effectively abandoned spec.
  • The article’s own minified HTML is noted as technically invalid (e.g., <!doctypehtml>), exploiting parsing leniency vs. authoring rules.

Optional tags, strictness, and XHTML nostalgia

  • Multiple comments point out that <html>, <head>, and <body> start/end tags are optional and that HTML auto‑closes many elements.
  • Some enjoy “minimal valid HTML” and omitting closing tags; others find this shoddy and prefer explicit closures for readability and error‑proofing.
  • This evolves into a long XHTML vs. HTML5 discussion:
    • Pro‑XHTML side: stricter parsing would have simplified engines, tooling, and robustness.
    • Anti‑XHTML side: strictness broke too many real‑world pages, users won’t accept “yellow screen of death,” and browsers are incentivized to render sloppy markup.

Viewport, locale quirks, and encodings

  • The ubiquitous meta viewport is dissected:
    • initial-scale may be all that’s needed; width=device-width is called cargo cult.
    • The spec’s use of locale‑dependent number parsing (strtod) could misparse decimals like 1.5 under some locales.
  • Some lament that mobile‑driven viewport hacks are permanent baggage.
  • There is frustration that HTML still doesn’t hard‑default to UTF‑8, forcing meta charset boilerplate and occasional encoding bugs.

DOCTYPE, quirks mode, and HN’s UI

  • Explanation that <!DOCTYPE html> (case‑insensitive) is required for standards mode; without it pages fall into quirks mode.
  • HN and paulgraham.com lack a DOCTYPE, so they render in quirks mode; this breaks some modern CSS selectors and scripts.
  • A large subthread debates HN’s very small font size and narrow content width:
    • Some praise high information density and dislike modern “big text with huge whitespace.”
    • Others find HN unreadably tiny on high‑DPI/4K setups and argue it should respect browser font settings and use relative units (rem).
    • Users propose browser zoom, user styles, and extensions as workarounds.

lang attribute usefulness and values

  • The article’s lang="en" recommendation prompts debate:
    • Supporters say lang helps screen readers choose voice/accents, improves spell‑check, hyphenation, indexing, and translation.
    • Skeptics argue language detection is “trivial” and lang adds little; others push back, noting detection isn’t perfect, especially on mixed‑language pages.
  • Discussion over en vs en-US vs “international English” variants; some want finer distinctions for locales, units, and idioms.
  • Mixed‑language content: suggestion to tag the root <html> with site language and override with lang on inner elements (or use lang="" when unknown).

No‑build JavaScript, web components, and TypeScript

  • Several commenters favor “no‑bundler” approaches: native ES modules, web components, and minimal tooling, often without Shadow DOM.
  • Some happily write plain JS for simplicity; others insist they wouldn’t give up TypeScript but still avoid heavy bundling, relying on modern runtimes that strip types.
  • There’s criticism of complex JS build chains for simple sites and nostalgia for being able to open an HTML file directly without tooling.

Accessibility and semantics (<main>, <nav>, screen readers)

  • The joke “SPA boilerplate” (<div id="root"></div><script src="bundle.js">) prompts a reminder to include <main> so screen readers can skip chrome, and to mark navigation with <nav> or role="navigation".
  • Some share experiences testing with screen readers:
    • Navigation should appear early in document/tab order; “skip to content” links are recommended.
    • Real testing is hard because behavior varies across OS / browser / screen‑reader combinations and input devices.

CSS defaults and small best practices

  • Suggestions to pair HTML boilerplate with CSS normalization or minimal resets (e.g., Normalize.css, custom small resets).
  • Common patterns: *, *:before, *:after { box-sizing: border-box; } and fixing monospace font sizing with code, pre, tt, kbd, samp { font-family: monospace, monospace; }.
  • meta name="color-scheme" content="light dark" is recommended for automatic dark‑mode friendliness.

Is sharing basics in 2025 still useful?

  • One commenter questions whether such elementary HTML tips are worth posting now.
  • Many others strongly defend it: knowledge is unevenly distributed; people are always learning; basic, explicit write‑ups are valuable even for veterans who’ve been cargo‑culting boilerplate for years.