Those HTML attributes you never use

> requires incredible pecking accuracy on mobile, non-hummingbirds cannot use

At least that part is easily solved: Assign a label to the checkbox, label is tap-able. nice large target.

Styling it to look like a native toggle control is harder.

If a checkbox isn't a toggle, what then by you is a toggle?

In my uses, I can be almost certain that I won't get a 404 back as a response, unless I forgot to do something - although the others are a concern. Even though Netlify allows setting headers and redirects, I obviously don't control the image they use or the CDN generally.

Something to watch out for.

I've had to do something like that for an awful application where the frontend did chunked downloads, but didn't check properly for the status code, embedding error pages directly in the downloaded file.

As I had no control over the frontend itself, I configured the reverse proxy so that for requests to download endpoints, all error responses would instantly close the connection to the client.

Your post makes me think that I could generalize this so that any error to an explicit download would close the connection at the network level. It would be quite tricky to be able to distinguish between implicit and explicit downloads, but I think that if the frontend, backend and reverse proxy coordinate well together, it can be done without introducing other problems.

Of course, it's a big hack that's not worth the bother.

Ok, it works for me but only if I dismiss the keyboard in between fields.

https://owo.whats-th.is/D4Vf7g6.mp4

Stock Android keyboard. Doesn't work if I dismiss either, as sibling comment states.

SE Editor-in-Chief here. We include <i> within <cite> because 1) reading systems often have different default CSS which may not even recognize <cite> and 2) <cite> often contains both a title and an author, and in those cases we want only one or the other to be italicized. SE's default CSS for epigraphs (probably the most common place where <cite> is found) is to give <cite> small caps, italicize the title if there is one, but don't italicize the author.

I believe our use of <cite> predates the modern definition of its use, and in any case it's so infrequently found in a web context that I don't think there's much agreement about how it should be used anyway. (For example MDN says the work title must be in <cite>, but at SE we often only include an author name, like <cite>--Shakespeare</cite>.)

While the semantic web mindset (especially the "Xanadu" inspired subsets) thought cite should always be a URL, it didn't technically have to be per the spec. (Without browser behavior backing it as a URL, it certainly didn't have any enforcement to be a URL.) In my case I think I was using it for author annotations in a more "APA or Chicago Style Manual" style at the time I had CSS like that in the style of: —Author Name from "Book/Webpage Title"

Not selectable is still a bit annoying in that case, but Author Names don't need to be clickable links and the point comes across.

You got me, I actually searched for evidence that the <blink> element supported a `speed` attribute.

The MDN page about <blink> has example CSS to make the element blink again. If you wanted to make speed variants, you could use CSS selectors that set different durations based on a data attribute and its value:

  blink {
    animation: 2s linear infinite condemned_blink_effect;
  }

  blink[data-speed: fast] { animation-duration: 1s }
  blink[data-speed: slow] { animation-duration: 4s }

It keeps style instructions together instead of mingling them with data and behaviour attributes. There's some exceptions with some elements having attributes like width and border but it's mostly historical.

Neither is necessarily "better", but rather they are different design choices. HTML at first wasn't intended to have very much styling at all, and originally there was some more styling mixed into the HTML itself (like <font>, bgcolor, etc.). Since now we pretty much want to make our webpages look like anything, it seemed to make sense to those drafting the standards to separate the two concerns, since HTML is mostly about page flow structure and data display, and page sources would be even harder to read than they already are if everyone was just putting their styles within HTML tags. If you're looking for a data attribute, it can be hard on the eyes to be constantly sifting through attributes for styling.

You certainly can do things to overload attributes and do what you're suggesting (in a sort of hackish way), and you wouldn't necessarily be wrong in doing so if that's your preference. Many people just don't like that.

One of the great things about separating styles out of HTML is that they can be contained in files and included separately. With poor connectivity, ideally, it's beneficial to keep the main page source to be as slim as possible so that it can still be downloaded and read even if the styling hasn't yet finished downloading. That's not nearly as relevant anymore, but it would not be surprising if keeping pages lean was a motivator in moving away from putting more stuff in HTML.

You do remember the hell that was the font tag, don’t you?

I think a lot of confusion from HTML being used for UIs vs hypertext documents. It’s a natural evolved mess still balancing the two.

But style should apply to the applied representation, while HTML should represent the intent of the content. The line is fuzzy, and HTML/CSS has a bad history of what falls where.

The cool thing with browsers is that we can bake in style to support multiple representations at once: monitor, mobile, printer, etc. Using the style attribute directly is mostly a side effect of only targeting the browser. Although your example of relative units is more ambiguous. Using a proper tag to represent the intent or falling back to a class where HTML lacks one would be preferable.

I think the separation makes more sense if you’ve used other document systems. SGML or XML DocBook, LaTeX, ROFF, etc.

For the last, if I use the man or mandoc module, all the man page norms are there for me and I’m just plugging in the content with the right macros.

W/o, I’m manually flipping registers all over the place.

But I’ve never hear of a roff or LaTeX UI, so…

Contrary to popular belief, HTML and CSS are unrelated.

If any CSS property was also an HTML attribute, any addition to either spec would have to make sure it wouldn’t conflict. One example is the `content` HTML attribute and CSS property. They serve different purposes and have a completely different syntax.

    <meta name="description" content="Cool stuff”>

and

    .css::before {
        content: url(image.bmp)
    }