Using Standard HTML (1997) | Hacker News Reader

Using Standard HTML (1997)

w3.org

72 pointsdredmorbius35 comments

Whenever I write HTML documents, I find it helpful to use the XHTML syntax. The strict XML parser catches syntax errors, incorrect nesting, unescaped characters, unquoted attributes, and more. And it supports all the tags and attributes of the HTML5 living standard, so I don't miss any modern functionality.

The standard "tag soup" HTML parser has numerous surprising behaviors on invalid or questionable HTML code. Examples:

The <p> element cannot nest, so starting a new one will end the previous one:

  <p>Hello
  <p>World
  
  gets transformed to
  
  <p>Hello</p>
  <p>World</p>

Furthermore, trailing junk triggers weirdness:

  <p>Hello
  <p>World
  </p></p>
  
  becomes
  
  <p>Hello</p>
  <p>World</p>
  <p></p>

Some elements are defined in the HTML DTD to have implicit start tags:

  <table><td>abc</td></table>
  
  yields the DOM tree of
  
  <table><tbody><tr><td>abc</td></tr></tbody></table>

Whereas in XHTML mode, either your code is a parse error, or what you see is what you get. You can nest <p> elements in XHTML, and you can make a <table> contain <td> directly (without the <tbody> and <tr> containers).

Does every popular browser support it in the same way? I would expect some subtle differences, because this mode is not very popular and probably not as tested as standard HTML.

On the contrary, part of the point of XHTML is you can reference the document type definition (DTD) so everyone would be on the same page.

https://www.w3.org/wiki/Doctypes_and_markup_styles

For example...

    <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

... is the XHTML 1.0 equivalent of HTML 4.01 except it won't validate loose HTML style markup, it all needs to be well formed XML.

That said, for HTML5 ...

https://stackoverflow.com/questions/1570418/if-i-use-html-5s...

Ten years ago they thought that should work a while. Looks like it.

Thanks, those are definitely good things. I never had much thought about it, but I definitely was bitten more than once by those auto-closing and auto-generating HTML tags, so strict XML might be a good alternative. Definitely will try it next time.

Note that XHTML must be served with application/xhtml+xml content-type.

In case you haven't already, I think you should take a look at SGML ([1], my site) which standardizes these and all other tag omission/inference rules used by HTML, and also attribute minimization. The hard-coded tag soup parser is by no means "standard".

[1]: http://sgmljs.net

Unfortunately, the XML-style syntax with all tags closed isn't allowed in HTML for certain tags. For instance, you can't close <input> or <br> or <hr> tags.

Yes you can.

    <input />, <br />, and <hr />

And it is valid XML. They are referred to as self closing tags.

It is valid XML. It means totally different thing in HTML.

The self-closing form is fine in HTML5 for those examples, since they are void elements. The "/" gets ignored, which is what you want in that case.

It fails if you try this with non-void elements: E.g. XHTML <div /> might turn into <div> in HTML5, which opens a div element, which is not the same. (I'm not sure if this behaviour is specified or not)

https://html.spec.whatwg.org/multipage/syntax.html#start-tag...

> 6. Then, if the element is one of the void elements [...] then there may be a single U+002F SOLIDUS character (/). This character has no effect on void elements [...]

https://html.spec.whatwg.org/multipage/syntax.html#void-elem...

> area, base, br, col, embed, hr, img, input, link, meta, param, source, track, wbr

  > The standard "tag soup" HTML parser has numerous
  > surprising behaviors on invalid or questionable HTML code.

There is nothing surprising here. And some elements are allowed to omit end tags, or even start and end tags altogether.

In fact, if you dig deeper there are a lot more surprises in XHTML documents (assuming they are served with the proper MIME type so they get treated like XHTML).

Gonna aggregate all the subtopics in one reply.

> you should take a look at SGML

I am aware that SGML is the ancestor of HTML and XML. I'm not sure there are any popular software today that handle SGML syntax. Furthermore XML has fewer rules to remember than SGML. So I will largely ignore SGML, except for explaining why some behaviors went into HTML.

> The hard-coded tag soup parser is by no means "standard".

I believe HTML5 standardized the syntax/error handling for HTML (not XHTML) documents. It should mean that for any given document, every HTML5-compliant web browser - Chrome, Firefox, Edge, etc. - will parse it into the same DOM tree.

> Does every popular browser support [XHTML] in the same way?

Yes, XHTML mode is supported by IE 9+, all Firefox, all Chrome, all Safari, all Opera, and all mobile browsers on Android and iOS. https://caniuse.com/#feat=xhtml

> I would expect some subtle differences, because this mode is not very popular and probably not as tested as standard HTML.

Indeed XHTML is very unpopular. There was one slight bug I encountered in Firefox about a year ago, where invalid XHTML pages would show a yellow error screen (correct) but with no error message text (this was a regression). That said, I'm pretty sure that the XML-parsing engine, XSLT, and related technologies are here to stay, so XHTML isn't at risk of losing support.

> On the contrary, part of the point of XHTML is you can reference the document type definition (DTD) so everyone would be on the same page.

That was the original intent in XHTML 1.0, 1.1, and 2.0. But anyway, nowadays the DTD is optional and probably unhelpful: https://stackoverflow.com/questions/38427011/does-xhtml5-req...

>> The standard "tag soup" HTML parser has numerous surprising behaviors

> There is nothing surprising here.

So are you an expert at diagnosing HTML parsing and invalid syntax? I prefer not to be one, because I'd like the XML parser to yell at me loudly when I'm wrong, rather than helpfully try to fix my code the wrong way.

> if you dig deeper there are a lot more surprises in XHTML documents

Like what? I'll try to name a few: Namespaces (colons), character entities, CDATA sections, strict comments (rules about the substring "--").

> assuming they are served with the proper MIME type

Yes, I forgot to mention this. My website https://www.nayuki.io/ has been serving application/xhtml+xml for about a decade, and seems to work well with the browsers that the audience uses.

> The second reason is you may want the data you are creating to be still accessible in the future

I wish developers in the front-end ecosystem would hold longevity in higher regard when innovating. When identifying a shortcoming in the web platform, help improve it rather than inventing another framework silo - while throwing out so much hard work that has gone into things like accessibility, separation of logic from content, and more.

Improving HTML just isn't a possibility as a developer.

When you develop an app, it's for now and not for 10 years into the future when it has finally been standardized, reviewed, accepted and implemented in all browsers as well as having all the older, non-compatible versions disappear.

We're 25 years into HTML and applying form validation only after an initial input (so as to not display a form filled with red input fields) still isn't a thing.

Hell, even regular form validation still is only applied on form submission and lots of browser versions still aren't compatible.

That's after 25 years of <form> tag existence.

So no, every time somebody talks about the complexity of frontend development and how everybody should stop using JavaScript and use pure CSS and HTML, they forget that the technologies are hot garbage that evolves at the pace of snail.

ECMAScript is part of the web platform. I wasn't making that strong of a statement. More specifically, I am saying we should build things to last and not throw out substantial work, such as standardization and accessibility, in the name of "modernity" (or similar buzzwords like "scalability".)

https://stackoverflow.com/questions/7920742/delay-html5-inva... doesn’t show the red until you enter text.

This solution sadly doesn't work for form elements without placeholders like <select>, checkboxes, radio buttons, date & number pickers, etc.

And checkboxes can still not be styled. But that's another one of the multiple problems in HTML and forms in particular ...

Longevity of technology simply isn't a concern in a ecosystem where everything else is moving at such a rapid pace.

this was written before chrome, firefox, ajax, safari, node, most banner ads and a boatload of breaking changes to css

as far as we know, nothing on the web is future-proof -- I suspect if the goal is to serve archeaologists, we don't know what will really be usable in the long term.

I think video game emulators are an interesting success story in this space. Short of that, acid-free paper or stone also last quite well when stored correctly.

Node is just a backend language. The HTML you write in node in 2020 can be targeted for 1997, and if you have a server from 1997 running ASP 2.0 it can target browsers working in 2020. You get to craft the output.

Chrome/Firefox/Safari all do a pretty good job of rendering HTML consistently - we've come a lot further than where we were in 1997, when websites commonly had "Made for Netscape" or "Made for IE" graphics on them.

Fun fact: AJAX came from an extension to the browser from Microsoft (first written for Outlook web client). For all the talk about standards and open source, I find it ironic that what is possibly the most defining feature of today's web came from what at time was the greatest force against standards and open source.

Microsoft was also first to the table with DHTML, or what we now call DOM manipulation.

The combination of DOM manipulation and asynchronous HTTP was like crack for developers, and resulted in an explosion of IE only business apps, which caused IT departments to become IE-only, which led to a feedback effect.

All the crappy IE-only back-end systems that still fester in enterprises today hark back to those days.

I'm pretty sure that archeologists are happy about any human readable format, and don't worry too much about browser support.

it depends on how far forward they are (like have they forgotten the language they're interpreting)

the rosetta stone is useful because it's a concordance

in that light, there could be value in structured databases that make clear semantic links between words, or which link words to images

If we're talking that far ahead -- our storage media won't last that long.

one of the difficult things is extracting and reusing data inside of html documents. So after you've written the html file it's done, you can't reuse it in a different page, no api nothing. let's day you want to reorder / filter a list it's impossible

With Hugo this is no problem and still can be standard HTML.

What?

OK. You have a mere CSV file with data. What you're stating about HTML is true for the CSV file - _on it's own_.

HTML is nothing more, than a data structure, and fairly good one.

Not only that, but their assertion isn't even true. It's as if there's an HTML renderer that doesn't support iframes, template tags, or JavaScript...

Some might say the latter is cheating, but HTML isn't a programming language.

Could you expand on what you mean by this?

I don't know if this is a case you had in mind, but I'm increasingly frustrated with the inflexibility of table-based data in HTML.

With JS support, it's possible to create dynamic tables -- sortable, searchable, filterable, summarisable (sum, mean, count, etc.). But none of that is available in stock HTML + browser. It would be quite useful.

Similar features might be envisioned for ordered or unordered lists.

As would be the ability to simply extract content from HTML tables. There are some tools offered for this, but relatively few, and largely arcane, especially for nontechnical users.

> PNG (an improvement on GIF) is becoming acceptable.

And two decades later it is still a second class citizen :-/

Compared to what? It is supported in every major browser as far as I know.

For still images PNG replaced GIF, but both MNG and APNG suffered from missing browser support for most of their life (particularly from Chrome), leaving GIF as the only viable format for silent moving pictures (until the rise of webp).

Maybe it's the ffmpeg apng muxer but it almost seems like gif does a better job a compression compared to apng, making apng only solve one problem (AFAIK): the color limitations. See this example: https://gist.github.com/judge2020/a78adb07ae60244a5660fb631f...

PNG has two (commonly used modes): 256 colors or true color. A 256 color PNG beats a GIF in compression, but for many images a 2^32 color PNG takes more space than a 256 color GIF. This holds true both for still images and animations.

This leads to a curious situation where PNG beats GIF at anything GIF can do, yet still disappoints people.

Compared to JPEG. Sure the browser support is good nowadays, but there are still so many tools that create JPEG files by default, even when PNG files would be a better choice (e.g. Screenshots, computer generated graphics, etc.).

Reply on news.ycombinator.com