It's great until you have a typo in the field, or want to show options that don't start with what you typed in but appear near the end of an option (think Google search's autocomplete). There's no way to filter in Javascript and force it to show certain options with <datalist>. I've resorted to <ol> for search suggestions.
Some of these new HTML features don't fully work in my "ancient" browser. But all of them partially work (ie opening the accordion element doesn't close others but it still opens and closes) and they still remain functional elements I can read and interact with. This puts them far ahead of any javascript implementation which almost universally fail to nothing.
The details / summary thing absolutely kills me. There’s basically nothing you can’t do with them. Hiding and replacing markers is easy. But every component library just pretends they don’t exist.
It even saves you the effort of all the aria control and expanded tags: these tags don’t need them.
The details / summary feature can also be implemented with pure css without JavaScript. Here is an example: https://docs.go101.org/std/pkg/io.html, just click all "+" signs to expand contents.
Something I keep thinking about when I consider the trade-offs between building a site with HTML/CSS wherever possible vs JS is what the actual _experience_ of writing and maintaining HTML/CSS is vs JS. JS gets knocked around a bunch compared to "real" languages (although less so in recent years), but at the end of the day, it's a programming language. You can write a loop in it.
Writing a web server in C++ is a way to get excellent performance. So why don't most people do it?
One thing I am quite hopeful for is customizable selects! It's in WHATWG stage 3 right now. I have seen so many horrors with javascript-based custom dropdowns components. https://developer.chrome.com/blog/a-customizable-select
The problem is that it's difficukt to style or animate those things. Unless you're builsing something for dun or technical where it's not important it's fine but i doubt any real world commercial project would be satisfied with just this
HTML and JavaScript serve distinct purposes, making better or worse comparisons logically flawed. Complex/interactive web apps requires JavaScript, period. Attempting to build sophisticated apps solely through HTML (looking at you HTMLX) eventually hits a functional ceiling.
A pleasant surprise to see Aaron's post here, we worked together for a bit on frontend optimization in a multi-tenant international ecommerce platform. That work was a large part of my inspiration for building https://contentblocksjs.com which encapsulated a lot of the JS concerns into web components.
I didn't know about <datalist>, but how are you supposed to use it with a non-trivial amount of items in the list? I don't see how this can be a replacement for javascript/XHR based autocomplete.
I'm so not impressed by the toggle implementation... How nice it could have been.
Nesting the elements is a truly hideous choice. The summary is part of the details?? I thought they were opposites.
Should we also put the headings in the <p> from now on?
Identifying a target should be done by id or by name. That it does use a name because js can't target it without makes it even more stupid.
We already had labels for form fields. Inventing a completely different method for something very similar is a dumb idea. The old checkbox hack is more flexible and less ugly for some implementations.
Why force the hidden content to be below or above the toggle? We aren't gaining anything with this.
What is this nonsense for an element to not just be hidden or displayed but to have some weird 3rd state where only one of its children is shown?
How should styling it even work for this new state? If I apply a style to the hidden content it must also apply to the link? The text is hidden but the style is visible??? Preposterous!
Don't try style <details> to avoid unexpected behavior. Try wrapping the hidden content in a new element to make it behave normally.
What is this ugly arrow? If you find 1000 websites using a toggle I doubt there is one using an ugly arrow like that.
The default styling gives no clue about it being clickable?
The pointer (awkwardly called the cursor) choice is the text selection?????
Blue underlined "more" is what everyone does and everyone is used to. The cursor should be pointer. (This is css speak for "the pointer should be a hand")
The number of js toggles you can find online where the button lives inside the hidden text is guaranteed to be zero. Forget about drop in replacement, you will have to reinvent your css.
Maybe I'm dense but I also want my url to reflect the state of the page. I would have been impressed if that was supported. Personally I use actual links and disable default action in the listener if js is enabled/working or modify the state on the server if js isn't available/working.
It would have been great if the toggle action was implemented as a simple attribute something like toggle="element name" so that anything can be clickable and anything can be toggleable. Have a "closed" as well as an "open" attribute for the target.
Doesn't seem very hard. An open/closed attribute would be useful for other things too. Using display:none is terrible as display: is used for many things.
"I also want my url to reflect the state of the page... It would have been great if the toggle action was implemented as a simple attribute something like toggle='element name'"
Your wishlist (state in attributes, URLs reflecting page state, anything being toggleable via simple attributes) is basically describing an architecture I've been working on called DATAOS (DOM As The Authority On State).
The core idea: instead of JS owning state and syncing to DOM, flip it. State lives in HTML attributes. JS just listens for changes and reacts. Want toggle state in the URL? The DOM attribute is the state, so serializing to URL is trivial.
It won't fix <details> being weirdly designed, but it's a pattern for building the kind of declarative, attribute-driven interactivity you're describing.
Your blogs have very small amount solution, but the JS use cases are very large. How this little replacement can do more thing? I usually like the idea of being using as lean as possible, if it's can be possible to do more thing just with HTML and CSS that's obviously cool. Is it really possible to replace JS with HTML in near future?
BTW the toggle solution (expanding content) is good.
Most of this is great, except for the input/datalist bits, which are not sufficiently functional to be used in any real scenario. Users expect these interfaces to be tolerant of misspellings, optional sub text under each option, mobile ux niceties, etc -- and so everyone builds this with js...
Try on a phone, it doesn’t work. Now that’s you create html only and no js you need to test all kind of devices to see quirks and try to fix it. And you’ll end up with more hacks to fix other devices and you end up adding Js. And you’ll have html only and html with js. With is much worse that just properly do it in js.
I can see the op is a js hater even tho he keep saying he’s not. Anyway doesn’t matter. Just a small note.
Also datalist is nice but most the time we need a “select” (so users can’t submit anything not in the list), but select doesn’t have search/filtering like datalist has.
So much about html only that makes me load 2mb of code pen and heavy ui to see the example. Yeah it’s terrible ux. same as most of the examples are bad
I don't see any mention of HTTP 204 or multipart/x-mixed-replace. Those are both very helpful for implementing rich JavaScript-free HTML applications with advanced interactivity.
I was trying to rewrite some UI library with html sometime ago following the W3C accessibility specs and found out a lot of patterns can’t be done with pure html and require javascript unfortunately.
Plain HTML is very cozy to me - I came of age in that era. Marquee tags 4eva.
But as much as I hate to admit it, it is very difficult to build something functional today with plain HTML and no/minimal JS. If you want, say, a model form that manages its children as well, you're basically going to end up with a 2003-era ASP-feeling application with way too many views and forms (as seen on your employer's current HR system). Or you use HTMX... and you still end up with just as many (partial) views, but now with so much implicit state that you're veering into write-only code.
I dislike modern JS to the extent that I opted for Phoenix LiveView, just so I could achieve interactivity without ever having to touch JS, but in truth it's not a comprehensive solution. Still had to write a web worker, a bridge to handle things like notifications, etc. Plus the future direction of Phoenix, all in on AI, is worrying.
Honestly, I should probably just swallow my disdain and learn to appreciate and use modern JS, as painful as that sounds. I want to write and release cool things, not get caught up in navel-gazing language wars.
I miss marquee... I burned more tokens than I'd like to admit to build a marquee-like feature in react and it was really just the same text twice with an animation that hopefully no one notices isn't a clean loop on some viewport sizes (since it restarts after reaching the end).
66 comments
[ 0.21 ms ] story [ 76.6 ms ] threadIt's great until you have a typo in the field, or want to show options that don't start with what you typed in but appear near the end of an option (think Google search's autocomplete). There's no way to filter in Javascript and force it to show certain options with <datalist>. I've resorted to <ol> for search suggestions.
It's good to know these things exist so there are alternatives to reaching for a fat react component as the first step.
It even saves you the effort of all the aria control and expanded tags: these tags don’t need them.
We can also use pure css to implement tab panels. A demo: http://tmd.tapirgames.com/demos.html#section-demo-4
Modern css is powerful.
Writing a web server in C++ is a way to get excellent performance. So why don't most people do it?
Nesting the elements is a truly hideous choice. The summary is part of the details?? I thought they were opposites.
Should we also put the headings in the <p> from now on?
Identifying a target should be done by id or by name. That it does use a name because js can't target it without makes it even more stupid.
We already had labels for form fields. Inventing a completely different method for something very similar is a dumb idea. The old checkbox hack is more flexible and less ugly for some implementations.
Why force the hidden content to be below or above the toggle? We aren't gaining anything with this.
What is this nonsense for an element to not just be hidden or displayed but to have some weird 3rd state where only one of its children is shown?
How should styling it even work for this new state? If I apply a style to the hidden content it must also apply to the link? The text is hidden but the style is visible??? Preposterous!
Don't try style <details> to avoid unexpected behavior. Try wrapping the hidden content in a new element to make it behave normally.
What is this ugly arrow? If you find 1000 websites using a toggle I doubt there is one using an ugly arrow like that.
The default styling gives no clue about it being clickable?
The pointer (awkwardly called the cursor) choice is the text selection?????
Blue underlined "more" is what everyone does and everyone is used to. The cursor should be pointer. (This is css speak for "the pointer should be a hand")
The number of js toggles you can find online where the button lives inside the hidden text is guaranteed to be zero. Forget about drop in replacement, you will have to reinvent your css.
Maybe I'm dense but I also want my url to reflect the state of the page. I would have been impressed if that was supported. Personally I use actual links and disable default action in the listener if js is enabled/working or modify the state on the server if js isn't available/working.
It would have been great if the toggle action was implemented as a simple attribute something like toggle="element name" so that anything can be clickable and anything can be toggleable. Have a "closed" as well as an "open" attribute for the target.
Doesn't seem very hard. An open/closed attribute would be useful for other things too. Using display:none is terrible as display: is used for many things.
Your wishlist (state in attributes, URLs reflecting page state, anything being toggleable via simple attributes) is basically describing an architecture I've been working on called DATAOS (DOM As The Authority On State).
The core idea: instead of JS owning state and syncing to DOM, flip it. State lives in HTML attributes. JS just listens for changes and reacts. Want toggle state in the URL? The DOM attribute is the state, so serializing to URL is trivial.
It won't fix <details> being weirdly designed, but it's a pattern for building the kind of declarative, attribute-driven interactivity you're describing.
Free book and open source libraries if you are curious: https://dataos.software/book
BTW the toggle solution (expanding content) is good.
I can see the op is a js hater even tho he keep saying he’s not. Anyway doesn’t matter. Just a small note.
Like I get this is a blog system but it still feels odd, especially for a "use this plain HTML"-style post...
But as much as I hate to admit it, it is very difficult to build something functional today with plain HTML and no/minimal JS. If you want, say, a model form that manages its children as well, you're basically going to end up with a 2003-era ASP-feeling application with way too many views and forms (as seen on your employer's current HR system). Or you use HTMX... and you still end up with just as many (partial) views, but now with so much implicit state that you're veering into write-only code.
I dislike modern JS to the extent that I opted for Phoenix LiveView, just so I could achieve interactivity without ever having to touch JS, but in truth it's not a comprehensive solution. Still had to write a web worker, a bridge to handle things like notifications, etc. Plus the future direction of Phoenix, all in on AI, is worrying.
Honestly, I should probably just swallow my disdain and learn to appreciate and use modern JS, as painful as that sounds. I want to write and release cool things, not get caught up in navel-gazing language wars.
Its so easy, like a breeze!