
Using Standard HTML (1997) - dredmorbius
https://www.w3.org/Provider/Style/Standards.html
======
nayuki
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).

~~~
JoshTriplett
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.

~~~
firefoxd
Yes you can.

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

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

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

~~~
detaro
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...](https://html.spec.whatwg.org/multipage/syntax.html#start-tags)

> _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...](https://html.spec.whatwg.org/multipage/syntax.html#void-elements)

> _area, base, br, col, embed, hr, img, input, link, meta, param, source,
> track, wbr_

------
brylie
> 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.

~~~
LunaSea
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.

~~~
earthboundkid
[https://stackoverflow.com/questions/7920742/delay-
html5-inva...](https://stackoverflow.com/questions/7920742/delay-
html5-invalid-pseudo-class-until-the-first-event/48144022#48144022) doesn’t
show the red until you enter text.

~~~
LunaSea
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 ...

------
awinter-py
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.

~~~
bdcravens
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.

~~~
mr_toad
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.

------
serverQuestion
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

~~~
pmlnr
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.

~~~
ravenstine
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.

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

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

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

~~~
wongarsu
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).

~~~
judge2020
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...](https://gist.github.com/judge2020/a78adb07ae60244a5660fb631f389c02)

~~~
wongarsu
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.

