Live data from Hacker News

A Blog Post with Every HTML Element

patrickweaver.net

1–10 of 88 posts

Re: A Blog Post with Every HTML Element

#2
How fortunate, I was looking for something like this today for a side project. HTML can do so much already, I'd rather lean into it than use one of the bloated frameworks/libraries out there.

Really helpful to see it all in one place!

Re: A Blog Post with Every HTML Element

#6
Most of these aren't widely used because they were quaint attempts at solving problems that no longer exist, could be better solved with CSS (as the author concedes with ), and very much depend on browser implementation.

I was excited when and landed in all evergreen browsers for example, but just to get the content to slide open (guiding the user) instead of pop open requires JS (the best implementations I've seen use WAAPI), Safari adds a proprietary pseudo element, etc.

Re: A Blog Post with Every HTML Element

#7
> Some of deprecated elements won’t render without some extra work, for example and are designed to be used instead of a , for I guess some kind of collage web page made up of other pages.

The author is too young to remember frames, huh? :) I'd just link the Wikipedia article ( https://en.wikipedia.org/wiki/Frame_(World_Wide_Web) ), but I feel like it doesn't explain it very well.

So, to briefly explain -- in the early web (OK, not the really early web, but once it got popular) frames were very common. They were commonly used for menus/sidebars, as well as things like headers that were meant to stay visible. So perhaps a page would have three frames -- a frame up top with a persistent header, one on the left with a sidebar, and then one main frame with the content.

Each frame acted fairly independently, with e.g. its own back/forward history (a link in a frame would by default only affect that frame, although you could have links in one frame open in another, useful for implementing a sidebar). This meant using back/forward/reload/etc with frames could be pretty troublesome and unintuitive. If you somehow got a page into a messed-up state where the wrong thing was loaded in one frame, it could be hard to get out of this state other than by navigating to the page from the start. Or it could be troublesome if you accidentally loaded just the content page without the framing page it was supposed to be a part of.

CSS got rid of most of the use case for frames, which is good, because frames were a real pain to deal with as a user!

Re: A Blog Post with Every HTML Element

#8
post #2

How fortunate, I was looking for something like this today for a side project. HTML can do so much already, I'd rather lean into it than use one of the bloated frameworks/libraries out there. Really helpful to see it all in one place!

Have you tried htmx?

htmx isnt meant to solve frontend element problems, it's for more easily communicating with a backend.

Re: A Blog Post with Every HTML Element

#10
This comes up briefly but I do still find it ridiculous that there's no simple standard CSS declaration to hide something from visible display but keep it for screenreaders.

Everything I've seen still does clip, or positions the content off the side of the page, or something like that. How is this not just an alternative "display" value, or an additional property?

There's been a "speak" property floating around in one of those theoretical CSS modules that would accomplish this but as far as I know it has zero uptake among implementers.

Post reply on HN