A missed opportunity to not have all of these examples inline. The page/blog-post would be so much more convincing if it utilized all of these HTML replacements instead (or in addition) to linking to codepen.
Absolutely mind boggling. I've seen it many times before. There's some FooMaker v1.0 announced and you click on it thinking it will allow to easily make Foo and the example is how to disable FooMaker's lights l while AC is running or some other obscure edge case that affects like one in a million people, no examples how to actually use it for most common use case or how the result look like.
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.
One drawback of details was that cmd+f search wouldn't play nicely when the details was closed. But now there's a hidden="until-found" you can put on child content, along with an associated event. So you can open the details when a user searches :) super useful
You don't need the hidden="until-found" for details/summary, because that has those semantics automatically, but you can use that for other elements that behave similarly (for example tabs, which can't quite correctly be implemented with details/summary, and so needs to be done by hand).
Also I think the event isn't currently emitted consistently on all browsers (and maybe not at all for hidden="until-found"?) so unfortunately you can't quite rely on that yet if you need to sink some JavaScript state to your html. But in general, yeah, this is a really cool feature.
Yeah, support was patchy until recently (and I think that behaviour might not even have been standardised?) so I think a lot of people have assumed that if you want that functionality you need to do something extra.
Yes, Google started revealing the contents of <details> a few years ago, long after the element was supported in all browsers. Firefox added support earlier this year and Safari just added it.
Supporting the behavior was related to changing the user agent CSS when they're closed and the other browsers implemented it and hidden=until-found at the same time.
That is no longer true! You can do it in CSS with a combination of `@starting-style` and `transition-behavior: allow-discrete`. [1]
Another gotcha you'll run into is animating the height. A couple other new features (`interpolate-size: allow-keywords` and `::details-content`) will let you get around that. [2]
The major issue with this is that modern CSS is almost its own job, to the point we used to have Interface Developers at some place I’ve worked (HTML+CSS specialists). I did frontend for over a decade and eventually lost the train on CSS changes, I don’t even know what’s going on there anymore.
It’s still awesome, but it’s becoming increasingly silly to ask someone to know modern HTML, CSS, JavaScript, Typescript, some build tools, a couple of frameworks, etc.
The amount of JS we ship to clients is a reflection of cost-cutting measures at your workplace, not that every FE dev shuns CSS.
When I started dabbling in web development, writing HTML and CSS was already its own job, and professional JavaScript developers basically did not exist. This was before TypeScript, before Node, before Ajax, before React or even jQuery. If anything has exploded in complexity in the intervening years, it's the JavaScript part of the equation.
I agree that it's increasingly silly to ask someone to be an expert in all of frontend. But the primary driver of that is not all the new CSS features we're getting.
These are fair points. And developers themselves thought “hey, what if I also write Node?”, thus making things worse. Businesses accepted that all too willingly.
<sarcasm>I'm an expert -> just write everything in static html, use css only where defaults are neglected. After relevant tables in the db are updated generate a new static document. Only if that won't fly use json but feel appropriately dirty when you do.
Agreed. Having a "HTML + CSS" engineer on the team was largely due to the number of hacks needed to make css work -- purposely adding invalid html that would only be parsed by specific browsers, ie5 vs ie6 vs netscape being wildly different (opera mobile was out of this world different), using sprites everywhere because additional images would have a noticeable lag time (especially with javascript hover), clearfix divs to overcome float issues. To be clear, I'm not saying "things were harder back then" or "css is simple now", but things with CSS were so wild and the tooling was so bad, that it what a unique skill of it's own that is less needed now, and the shift has been for people to focus on going deeper with js.
Because you need 20x the JS to do the same thing and it’s still not hardware accelerated. These new CSS properties are well supported and will only get better.
Is that "straight-forward easy to understand and follow JavaScript" the whole thing written from scratch? Or does it use libraries (that use libraries, that use libraries)?
Because I've written my share of javascript-from-scratch in my time - before npm and such. And even if my use-case was limited, in order to get edge-cases and details working - issues long solved by their HTML/CSS counterparts - we needed more and more JS. Many of which handwritten polyfills, agent-detection, etc.
Seriously, things like scrollbars (because the client insisted on them being consistent across user-agents) or dropdowns (because they had to be styled) "visited" state on links, in pure JS are thousands of lines of code.
Maybe not today, anymore, IDK, with current APIs like the history API or aria labeling. But back then, just in order to make the dropdown work with screen readers, or the scrollbars react well to touchpads -in the direction the user was used to based on their OS- took us thousands of lines of JS, hacks, workarounds and very hard to follow code - because of the way the "solutions" were spread out over the exact right combination of JS, HTML and CSS. Edit: I now recall we got the web-app back with the comment "When I select "Language" and start typing "Fr" I expect French to be picked and "enter" to then put the language in French". We spent another few days on functions that collect character inputs in memory and then match them with values. All because "flags in front of the names were of crucial importance".
So, maybe this is solved in modern HTML/CSS/JS. But I highly doubt it. I think "some straight-forward ... JavaScript" is either an `import { foo } from foobar` or a pipe-dream in the area of "programmers always underestimate hours"
Certainly. But the problem here wasn't "we want flags", but that the client (via the designer) demanded something that couldn't fit in a select box and so we had to build our own.
Now, I think part of the problem is that such elements weren't architectured properly when invented. Like many other HTML elements, they should've had some way to style and/or improve them.
E.g. an H1 Header, I can apply CSS to and change it from the default to something matching the business style. I can add some behaviour to it, so I can bookmark it's id anchor. I can add some behaviour to turn the H1-6 into a nice table-of-contents. Or an image can be improved with some CSS and JS to load progressively. But most form elements, and the dropdown in particular, is hard to improve.
And, yes, I am aware of the can of worms if "any element is allowed inside an <option>". Or the misuse designers will do if we can add CSS to certain <options> or their contents. Though I don't think "webdevs will abuse" was ever the reason not to hand power to them. It was mostly a disconnect between the "designers of the specs" and the "designers/builders of websites".
Because that "abuse" is never worse than what is still done en-masse: where we simply replace the "select" with hundreds of lines of CSS, divsoup, and hundreds or thousands of lines of JS. Where entire component libraries exist and used all over the place, that completely replicate the behaviour of existing (form) elements but with divs/spans, css and js. And despite the thousands of hours of finetuning, still get details wrong in the area of a11y, on mobile platforms, on obscure platforms, with a plugin, with a slow connection and so on.
Because a team of browser engineers have already written and reviewed the code to do it for you; and (hopefully) it’ll be performant, properly tested and accessible… ;-D
JS animations run on the main thread with everything else, so if your browser is busy doing something else the animation ends up being janky. Using CSS solves that problem.
We've gotten so far away from semantic documents so we could build "apps".
Data used to be first class. You would deliver everything in the HTML container and the style sheets or client could do whatever it wanted/needed with that data.
Native search, native copy, no clever javascript tricks to hide or remove information from the document.
> We've gotten so far away from semantic documents so we could build "apps".
Exactly. We're still pretending that the browser is some kind of document display application when it's an application runtime. We keep adding more HTML tags and infinite number of CSS properties and features (that never get it right) when what we should have as a better application GUI API. Throw all the hardware acceleration and threading into that instead of @starting-style, transition-behavior: allow-discrete, interpolate-size: allow-keywords and ::details-content and breath some sanity into the platform.
We've effectively re-implemented that desktop/mobile GUI using a bunch of cobbled together technologies and continue to get more esoteric and complicated every year. Hell, I'm not even sold on JavaScript -- it's just as clunky and weird as everything else.
Move document rendering into high-level implementation on top of a better designed low-level API much like how PDF display in browsers is done with JavaScript.
In my opinion the problem is the lack of good GUI editing apps for purely HTML documents and no standard for self-contained HTML docs (that would bundle all the ressources into a single clickable file).
Word for the web basically, but with support for multimedia.
In that sense the web has failed, there is epub but it's not really good.
As a developer, I want a sane platform. Sometimes I want to write documents and sometimes I want to write applications.
> This is sane from a declarative document styling syntax.
Is it? CSS intentionally avoided mixing animation with live layout resolution and now we have a "switch" to enable it. I wouldn't call that elegant.
If we could just hook into layout with code this could have been resolved years ago instead of waiting for browser makers to invent yet another set keywords.
To be fair, that's on the user. It's a trade-off the user is making, knowing that there's poorly made sites out there and sites that actively depend on JavaScript to function (sometimes because JavaScript is the only way they can function, but usually because someone's never heard of progressive enhancement). In the past, turning off JavaScript was a functional way to prevent things from running and to make sites load faster; today ads and progressive enhancement and optional functionality are hardly the only usage of JavaScript: lazy loading variable-size content (via fragments or otherwise) causes scroll issues if you're trying to go for performance on a complex layout. CSS containment and content-visibility with contain-intrinsic-size help solve this, but they're pretty new.
I agree, but must also observe that I have never met a designer who was willing to admit without a knock-down drag-out fight that any animation they put in was not somehow crucial.
I've never met a designer who wasn't completely fine with my suggestions for more pragmatic solutions. Like just styling a default scrollbar instead of implementing my own scrollbar to make it exactly like the design. Using a default drop-down menu instead of rolling my own just so I can round the corners of the selects.
The designers I've worked with are fine with these things. We have more important things to work on than small style details. We can go back and change these things later if anyone actually cares, but generally nobody ever does.
I've never met a designer who cares how it gets done but I have hard time believing they were OK with the corners not being rounded as per the design. They may agree on shipping without the rounded corner, as long as the ticket to round that corner is registered.
I suppose though that we have just had very different life experiences, as that is what the HN guidelines would require of us.
I have also met a lot of completely unreasonable designers that would insist on the most minimal things (even to the detriment of usability), and would act like assholes towards developers.
I have also had situations where developers would beg to work with a certain designer because their experience made development a breeze, even for complex layouts. Funny enough, the projects where this designer worked would always get done, and the visual result was always great.
It depends on what you're doing. It's common for clients to wonder why the design they saw had fancy animations yet they don't see them on their MacBook...
You're doing it wrong. You don't have to remember the incantations. You just have to remember that they exist, and then google them or ask an LLM when you need them.
If you use something enough you'll remember. If you don't, you just look it up when you need it. This is basic programming, nobody remembers everything.
Seriously. As a user I can count on zero hands the number of times I’ve said “Oh great, I’m sure glad this UI is animated!” - and likewise zero times have I missed it when animation isn’t used. Animation is a way to light small units of your users’ precious time on fire, for zero benefit.
As the other user alluded to, Animations are not actually there for people who are comfortable using a computer. The vast majority of users are borderlines in capable of using the internet these days. Animations are supposed to be there to really help guide these users into understanding what the scary machine is doing when they click it. Can they be overused, absolutely, but i think have an accordion fold out animated is a reasonable case. You gotta remember your average user isnt paying any fucking attention, so drawing their attention to important changes on screen is not only good but necessary. I'd prefer no animations ever, but i also dont own an iphone while the majority of the world either does or wants to.
That's the positive interpretation, but none of the discussions I've had with UI designers or managers have been about adding animation for accessibility, and the zeitgeist of the last decade has been that skeuomorphism (of which intuitive animations are a subset) is passé.
So far as I can tell, all that the stakeholders want from the UI, animations included, is pizzazz.
If it is for those people who barely grasp the slightest thing about what’s going on on-screen, I could grant them that, if they’d let me turn it off. In the days before jailbreak became basically impossible, setting the animation duration to zero was a blessed, incredibly satisfying thing. It’s exactly what I want. Just do the transition in zero seconds.
My iPhone 15 can’t even catch my first 1-2 keystrokes on the keyboard, multiple times a day, but boy howdy does it have the time and the cycles to animate that f*%ker into view. The disrespect for my time and my needs is so obvious.
Animations are also a way to explain causal relationships between interactions and their results, and to help build mental models of software behaviour.
Being related to neither software behavior nor the structure of the underlying problem, animations tend to obscure the causal relationships and make it harder for user to build a correct mental model.
I see where you're coming from: animations are overused and even when they make sense they are made too slow and flashy (because otherwise how would the implementors feel like they did something if it's barely noticeable?)
Animations are like bass in music: most people notice them only when they're missing or bad.
> Animating the details element is tricky. By the spec, browsers don’t natively support transitions between display: none and display: block.
Very hot take; then don't animate them!
Animation in a UI is great - you draw the user's attention to a widget that changed because they might not necessarily notice it otherwise. This improves the UX.
With a details/summary, the animation is not needed and can only make a negative change to the UX. There is no positive change to the UX that animating the details/summary elements would bring. When it is opened it is obvious.
If you really really need to animate the details, instead of animating open/close, instead animate the summary background/text color to indicate that the element has just changed state.
Would I like easy animation of open/close? Sure. Does it improve the UX? Nope.
Ooh, that sounds useful as a pretty mix-in-bad-data method for scrapers. Have a few of these tags do if junk, even though they are hidden it'll look to a scraper that cares about hidden/not like they aren't always hidden so are likely to contain something worth adding to their DB…
I'd need to look into what effect this might have on accessibility, but my gut says "very little".
Fun fact: <details> even works on github and similar sites with markdown-based input. You can post large inline logs in issues without cluttering the conversation.
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.
This is false, recently the details element has gotten support for grouping them: the [name] attribute.
This effectively enforces tab-like semantics where only one of the grouped details elements can be open at a time.
This is a quite recent addition and the modern web is evolving too fast so I wouldn't put it past myself for missing this :)
Yay for progress and for JavaScript free solutions!
No, it's still true. I'm aware of that hack, but unfortunately it doesn't solve the problems with pure HTML and CSS tabs.
Crucially, the `name` attribute does not semantically turn a group of <details> elements into a set of tabs. All it does is introduce the (visual) behavior where opening one <details> element closes the others.
Same caveat applies to the "checkbox hack" or any other pure CSS solution. You cannot create accessible versions of most complex controls like tabs without JavaScript.
(That first example could be created semantically and accessibly with <details> / <summary> though!)
That's actually a common strategy called "progressive enhancement". The only thing is that your order is backwards: you should first make it accessible in pure HTML and CSS, and then use JavaScript to layer your fancy interactions on top.
So, for the tabs example, your baseline pure HTML and CSS solution might involve showing the all tab panels simultaneously, stacked vertically. Once the JavaScript loads, it would rearrange the DOM to hide all but one and add the tab-like behavior.
Here is a non-exhaustive list of issues you'll run into with various pure HTML and CSS implementations:
- Tabs should have an ARIA "tab" role [1], but <summary> doesn't accept roles [2].
- Focusing a tab must activate the corresponding tab panel [3], which requires JavaScript.
- Tabs should be navigable by arrow keys [4], which also requires JavaScript.
I want to be clear that I'm not trying to tear down your work. Your project looks cool and eliminating JavaScript is a noble goal. But unfortunately, as of today, it's still required to correctly build most complex controls on the web.
I really don't know. I'm not a CSS expert. I've just picked up bits and pieces of CSS knowledge from Google and AI agents. These results often aren't perfect, so you'll need to make some adjustments.
You can't actually control the open state properly from markup (the `open` attribute only sets the default state), which is why I haven't bothered with them.
I’m not sure this is correct. The DOM class HTMLDetailsElement has the `open` property, which you can use to read/write the details element’s state. If you’re using setAttribute/getAttribute just switch to the property.
Having to use the property on the element instance, rather than the actual HTML attribute, is exactly the kind of wrapper code I want to avoid if I'm using a built-in.
You need some JS to change an attribute as much as you need JS to change a property. What am I missing?
I hope the command attribute (https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...) will eventually support this out of the box. In the meanwhile you can write a single custom --toggle command which is generic and works with any toggleable element
`open` works just like checked for a checkbox input. You can set the initial state in HTML and CSS can respond to changes in the attribute if a user clicks it. Markup won't have programmatic control over the attribute by design, that's always done in JS by modifying the element instance.
If you specify the same name on each `details` element they behave like an accordion automatically [1], no need for JavaScript. If you set one of them to open that one will be initially open.
You can do that with a details element, you just need some code to actually do it. Which I'm pretty sure there's no possible solution that doesn't require some code to do that.
Yes. For example, on Codidact (https://codidact.com), limited HTML access is offered along with Markdown when making posts, and the details and summary tags in particular are whitelisted. I've made extensive use of this in some of my content, for example https://software.codidact.com/posts/289251/289252#answer-289... . If you have NoScript you can easily verify that the expanding sections work perfectly well without JavaScript. They can even be nested, as they are here; and the summary text can contain some other forms of markup without issue. (When crafting the post, however, I had to do some tricky things with whitespace to avoid confusing the Markdown parser.)
Details works even when it's set display:contents too, for even more flexibility. Can't animate from open›close, yet, though. That's pretty much my last frustration with it.
I think the CSS support for that has finally landed, though it means targetting a pseudo element instead. Its been a year, so support is probably good enough you don't care if just the animation doesn't happen.
Note that the transition to `auto` in that post relies on `interpolate-size` which has yet to land on Firefox or Safari, and neither have movement right now.
That's not correct. There is no aria-open attribute and the summary implicitly has the correct ARIA state, aria-expanded, indicating that its details element is either expanded or collapsed.
There have been bugs in its implementation, particularly in Safari and differing between mobile and desktop Safari.
The interesting part here isn’t “no JavaScript”, it’s that HTML already covers more use cases than people remember (forms, dialogs, validation, navigation).
I ran into this repeatedly while writing my book "You Don’t Need JavaScript"[0]: most JS in these cases isn’t adding capability, it’s compensating for forgotten platform features.
Agreed! I assume the reason for the forgetting of the features is that at least some were poorly supported when first released so developers create workarounds that then become the de facto standard.
It has been amazing to see the speed up in release and support of new CSS features over the last couple of years! Even the masonry layout has finally reached an experimental stage
Yup, at this point it feels more like habit than necessity. People learned to build things like dropdowns in JavaScript years ago, so they keep doing it that way.
A lot of devs simply don’t look any further when it comes to what HTML and CSS already provide.
That exactly describes me. I'm not a good frontend person. I got really, really good at building desktop GUIs in Swing (Java) back in the day and really imprinted on that way of doing things. When moving to web, I found the the display landscape really challenging to grok. I read a few books and got to where I could get most of what I wanted done, but it always took me way longer than it felt like it should, and certainly much longer than it took my coworkers. In that period I learned the contemporary patterns of the day and got pretty good at using component libraries with frameworks like React and was finally able to make things look and behave more like I wanted them to.
Because at that point so much of the focus was on javascript and component libs/frameworks, I didn't (and mostly still don't) really follow browser development. I looked into things like web components when they were first talked about but found their DX to be quite sub-par (it was still pretty early days) and haven't really looked again.
I'm personally much more interested in systems, infrastructure, devops, and all things backend, so for me frontend is a necessary evil to enable me to surface controls for my stuff to users. It's not that I don't want to stay up to speed and current, it's more that in my limited bandwidth I'm more focused on what I care about. That leads to exactly the pattern you described: I learned and got comfortable with a certain paradigm in a different time, and those ways are quite engrained.
Anyway, thank you for your comment. It really helped me identify a blind spot I previously had (which I intend to rectify) :-)
Thanks for sharing that! It’s a super common story. Frontend patterns moved fast (especially for the last 3 years), and not always in a way that encouraged checking what the browser itself could already do.
If you want to improve a bit and discover more what CSS and HTML can do today, I also try to post daily on my LinkedIn: https://www.linkedin.com/in/theosoti/
Very interesting book! These are the types of programming books I wish that were more abundant rather than "Learn X framework/language," those that solve/discuss interesting problems. Just bought a copy.
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...
My main beef with datalist is that there's no easy way to show and allow only text (e.g. Beverly Hills), but have the actual value selected be a number (e.g. 90210). In other words there's no analogy to <option value="90210">Beverly Hills</option>.
That and there's no HTML way to interactively load results. Or are you really going to serialize half a million records to HTML and transfer it all every time the relevant block is added to a page? What if it sits in the header or footer templates?
Right, I sort of expected there to be an attribute for an url.
<datalist json="search.php?q=toyota+corolla">
But then you would want to send other form values along with it which might make things more complicated than it should be?
Static could be better too. When search engines first started building these auto complete dropdowns the multi word input was really the killer feature. To have something like "green toyota" you would have to generate an element for all color and brand combinations? And the you want it to work for "green toyota corolla" and you get an abc kind of list length.
Perhaps a wildcard would have been fun or regex options.
Indeed, and if I have to build a component for it in JS anyway, I'm highly likely to just reuse that component everywhere I need it rather than have to build, style, and test different implementations in the same app.
> Each <option> element should have a value attribute... It can also have a label attribute, or, missing that, some text content, which may be displayed by the browser instead of value (Firefox), or in addition to value (Chrome and Safari)... The exact content of the drop-down menu depends on the browser, but when clicked, content entered into control field will always come from the value attribute
This seems... underspecified. Not ideal that Chrome/Safari aren't aligned with Firefox here, and that there is no standard way to only display the label
Default styling being ugly is often for backwards compatibility with older sites so their look stays as consistent as possible. For that reason opening an issue is likely a waste of time for GP and for the devs.
They also are most certainly quite aware of how the default styling looks in their browser. It wasn't an oversight. That's not to say it doesn't pain them, it often does, but it has been intentional
Usually it looks however the native OS toolkit looks, just like everything else in browser. This is pretty new (and not well adopted) tech so it's not about legacy styling considerations (like, say, the default CSS for text being so awful) but rather that the OS no longer looks the way people want it to look by default.
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.
Technically native selects do have a very rudimentary form of filtering: start typing text with the select focused and it will auto-select the first matching option.
E.g. if the select is a list of US states, type "N" and it will jump to Nebraska. Continue into "New" and you'll get New Hampshire, etc.
This is better than nothing (and I personally use it all the time) but not a patch on an actual proper select-with-filtering which, yes, you still need JS to implement properly.
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.
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
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
Just been through several frontend interviews in the last few months, where it's clear that they still judge a developer's JS skills (especially React) than being semantically correct on HTML elements.
Every question/exercise is centred around how well you know React hooks, effect, memoization, modern css-in-js etc. Given I've been working with Astro recently, in one interview I talked about DOM APIs and I can see the interviewer raise an eyebrow. In later stage, even I that passed the exercises, still didn't get the job.
Remember that a large part of hiring is finding someone who fits in an existing team. A team that uses react won't appreciate someone choosing to use native DOM APIs instead of a react component.
In every React team I've been part of we've wanted to use as little react as possible and use native DOM apis when possible. React would be used purely for state management or interactivity.
I feel like teams that have used react enough learn that the less React you can use the better :) it's a great tool, but most teams use it because it's all they know and they don't know what they don't know about html.
Weird comment, I'm a web dev that has been using react for 10+ years and I prefer using native browser features whenever possible. I'd honestly avoid hiring framework specific devs because the skills required are never about just one single framework.
Also this is just all JS + HTML here, let's not act like it's impossible to learn the most popular frontend tool at the moment.
Eh. I build apps with Preact, but I prefer candidates who know the core web platform. They’ll be more apt to use the right tool for the job and not be baffled by edge cases.
It's not HTML purism. It's simply recognizing that HTML and CSS have evolved a lot and many things don't need (or are close to not need) JS anymore.
This shouldn't be taken as an anti-JS article, everyone benefits from these gradial improvements. Especially our users who can now get a uniform experience.
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.
> 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.
I would certainly agree that using a little JS can get you further than just HTML. But I think that a plain HTML page is far more pleasant to use (and thus, functional) than the JS monstrosities that dominate the Web today. There's a reason people use the NoScript addon: because a whole lot of website designers use JS in ways that make the experience a ton worse for the user.
It's not an either/or. Modern Javascript is actually really nice to write and use, and you can write it in a tight, minimal way that doesn't bloat the page or slow it down.
Of course you can, but most people still opt to pull in a whole framework (React) or heavy library (jQuery) just to achieve what's essentially a few XMLHttpRequests and some DOM changes.
> 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.
You're overthinking htmx then. I do some fairly complex stuff with no extra partials. Trick is just always rerender and use hx-select and hx-target to slice out the bits you want to update on the current page.
Server always has authoritative state and code is dead simple to reason about.
> I do some fairly complex stuff with no extra partials. Trick is just always rerender and use hx-select and hx-target to slice out the bits you want to update on the current page.
Good trick! My only experience of HTMX in production entailed porting Stimulus code, hence the partials, but your approach is obviously much neater. I'll give it a shot, next time it might be suitable.
OT: marquee tags were a missed opportunity to implement horizontal scrolling often used on shopping websites. Now it uses JS to achieve the same.
I have been trying to find other more commonly known UI patterns that could be done natively. The time has long come for tabular data to be put into HTML tables just by referencing the source. Xslt almost did that. Another one is integrating xml http requests with native html. I think HTMz came close to this.
Sounds great <table type="text/csv" src="mydata.csv"> Then have it generate actual html so that you can target th's, tr's and td's with css.
I believe the lowest hanging fruit would be <div src="article.html">
I think formData should also be available as interactive JSON but perhaps it is possible to also populate a form with fields from a json with something like:
There's a usability and design issue with that as you lose what you're reading as it scrolls off the screen. Also, scrolling is a styling issue and not a document description issue which is what HTML is for.
Note: <marquee> has never been part of any HTML standard since the beginning except the current one which only has it for the purpose of marking it obsolete so people will quit using it.
> marquee tags were a missed opportunity to implement horizontal scrolling often used on shopping websites. Now it uses JS to achieve the same.
I have been trying to find other more commonly known UI patterns that could be done natively.
Are you sure you are talking about the functionality of the marquee tag? What exactly do you mean by "implement horizontal scrolling often used on shopping websites. Now it uses JS to achieve the same"?
For a banner-type text "Sale: 50% off until New Year" I can imagine this. And this is possible with almost no JS, by using a CSS animation on translateX. I think you need to pass the initial width of the content one time from JS to CSS via a custom property IIRC, and update that variable on resize, for example using a ResizeObserver, to avoid a jump when reaching the "wrap around"...
But – sorry if this a misunderstanding – I have a sneaking feeling that you might also have things in mind like swipable horizontal lists etc?
This is also possible using CSS in theory (scroll-snap and overflow-auto, and CSS to hide the scrollbars). But last I tried to use it, it simply wasn't good enough to sell it, compared to a fat JS library that did the trick, perfectly, on mobile and desktop.
When it comes to UX niceties, I feel it's pretty common to have HTML+CSS solutions that are good enough in theory, but suck in practise.
For the horizontal scrolling with "snap", I would also like a good JS-free solution. But I feel that the more interactive and complex the UX patterns become, it would be senseless bloat to build a specific implementation into the platform.
I think that "autocomplete" inputs are a good example for this, as discussed in another thread.
I once tried to implement a custom autocomplete using datalist (including dynamically updating the list with xhrs). In the end, the native element had so many issues that it was a waste of time and a JS solution was way better. At the time, that JS solution was Alpine.Js, because it was a b2b app with minimal a11y requirements and JS-allergic developers.
Within an hour, I was polishing keyboard use while the "near-native" solution using datalist was broken in a thousand different ways in every browser and in the end didn't work well at all.
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).
I appreciate the helpful reply, but I think this is precisely the kind of indirection I need to avoid. I'm a sucker for elegance. If left entirely to my own devices I'd probably design a language / write a transpiler of my own, and wind up with exceedingly elegant tooling for websites, and no websites. :)
This is why I don't use Typescript or frameworks in my own projects, I just constantly seek the cleanest abstraction and never get anything done. Using a deliberately messy solution is annoying but at least I accomplish stuff.
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.
I dont think anyone is arguing Google Earth should be pure HTML. But it is equally false you cant do Gmail with HTML only.
There are things that HTML could do, and should be doing, that is not done or not yet possible simply due to hype and trend from browser vendors. We could continue to polish HTML + sprinkle of Javascript to its absolute maximum before hitting JS Apps. Right now this is far from the case.
Hey the email services has just proved you could offer better than Gmail experience with HTML + small dose of JS. Another example being the new FE on Github.
At the end of the day it isn't really the tech that is the problem. Is how people use the tech. And for thousands of different reasons keeping it simple has always provided better experience evaluated on the whole.
Github's old frontend was mostly HTML with a bit of JS, their new frontend is react. The old UI had its bugs, but it was much better than the react version in my experience. I still commonly find the UI out of sync with itself requiring a reload, but now I also frequently wait for the page to load and viewing large diff's is a performance nightmare.
Not really. I used the HTML version for well over a decade and it was absolutely fine. I guess if you need fancy animations, maybe that doesn't suit you, but I came through Pine and Eudora and Gmail HTML was a million times better than both of those and entirely sufficient for a media that dates back about 50 years.
Actually, I do think that. Wouldn't it be lovely to have an image format for truly enormous images and have the browser request only the chunk currently visible? It could just be a container format with jpg's in it. Let the file system figure out that x/y means tile number 56436.
You could provide multiple image versions for zooming to get to the TB scale.
Computers are really good, performance is astonishing, no reason why we should never be able to use a TB size image. Never is a really long time.
Have epic panoramas, detailed scans from paintings, extremely easy game design and maps that just work.
I assume you mean htmx. It doesn't have to be either/or. You can supplement htmx with Javascript.
The core idea with htmx is that you transfer hypertext with controls and structure built in, not just a JSON blob that requires additional context to be useful.
I have just shipped a very useful and interactive app surprisingly quickly for my customer using just htmx with a little Javascript.
It shouldn't have to be this way though. There is no reason html can't do things it needs to do to build complete apps. We could use reasonable defaults to allow a new type of html markup without JavaScript.
All the http verbs.
Decent html input controls
What else?
Depends on how complex it is meant to be. Just like many wordpress sites that could easily have been static websites, many javascript heavy sites could have easily just have been using htmlx.
If your need really, goes beyond what htmx offers, then you may need Javascript. But in my experience people tend to use the tools they know for their job, not the tools that would be best suited.
FYI, it's easy to cache the html output of a WordPress site, resulting in essentially a static site with graphical admin, page builder, and all the other bells and whistles.
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.
I don't want to be so negative, but we got details and popover after literally decades, and we still have datalist presented as a plausible option? Html is so underdeveloped and the first we all agree on that the first we'll pretend from committee real advancement
The committee is an unsolved puzzle as old as mankind. That's not to discourage you. If you do solve it it would remedy almost all of our problems. If the solution could be found instantly in 5 seconds someone would have solved it already. This one is going to take some actual thinking and modeling.
I know for sure that Apple, who has an important seat on the standard committee, holded back innovation for so long, it's not a matter of finding or not finding solutions. They're failing us for different interests
> I know for sure that Apple, who has an important seat on the standard committee, holded back innovation for so long, it's not a matter of finding or not finding solutions. They're failing us for different interests
Apple isn't the problem.
Apple was the first to ship :has(), which developers wanted for 20 years but was thought to be essentially impossible to implement [1].
Apple pushed to get consensus on how to implement masonry layouts in CSS [2].
And they were first to ship the new specification in a browser you can use right now [3].
This dashboard shows Apple slightly ahead in terms of new CSS features being implemented and interoperable with Firefox and Chrome [4].
Oh please they pushed back pwas for "security reasons" for years. Safari is the browser with most quirks compared to FF and Chrome, it's considered by many the new IE holding back innovation. Sure they implemented some stuff before other who cares of changes that don't disrupt their apple store model? I don't want mansonry layout if not for designers portfolio or blog? I develop serious appa and I want an api to invent my own layout and I want feature parity with native apps
> Safari is the browser with most quirks compared to FF and Chrome
That may have been true 5 years ago and I get developers have long memories—but that's no longer the case.
> Sure they implemented some stuff before other who cares of changes that don't disrupt their apple store model?
The conspiracy theory Apple, whose revenue was $391 billion last fiscal year sees PWAs as a "threat" is nonsensical. Also, new features for the web platform gives developers another reason to create web apps instead of a native app.
In reality, Safari's PWA support is really good; it has implemented 89% of supported PWA features vs 96% for Chrome according to the PWA scorecard [1].
> It's considered by many the new IE holding back innovation
As someone who lived through the '90s and early 2000s doing web stuff, I can assure you anyone who believes "Safari is the new IE" literally has no idea what they're talking about; they're just repeating a meme they don't understand.
> In reality, Safari's PWA support is really good; it has implemented 89% of supported PWA features vs 96% for Chrome according to the PWA scorecard [1].
I remember, I was like, ohh sounds great! So I tirelessly looked for an "add to home screen" button but couldn't find it.
I had to search google to find the answer, you hve to share it!?
weird but okay, so I open the share menu. No such option there.
Again I search, ahh so you have to first edit the sharing options!
The only thing missing from the experience was a warning dialog.
Moral of the story, it doesn't matter if it works if people cant find it.
The 3rd class experience was funny but then they announced they were going to get rid of pwa's entirely.
> The need to remove the capability was informed by the complex security and privacy concerns...
When a 4T company says such things you know it must be hard.... lmfao....
I've never had to explain to an android user how to "Add to home screen". Explaining it to iphone users honestly sounded like I was trying to hack them. It drifts so far from apples usually polished UI that I cant blame them.
They are the new Microsoft, if the web died it would be good for them. We've also tried to have elected bureaucrats make the decisions. Systems giving everyone one vote also turned out terrible as expertise and thoughtfulness drowns in superficial noise. It is kind of embarrassing how well the dictator model works. Personally I prefer to do everything alone. There are no meetings, barely any paperwork, I get to own the bad choices. So far I get along well with my past self and my future self. I do consider it a temporary hack until figuring things out in groups is solved. Robot overlords sounds increasingly appealing.
Until your client tells you that it doesn't work in Edge and you find out it's because every browser has its own styling and they are impossible to change enough to get the really long options to show up correctly.
Then you're stuck with a bugfix's allotment of time to implement an accessible, correctly themed combo box that you should have reached for in the first place, just like what you had to do last week with the native date pickers.
I'd argue that adding complexity from the get-go to ensure that all users have a pleasant experience from the get-go is better than simplicity at the expense of some percentage of users.
I think it's important for web devs to spend more than two seconds to think if the complexity is necessary from the get-go though.
Before anyone wastes a lot of time like I did trying to use the popover API: it is not ready yet. You can do very basic things in all browsers but positioning is still different and/or totally broken per browser.
Yes, HTML & CSS alone won't replace JS. Of course, for complicated form validation HTML is not sufficient. But IMHO it's very important to provide basic functionality in HTML / CSS as much as possible / reasonable. Moving the functionality to HTML / CSS can potentially improve the SEO.
As for positioning, there is an experimental feature @position-try. Here I made a small demo where it handles overflows.
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 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.
Modifier keys are used elsewhere optionally on operating systems. But no other form control demands knowledge of modifier clicks. It's simply a useless bit of UI and should not be used.
> If we can hand-off any JS functionality to native HTML or CSS, then users can download less stuff, and the remaining JS can pay attention to more important tasks that HTML and CSS can't handle (yet).
The <details> and <summary> elements are great, but I think the bigger missed opportunity is the lack of inline examples/demos on the page itself. Would be much more powerful to actually show these working rather than linking to external codepens.
A few thoughts on the practicality:
1. Progressive enhancement is the real win here, not "replacing" JavaScript. These HTML features provide a baseline that works without JS, then you enhance with JS for better UX (animations, state persistence, etc.)
2. The details/summary approach breaks down when you need:
- Custom animations/transitions
- State synchronization across multiple elements
- Analytics tracking on user interactions
- Keyboard shortcuts beyond basic tab navigation
3. What about the <dialog> element? That's another underutilized HTML feature that could replace a ton of modal/popup JavaScript.
4. Have you explored the Popover API? It's getting broader browser support and handles a lot of common UI patterns without JS.
The spirit of "use the platform" is great, but the title feels a bit clickbaity - you're not really replacing JS, just avoiding it where unnecessary. Which is good practice anyway!
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.
"Nothing against JS, but it has better things to do than setup and manage your accordions or offscreen navigation menus... "
Perhaps this is referring to "things" such as data collection, surveillance and ad services
It would be interesting to see how Big Tech and other adtech companies would accomplish the same level of data collection, surveillance and ad services without the use of Javascript
As for "nothing against JS", I think some web users (cf. "developers") who dislike adtech and the ad-laden web they perpetuate might have something against it
Use a checkbox, d. Define vars for light mode. Override when checked for dark mode with body:has(#d:checked) and can include the dark mode media query too
Why would you build a switch instead of relying on the user’s system settings? The only reason I can imagine is that your dark/light mode is not usable/readable so it forces the user to switch
I often use different light/dark settings between apps and my system. Just because I want system UIs to be dark, for example, doesn't mean I want to read long pages of white-on-black prose on your blog.
Seconded. Just because I like to have the browser toolbar dark and GitHub dark doesn't mean I also want to read lengthy articles (LWN) in thin white text on a black background.
My specific usage is a site to host my own internal training content.
I want to read it in dark mode and give users that option, but I want to present it in light mode because dark mode suffers poorly from video compression when screen sharing.
I currently have a JS toggle for it which uses local browser storage, but ditching JS would be nice if possible.
Having it default to the users preference is nice, but you should still provide an override. I sometimes use my browser in light mode while my OS is dark mode. Many times, I find the contrast for dark mode websites too low unless I’m in a totally dark room.
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.
If we've concluded that's it's okay to have elements that change/morph, as we seem to with the introduction of things like details, a native tab-like element feels like a glaring omission. Tabs have been a long-standing UI pattern and forcing every site to implement their own is a nightmare for accessibility. (The page you're reading is maybe already in a browser tab.)
I wouldn't be surprised if it turned out less than half of the custom tab interfaces on the web failed from an accessibility standpoint. When considering ARIA guidance, I don't even think it's possible to build an accessible version in HTML alone.
Other people have recognized it's missing. Open UI has a draft spec for it[0] and CSS Tricks has an article from 2001 about Open UI's experiments with sections for tabs[1]. I have no idea what happened on this front, though.
Accordion behavior is discussed in the article in the "Accordions / Expanding Content Panels" section:
> Use the same name attribute on all related details (like radio buttons) to restrict only one open panel at a time
And tabs can be a <details>-based accordion with some creative CSS to adjust the layout (left as an exercise for the reader, but I could write up an example if that would be helpful!)
Yes, the tabs in a tabs pattern should be keyboard navigated using arrow keys (ironically not the Tab key).
Also, the summary for the currently open details element will have the wrong state, 'expanded' instead of 'selected'. And while a set of details can now have a maximum of one open at a time, you can't ensure exactly one is always open (without JavaScript) as the tabs pattern requires.
And yes, being able to do all of these in pure HTML/CSS would be awesome. Though we are getting there with things like `details` and the newer `popover` features which should make things like rich tooltips, menu buttons, etc. a lot easier to implement. IIRC, there are also several anchor CSS properties to make positioning a lot simpler.
That’s a bit of evergreen topic. “stop bloating web with js” comes up fairly often and there are those people who think they found a solution and everyone should start using whatever they imagine is “best for everyone”.
In my opinion most of those people struggle with whatever they encountered in ecosystem and just want to find a way that fits them - while also trying to make others do the same.
*“You didn’t want to make things perfect. You just hated things the way they are.”*
Brilliant I will be adopting a few of these, I have been on a personal quest to reduce js use recently, I feel like I spend more time debugging js than producing the end result.
Most people think that you should remove JavaScript to load your sites faster or for reasons like that. You have to learn to balance things, always use it if you need some good interactivity, validation etc. Don't try to use HTML only to force things.
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.
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.
I was stuck on the backend while CSS3 absorbed most of the functionality of Less and Sass and now I’m trying to play catchup. If there had just been a CSS4 I’d be able to find a tutorial to teach me everything I missed in the interim.
I really try not using JavaScript unless absolutely needed. On my latest project, the whole site actually functions without JavaScript and is server side rendered. However, there's some small piece which I really needed JavaScript for couple reasons.
Basically, I have a site which collects the top STEAMD posts from places like HN, lobsters, tildes, slashdot, bear, reddit etc and displays them in chronological order. I wanted a way for users to block posts with certain keywords or from specific domains. I didn't want to do this server side for both performance reasons plus privacy reasons. I didn't want users to need signing up or something to block. I also didn't want to collect block lists for privacy reasons. So, I resorted to using JavaScript and local storage. All posts within the filter for the date are sent and JavaScript is used to block posts with keywords before displaying. So my server never knows what keywords are blocked.
i like the points the article makes, but i really wish it used looping videos instead of actual GIFs
i don't really see any reason to use GIFs here; any widely available video codec like H.264, VP8/VP9 or AV1 will result in significantly smaller file sizes, look better, and will allow enabling controls for seeking and play/pause
My personal pet-peeve everytime a "you don't need JS" post comes up on HN, is the disconnect between the interface designers and the developers. In my dayjob as a (mostly react) freelance contractor doing B2B and LoB apps, there are always UX designers coming up with the screen- and interface designs. I don't think any project I ever were, could have matched a screen design I was passed without JS. Whether it being business requirements (has to work in IE, or nowadays has to work in Edge), or simply hard visual design choices.
My favorite example is that of a date, date-time or date-range picker. Yes, there are HTML native elements. But they look absolutely ugly, styling only goes so far, and good luck with requirements such as "oh, but in the popup on the date-range picker, add a topbar with 3 buttons that trigger preselection and a dropdown". Now you can argue and communicate back that we save a lot of technical complexity in the stack if we stick to the HTML native solutions. But all those discussions basically end up managers and UX designers having no clue about the actual complexity and savings (time and money wise for future maintenance) and simply don't care.
And if I am the one telling them "Look, in the HTML native date-time picker, you can't add custom elements, you can't fully customize every bit and piece of behaviour so change the screen designs" they will just fire up random corporate website XYZ and show a similar version of what they have in mind (and it is always JS-based) and suddenly it looks like me being unable or unskilled to achieve something, that is clearly doable as others have done it.
Now not all is nice and shiny in the JS/React world. We use MaterialUI in a current project, and the commercial MUI-X DatePickers. They also come with their limitations, but it is just they are far more powerfull and customizable to actually meet the requirements and demands of UX and management, compared to the HTML versions.
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?
JS got popular because some devs were trying to realize a world where the same code can be shared on the front and backend. I think on the surface, it was a noble goal with good intentions. Having only one programming language to handle is going to create some efficiency gains when you work in a large company with thousands of devs who all need training want to share knowledge as a larger organization.
In the past decade, we went full JS as an industry and now we’re starting to swing back. Server side interactivity like Phoenix Liveview, C# Blazor, HTMX, PHP/Laravel Livewire, Rails Hotwire, all of these are different abstractions around JS to make interoperability between the frontend and backend more manageable and they’ve come a long way to closing the gap. Advancements in HTML/CSS standards also deserve credit for closing the gap but we’re still not quite there yet.
But at the end of the day, the web is dynamic. As new tools and techniques are discovered, the industry will continue to evolve and certain “hacks” will become new standards and ignorant newcomers will reinvent the wheel again to achieve some crazy interactive design because they didn’t know any better! And it wil work, mostly.
Until the way we interact with browsers changes, I feel that we’ll continue to bolt on new features over time and the web will continue to evolve. Just like the iPhone, a surge of use of smart glasses could change the computing paradigm or perhaps its some other device entirely.
So you can (and should!) try to optimize for today, but trying to optimize for tomorrow will always carry the risk irrelevance if the market pivots quickly. Bleeding edge is risky but so is falling behind.
The problem is that CSS continues to be a pain in the ass, even as it evolves. There is no other reason why something like tailwind should have the traction it has.
The switch from everything tables to everything divs was one of the worst for usability on the web. Every day I run into a table of data that doesn’t sort, copy/paste, search, resize columns or any of the very trivial items to do with tables. It always infuriating.
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.
> Nesting the elements is a truly hideous choice. The summary is part of the details?? I thought they were opposites.
It gives them a semantic connection. Last I checked, HTML isn't really based on giving special meaning to combinations of sibling tags. A summary is part of the thing that conceptually requires detailing.
> If you find 1000 websites using a toggle I doubt there is one using an ugly arrow like that.
I think the default looks fine. But TFA clearly explains right there that it can be styled. (Specifically, by styling ::before on the summary tag.)
> The default styling gives no clue about it being clickable?
You asked what the arrow is, and then asked about the lack of indication that the summary header is clickable. The arrow is exactly that indication.
> Maybe I'm dense but I also want my url to reflect the state of the page.
If you scroll, should the fragment automatically update as you scroll past anchors? I think I'd find that quite annoying.
An element should be visible or not be visible. There shouldn't be a 3rd state. It is a new idea and it is bad. Try writing a polyfill.
Even if you insist it shouldn't be the only way to use it. There should at least be a <summary for=""> so that the clickable thing can be put wherever one likes.
The goal is to make things convenient for the user not to sacrifice usability for some semantics.
But if it was a summary is not semantically part of the details.
I don't actually care about that, I just want to use it.
A summary should be allowed to have hyperlinks. I passionately hate clickable paragraphs but if you are going to do that at least change the pointer into a hand.
I could put the <summary> under the summary the way almost everyone does but then the name makes no sense.
>I think the default looks fine.
A summary (longer than a few words) starting with an arrow looks weird.
The arrow would be reasonable UI for fold out menus but those are not summaries.
I would want some margin on the left for the <details> of the sub menu.
What I don't want is to also have padding on the parent(!) menu item. Seems like a very confused parent child relationship.
>> Maybe I'm dense but I also want my url to reflect the state of the page.
>If you scroll, should the fragment automatically update as you scroll past anchors? I think I'd find that quite annoying.
Depends, if the thing is infinite scrolling and the user needs to send a permalink it would be nice to update it.
If I have an accordion with say frequently asked questions it would be necessary to link to the items.
It often isn't needed but I can't really picture when it would be annoying.
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
A missed opportunity to not have all of these examples inline. The page/blog-post would be so much more convincing if it utilized all of these HTML replacements instead (or in addition) to linking to codepen.
Absolutely mind boggling. I've seen it many times before. There's some FooMaker v1.0 announced and you click on it thinking it will allow to easily make Foo and the example is how to disable FooMaker's lights l while AC is running or some other obscure edge case that affects like one in a million people, no examples how to actually use it for most common use case or how the result look like.
I had assumed this was a 25 year old article at first glance. Those dithered gifs sure are a throwback!
I was also frustrated to find the examples weren't inline, but I think this is a guest blog post which makes it a bit more understandable.
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.
One drawback of details was that cmd+f search wouldn't play nicely when the details was closed. But now there's a hidden="until-found" you can put on child content, along with an associated event. So you can open the details when a user searches :) super useful
You don't need the hidden="until-found" for details/summary, because that has those semantics automatically, but you can use that for other elements that behave similarly (for example tabs, which can't quite correctly be implemented with details/summary, and so needs to be done by hand).
Also I think the event isn't currently emitted consistently on all browsers (and maybe not at all for hidden="until-found"?) so unfortunately you can't quite rely on that yet if you need to sink some JavaScript state to your html. But in general, yeah, this is a really cool feature.
Oh huh I didn't know details supported that naturally. I'm guessing this wasn't always the case and my knowledge is simply outdated. TIL!
Yeah, support was patchy until recently (and I think that behaviour might not even have been standardised?) so I think a lot of people have assumed that if you want that functionality you need to do something extra.
Yes, Google started revealing the contents of <details> a few years ago, long after the element was supported in all browsers. Firefox added support earlier this year and Safari just added it.
Supporting the behavior was related to changing the user agent CSS when they're closed and the other browsers implemented it and hidden=until-found at the same time.
https://caniuse.com/mdn-html_elements_details_search_match_o...
> The details / summary thing absolutely kills me. There’s basically nothing you can’t do with them.
Animating the details element is tricky. By the spec, browsers don’t natively support transitions between display: none and display: block.
That is no longer true! You can do it in CSS with a combination of `@starting-style` and `transition-behavior: allow-discrete`. [1]
Another gotcha you'll run into is animating the height. A couple other new features (`interpolate-size: allow-keywords` and `::details-content`) will let you get around that. [2]
Modern CSS is awesome.
[1] https://developer.chrome.com/blog/entry-exit-animations
[2] https://nerdy.dev/open-and-close-transitions-for-the-details...
The major issue with this is that modern CSS is almost its own job, to the point we used to have Interface Developers at some place I’ve worked (HTML+CSS specialists). I did frontend for over a decade and eventually lost the train on CSS changes, I don’t even know what’s going on there anymore.
It’s still awesome, but it’s becoming increasingly silly to ask someone to know modern HTML, CSS, JavaScript, Typescript, some build tools, a couple of frameworks, etc.
The amount of JS we ship to clients is a reflection of cost-cutting measures at your workplace, not that every FE dev shuns CSS.
When I started dabbling in web development, writing HTML and CSS was already its own job, and professional JavaScript developers basically did not exist. This was before TypeScript, before Node, before Ajax, before React or even jQuery. If anything has exploded in complexity in the intervening years, it's the JavaScript part of the equation.
I agree that it's increasingly silly to ask someone to be an expert in all of frontend. But the primary driver of that is not all the new CSS features we're getting.
These are fair points. And developers themselves thought “hey, what if I also write Node?”, thus making things worse. Businesses accepted that all too willingly.
<sarcasm>I'm an expert -> just write everything in static html, use css only where defaults are neglected. After relevant tables in the db are updated generate a new static document. Only if that won't fly use json but feel appropriately dirty when you do.
Agreed. Having a "HTML + CSS" engineer on the team was largely due to the number of hacks needed to make css work -- purposely adding invalid html that would only be parsed by specific browsers, ie5 vs ie6 vs netscape being wildly different (opera mobile was out of this world different), using sprites everywhere because additional images would have a noticeable lag time (especially with javascript hover), clearfix divs to overcome float issues. To be clear, I'm not saying "things were harder back then" or "css is simple now", but things with CSS were so wild and the tooling was so bad, that it what a unique skill of it's own that is less needed now, and the shift has been for people to focus on going deeper with js.
I can't see how a bunch of esoteric incantations are better than just some straight-forward easy to understand and follow JavaScript.
Because you need 20x the JS to do the same thing and it’s still not hardware accelerated. These new CSS properties are well supported and will only get better.
Is that "straight-forward easy to understand and follow JavaScript" the whole thing written from scratch? Or does it use libraries (that use libraries, that use libraries)?
Because I've written my share of javascript-from-scratch in my time - before npm and such. And even if my use-case was limited, in order to get edge-cases and details working - issues long solved by their HTML/CSS counterparts - we needed more and more JS. Many of which handwritten polyfills, agent-detection, etc.
Seriously, things like scrollbars (because the client insisted on them being consistent across user-agents) or dropdowns (because they had to be styled) "visited" state on links, in pure JS are thousands of lines of code. Maybe not today, anymore, IDK, with current APIs like the history API or aria labeling. But back then, just in order to make the dropdown work with screen readers, or the scrollbars react well to touchpads -in the direction the user was used to based on their OS- took us thousands of lines of JS, hacks, workarounds and very hard to follow code - because of the way the "solutions" were spread out over the exact right combination of JS, HTML and CSS. Edit: I now recall we got the web-app back with the comment "When I select "Language" and start typing "Fr" I expect French to be picked and "enter" to then put the language in French". We spent another few days on functions that collect character inputs in memory and then match them with values. All because "flags in front of the names were of crucial importance".
So, maybe this is solved in modern HTML/CSS/JS. But I highly doubt it. I think "some straight-forward ... JavaScript" is either an `import { foo } from foobar` or a pipe-dream in the area of "programmers always underestimate hours"
using flags for language is a bad pattern I wish would die. I'm not clicking on the British flag!
Certainly. But the problem here wasn't "we want flags", but that the client (via the designer) demanded something that couldn't fit in a select box and so we had to build our own.
Now, I think part of the problem is that such elements weren't architectured properly when invented. Like many other HTML elements, they should've had some way to style and/or improve them.
E.g. an H1 Header, I can apply CSS to and change it from the default to something matching the business style. I can add some behaviour to it, so I can bookmark it's id anchor. I can add some behaviour to turn the H1-6 into a nice table-of-contents. Or an image can be improved with some CSS and JS to load progressively. But most form elements, and the dropdown in particular, is hard to improve.
And, yes, I am aware of the can of worms if "any element is allowed inside an <option>". Or the misuse designers will do if we can add CSS to certain <options> or their contents. Though I don't think "webdevs will abuse" was ever the reason not to hand power to them. It was mostly a disconnect between the "designers of the specs" and the "designers/builders of websites".
Because that "abuse" is never worse than what is still done en-masse: where we simply replace the "select" with hundreds of lines of CSS, divsoup, and hundreds or thousands of lines of JS. Where entire component libraries exist and used all over the place, that completely replicate the behaviour of existing (form) elements but with divs/spans, css and js. And despite the thousands of hours of finetuning, still get details wrong in the area of a11y, on mobile platforms, on obscure platforms, with a plugin, with a slow connection and so on.
Luckily things are slowly changing for the better. You can actually style a <select> now! Browser support is still scant but it'll gracefully degrade to a normal looking <select>. https://developer.mozilla.org/en-US/docs/Learn_web_developme...
What about strings + flags?
String of the language, in it's language: [Flag] Suomi (Finnish)
Because a team of browser engineers have already written and reviewed the code to do it for you; and (hopefully) it’ll be performant, properly tested and accessible… ;-D
JS animations run on the main thread with everything else, so if your browser is busy doing something else the animation ends up being janky. Using CSS solves that problem.
1. CSS is declarative, so it avoid subtle bugs
2. CSS integrates better with HTML, as it has selectors to automatically bind to elements (yes there custom elements for JS)
We've gotten so far away from semantic documents so we could build "apps".
Data used to be first class. You would deliver everything in the HTML container and the style sheets or client could do whatever it wanted/needed with that data.
Native search, native copy, no clever javascript tricks to hide or remove information from the document.
The HTML data container should be immutable.
> We've gotten so far away from semantic documents so we could build "apps".
Exactly. We're still pretending that the browser is some kind of document display application when it's an application runtime. We keep adding more HTML tags and infinite number of CSS properties and features (that never get it right) when what we should have as a better application GUI API. Throw all the hardware acceleration and threading into that instead of @starting-style, transition-behavior: allow-discrete, interpolate-size: allow-keywords and ::details-content and breath some sanity into the platform.
We've effectively re-implemented that desktop/mobile GUI using a bunch of cobbled together technologies and continue to get more esoteric and complicated every year. Hell, I'm not even sold on JavaScript -- it's just as clunky and weird as everything else.
Move document rendering into high-level implementation on top of a better designed low-level API much like how PDF display in browsers is done with JavaScript.
It sounds like you want a game engine.
I want a hypertext document viewer.
> @starting-style, transition-behavior: allow-discrete, interpolate-size: allow-keywords and ::details-content
This is sane from a declarative document styling syntax.
In my opinion the problem is the lack of good GUI editing apps for purely HTML documents and no standard for self-contained HTML docs (that would bundle all the ressources into a single clickable file).
Word for the web basically, but with support for multimedia.
In that sense the web has failed, there is epub but it's not really good.
As a developer, I want a sane platform. Sometimes I want to write documents and sometimes I want to write applications.
> This is sane from a declarative document styling syntax.
Is it? CSS intentionally avoided mixing animation with live layout resolution and now we have a "switch" to enable it. I wouldn't call that elegant.
If we could just hook into layout with code this could have been resolved years ago instead of waiting for browser makers to invent yet another set keywords.
Is CSS too hard to learn or something?
I'm not particularly familiar with modern webdev, can anyone share a minimal example?
JavaScript encumbered pages break at least once for NoScript users.
To be fair, that's on the user. It's a trade-off the user is making, knowing that there's poorly made sites out there and sites that actively depend on JavaScript to function (sometimes because JavaScript is the only way they can function, but usually because someone's never heard of progressive enhancement). In the past, turning off JavaScript was a functional way to prevent things from running and to make sites load faster; today ads and progressive enhancement and optional functionality are hardly the only usage of JavaScript: lazy loading variable-size content (via fragments or otherwise) causes scroll issues if you're trying to go for performance on a complex layout. CSS containment and content-visibility with contain-intrinsic-size help solve this, but they're pretty new.
@starting-style Has less than 90% browser support making it a non-starter for the time being at least.
It'll just degrade gracefully into not animating the element's entry, so unless the animation is somehow crucial you should still be fine to use it.
If you really need to detect whether it's supported there are hacky methods: https://www.bram.us/2024/07/11/feature-detect-css-starting-s...
I agree, but must also observe that I have never met a designer who was willing to admit without a knock-down drag-out fight that any animation they put in was not somehow crucial.
I've never met a designer who wasn't completely fine with my suggestions for more pragmatic solutions. Like just styling a default scrollbar instead of implementing my own scrollbar to make it exactly like the design. Using a default drop-down menu instead of rolling my own just so I can round the corners of the selects.
The designers I've worked with are fine with these things. We have more important things to work on than small style details. We can go back and change these things later if anyone actually cares, but generally nobody ever does.
I've never met a designer who cares how it gets done but I have hard time believing they were OK with the corners not being rounded as per the design. They may agree on shipping without the rounded corner, as long as the ticket to round that corner is registered.
I suppose though that we have just had very different life experiences, as that is what the HN guidelines would require of us.
I think you're both right.
I have also met a lot of completely unreasonable designers that would insist on the most minimal things (even to the detriment of usability), and would act like assholes towards developers.
I have also had situations where developers would beg to work with a certain designer because their experience made development a breeze, even for complex layouts. Funny enough, the projects where this designer worked would always get done, and the visual result was always great.
The trick is they'll see it working for themselves. :)
It depends on what you're doing. It's common for clients to wonder why the design they saw had fancy animations yet they don't see them on their MacBook...
91% of usage for browsers tracked by caniuse [1].
The biggest gap is Chrome versions > 2 years old.
[1] https://caniuse.com/?search=%40starting-style
* Only works on chromium browser for now.
** Works badly even on chromium browsers (granted I was doing weird stuff, but the animation did not work properly).
I estimate that in a few years we will have animations working properly and mostly everywhere on details elements. Not before.
You say awesome, I say layers upon layers of opaque incantations I have to remember. Thank god for LLMs.
You're doing it wrong. You don't have to remember the incantations. You just have to remember that they exist, and then google them or ask an LLM when you need them.
If you use something enough you'll remember. If you don't, you just look it up when you need it. This is basic programming, nobody remembers everything.
“Layers upon layers of opaque incantations”
You’ve described software.
And how might you do this in Javascript?
they just said "LLMS"!
My point was that js would be vastly more complicated than these html/css "incantations".
Most front end engineers could do it in JS without ever having to look something up. But the CSS to do it is still obscure to most.
so, why not answer my question and say how you'd do it in js...?
Animating accordions is almost always a bad idea because the content length can make it unbearable.
In general I find animations on the web overused and unnecessary
Seriously. As a user I can count on zero hands the number of times I’ve said “Oh great, I’m sure glad this UI is animated!” - and likewise zero times have I missed it when animation isn’t used. Animation is a way to light small units of your users’ precious time on fire, for zero benefit.
As the other user alluded to, Animations are not actually there for people who are comfortable using a computer. The vast majority of users are borderlines in capable of using the internet these days. Animations are supposed to be there to really help guide these users into understanding what the scary machine is doing when they click it. Can they be overused, absolutely, but i think have an accordion fold out animated is a reasonable case. You gotta remember your average user isnt paying any fucking attention, so drawing their attention to important changes on screen is not only good but necessary. I'd prefer no animations ever, but i also dont own an iphone while the majority of the world either does or wants to.
That's the positive interpretation, but none of the discussions I've had with UI designers or managers have been about adding animation for accessibility, and the zeitgeist of the last decade has been that skeuomorphism (of which intuitive animations are a subset) is passé.
So far as I can tell, all that the stakeholders want from the UI, animations included, is pizzazz.
If it is for those people who barely grasp the slightest thing about what’s going on on-screen, I could grant them that, if they’d let me turn it off. In the days before jailbreak became basically impossible, setting the animation duration to zero was a blessed, incredibly satisfying thing. It’s exactly what I want. Just do the transition in zero seconds.
My iPhone 15 can’t even catch my first 1-2 keystrokes on the keyboard, multiple times a day, but boy howdy does it have the time and the cycles to animate that f*%ker into view. The disrespect for my time and my needs is so obvious.
Animations are also a way to explain causal relationships between interactions and their results, and to help build mental models of software behaviour.
Being related to neither software behavior nor the structure of the underlying problem, animations tend to obscure the causal relationships and make it harder for user to build a correct mental model.
I see where you're coming from: animations are overused and even when they make sense they are made too slow and flashy (because otherwise how would the implementors feel like they did something if it's barely noticeable?)
Animations are like bass in music: most people notice them only when they're missing or bad.
Does it need animating ?
> Animating the details element is tricky. By the spec, browsers don’t natively support transitions between display: none and display: block.
Very hot take; then don't animate them!
Animation in a UI is great - you draw the user's attention to a widget that changed because they might not necessarily notice it otherwise. This improves the UX.
With a details/summary, the animation is not needed and can only make a negative change to the UX. There is no positive change to the UX that animating the details/summary elements would bring. When it is opened it is obvious.
If you really really need to animate the details, instead of animating open/close, instead animate the summary background/text color to indicate that the element has just changed state.
Would I like easy animation of open/close? Sure. Does it improve the UX? Nope.
You can put a transition on details > summary.
> browsers don’t natively support transitions between display: none and display: block.
You say that like it's a bad thing.
When you search text with ctrl+f it also searches inside details elements and automatically expands them!
Ooh, that sounds useful as a pretty mix-in-bad-data method for scrapers. Have a few of these tags do if junk, even though they are hidden it'll look to a scraper that cares about hidden/not like they aren't always hidden so are likely to contain something worth adding to their DB…
I'd need to look into what effect this might have on accessibility, but my gut says "very little".
Fun fact: <details> even works on github and similar sites with markdown-based input. You can post large inline logs in issues without cluttering the conversation.
I used this for a long time, and only now realized that I'm using html embedding, not some hidden markdown feature.
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.
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.
Note that pure HTML and CSS implementations of tabs using <details> and <summary> fail to meet several important accessibility criteria [1].
While you can make something that visually appears to act as a set of tabs, building it accessibly unfortunately still requires JavaScript.
[1] https://adrianroselli.com/2019/04/details-summary-are-not-in...
This is false, recently the details element has gotten support for grouping them: the [name] attribute. This effectively enforces tab-like semantics where only one of the grouped details elements can be open at a time.
This is a quite recent addition and the modern web is evolving too fast so I wouldn't put it past myself for missing this :)
Yay for progress and for JavaScript free solutions!
No, it's still true. I'm aware of that hack, but unfortunately it doesn't solve the problems with pure HTML and CSS tabs.
Crucially, the `name` attribute does not semantically turn a group of <details> elements into a set of tabs. All it does is introduce the (visual) behavior where opening one <details> element closes the others.
I posted a list of accessibility issues with the <details> hack in another comment: https://news.ycombinator.com/item?id=46415271
The pure-css effects I mentioned both don't use <detail>/<summary>.
Same caveat applies to the "checkbox hack" or any other pure CSS solution. You cannot create accessible versions of most complex controls like tabs without JavaScript.
(That first example could be created semantically and accessibly with <details> / <summary> though!)
what about, make it work in pure html and css, and enrich it with js to make it accessible?
rather than not working at all with js disabled
That's actually a common strategy called "progressive enhancement". The only thing is that your order is backwards: you should first make it accessible in pure HTML and CSS, and then use JavaScript to layer your fancy interactions on top.
So, for the tabs example, your baseline pure HTML and CSS solution might involve showing the all tab panels simultaneously, stacked vertically. Once the JavaScript loads, it would rearrange the DOM to hide all but one and add the tab-like behavior.
for "accessible", do you mean getting focused when pressing TAB key?
Here is a non-exhaustive list of issues you'll run into with various pure HTML and CSS implementations:
- Tabs should have an ARIA "tab" role [1], but <summary> doesn't accept roles [2].
- Focusing a tab must activate the corresponding tab panel [3], which requires JavaScript.
- Tabs should be navigable by arrow keys [4], which also requires JavaScript.
I want to be clear that I'm not trying to tear down your work. Your project looks cool and eliminating JavaScript is a noble goal. But unfortunately, as of today, it's still required to correctly build most complex controls on the web.
[1] https://developer.mozilla.org/en-US/docs/Web/Accessibility/A...
[2] https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...
[3] https://w3c.github.io/aria/#tab
[4] https://www.w3.org/WAI/ARIA/apg/patterns/tabs/
> Tabs should be navigable by arrow keys [4], which also requires JavaScript.
It supports this now (with JavaScript). If not, try to refresh the page.
typo: s/with/without/
What is a good reference to learn modern CSS? I seems most books and online resources are quickly outdated.
I really don't know. I'm not a CSS expert. I've just picked up bits and pieces of CSS knowledge from Google and AI agents. These results often aren't perfect, so you'll need to make some adjustments.
You can't actually control the open state properly from markup (the `open` attribute only sets the default state), which is why I haven't bothered with them.
I’m not sure this is correct. The DOM class HTMLDetailsElement has the `open` property, which you can use to read/write the details element’s state. If you’re using setAttribute/getAttribute just switch to the property.
https://developer.mozilla.org/en-US/docs/Web/API/HTMLDetails...
Having to use the property on the element instance, rather than the actual HTML attribute, is exactly the kind of wrapper code I want to avoid if I'm using a built-in.
You need some JS to change an attribute as much as you need JS to change a property. What am I missing?
I hope the command attribute (https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...) will eventually support this out of the box. In the meanwhile you can write a single custom --toggle command which is generic and works with any toggleable element
What kind of control are you looking for?
`open` works just like checked for a checkbox input. You can set the initial state in HTML and CSS can respond to changes in the attribute if a user clicks it. Markup won't have programmatic control over the attribute by design, that's always done in JS by modifying the element instance.
If you specify the same name on each `details` element they behave like an accordion automatically [1], no need for JavaScript. If you set one of them to open that one will be initially open.
[1] https://developer.mozilla.org/en-US/blog/html-details-exclus...
It's not about using it as an accordion, it's about controlling the open/closed state from other interactions.
different things with the same name? O_O
It’s the name of the accordion and matches how radio buttons work. If you want to distinguish them, you’ll give them different ids.
I understand it, just wondering if it is good taste.
On a different note, trying to use an accordion this simplistic is quite terrible.
https://jsfiddle.net/8m0t5af6/
Or this?
https://jsfiddle.net/8m0t5af6/1/
Not very nice.
Out of curiosity, why have you needed to? This has never come up for me.
For a simple example, imagine buttons that opens a modal with a particular arrangement of open/closed accordions for each button.
You can do that with a details element, you just need some code to actually do it. Which I'm pretty sure there's no possible solution that doesn't require some code to do that.
Really don't see what your complaint is.
Do they work well for when you want to preview text? Like show the first 100 characters of a paragraph and then click to expand?
Yes. For example, on Codidact (https://codidact.com), limited HTML access is offered along with Markdown when making posts, and the details and summary tags in particular are whitelisted. I've made extensive use of this in some of my content, for example https://software.codidact.com/posts/289251/289252#answer-289... . If you have NoScript you can easily verify that the expanding sections work perfectly well without JavaScript. They can even be nested, as they are here; and the summary text can contain some other forms of markup without issue. (When crafting the post, however, I had to do some tricky things with whitespace to avoid confusing the Markdown parser.)
Of course. That's the summary part
Details works even when it's set display:contents too, for even more flexibility. Can't animate from open›close, yet, though. That's pretty much my last frustration with it.
I think the CSS support for that has finally landed, though it means targetting a pseudo element instead. Its been a year, so support is probably good enough you don't care if just the animation doesn't happen.
https://developer.chrome.com/blog/styling-details
Note that the transition to `auto` in that post relies on `interpolate-size` which has yet to land on Firefox or Safari, and neither have movement right now.
Last I checked that without JavaScript details / summary has accessibility issues. That is, you need JS to add aria-open or similar.
It’s odd and frustrating that such an essential tag is not defined to be accessible, afaik.
That's not correct. There is no aria-open attribute and the summary implicitly has the correct ARIA state, aria-expanded, indicating that its details element is either expanded or collapsed.
There have been bugs in its implementation, particularly in Safari and differing between mobile and desktop Safari.
Why would you need aria attributes if it's summary tag?
I presume it has to do with AT and how it typically interprets the tag. TBH IDK other than I’ve seen it come up in accessibility discussions / groups.
I needed to recreate it recently because summary element does not allow headings inside, because it has a button role.
You can’t force it to be always open on desktop and collapsible on mobile. That was a deal breaker for me.
The interesting part here isn’t “no JavaScript”, it’s that HTML already covers more use cases than people remember (forms, dialogs, validation, navigation).
I ran into this repeatedly while writing my book "You Don’t Need JavaScript"[0]: most JS in these cases isn’t adding capability, it’s compensating for forgotten platform features.
[0] https://theosoti.com/you-dont-need-js/
Agreed! I assume the reason for the forgetting of the features is that at least some were poorly supported when first released so developers create workarounds that then become the de facto standard.
It has been amazing to see the speed up in release and support of new CSS features over the last couple of years! Even the masonry layout has finally reached an experimental stage
Yup, at this point it feels more like habit than necessity. People learned to build things like dropdowns in JavaScript years ago, so they keep doing it that way.
A lot of devs simply don’t look any further when it comes to what HTML and CSS already provide.
That exactly describes me. I'm not a good frontend person. I got really, really good at building desktop GUIs in Swing (Java) back in the day and really imprinted on that way of doing things. When moving to web, I found the the display landscape really challenging to grok. I read a few books and got to where I could get most of what I wanted done, but it always took me way longer than it felt like it should, and certainly much longer than it took my coworkers. In that period I learned the contemporary patterns of the day and got pretty good at using component libraries with frameworks like React and was finally able to make things look and behave more like I wanted them to.
Because at that point so much of the focus was on javascript and component libs/frameworks, I didn't (and mostly still don't) really follow browser development. I looked into things like web components when they were first talked about but found their DX to be quite sub-par (it was still pretty early days) and haven't really looked again.
I'm personally much more interested in systems, infrastructure, devops, and all things backend, so for me frontend is a necessary evil to enable me to surface controls for my stuff to users. It's not that I don't want to stay up to speed and current, it's more that in my limited bandwidth I'm more focused on what I care about. That leads to exactly the pattern you described: I learned and got comfortable with a certain paradigm in a different time, and those ways are quite engrained.
Anyway, thank you for your comment. It really helped me identify a blind spot I previously had (which I intend to rectify) :-)
Thanks for sharing that! It’s a super common story. Frontend patterns moved fast (especially for the last 3 years), and not always in a way that encouraged checking what the browser itself could already do.
If you want to improve a bit and discover more what CSS and HTML can do today, I also try to post daily on my LinkedIn: https://www.linkedin.com/in/theosoti/
Very interesting book! These are the types of programming books I wish that were more abundant rather than "Learn X framework/language," those that solve/discuss interesting problems. Just bought a copy.
Indeed the "Learn X" books may even have a vested interest in not revealing rarely used features, so that you learn to reimplement them in X.
Thank you, it means a lot!
I originally started writing it because I was tired of books becoming obsolete every two years while the underlying problems stayed the same.
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...
My main beef with datalist is that there's no easy way to show and allow only text (e.g. Beverly Hills), but have the actual value selected be a number (e.g. 90210). In other words there's no analogy to <option value="90210">Beverly Hills</option>.
That and there's no HTML way to interactively load results. Or are you really going to serialize half a million records to HTML and transfer it all every time the relevant block is added to a page? What if it sits in the header or footer templates?
This would be possible in XSLT, if only browsers would implement the latest spec rather than abandoning it all together.
Right, I sort of expected there to be an attribute for an url.
But then you would want to send other form values along with it which might make things more complicated than it should be?Static could be better too. When search engines first started building these auto complete dropdowns the multi word input was really the killer feature. To have something like "green toyota" you would have to generate an element for all color and brand combinations? And the you want it to work for "green toyota corolla" and you get an abc kind of list length.
Perhaps a wildcard would have been fun or regex options.
Indeed, and if I have to build a component for it in JS anyway, I'm highly likely to just reuse that component everywhere I need it rather than have to build, style, and test different implementations in the same app.
Half a million might be pushing it, but you'd be surprised how much you can inline without any penalty these days.
> Each <option> element should have a value attribute... It can also have a label attribute, or, missing that, some text content, which may be displayed by the browser instead of value (Firefox), or in addition to value (Chrome and Safari)... The exact content of the drop-down menu depends on the browser, but when clicked, content entered into control field will always come from the value attribute
This seems... underspecified. Not ideal that Chrome/Safari aren't aligned with Firefox here, and that there is no standard way to only display the label
[from]: https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...
And styling! The default styling of datalists in most browsers is just ugly.
Open an issue with your browser or OS
Default styling being ugly is often for backwards compatibility with older sites so their look stays as consistent as possible. For that reason opening an issue is likely a waste of time for GP and for the devs.
They also are most certainly quite aware of how the default styling looks in their browser. It wasn't an oversight. That's not to say it doesn't pain them, it often does, but it has been intentional
Usually it looks however the native OS toolkit looks, just like everything else in browser. This is pretty new (and not well adopted) tech so it's not about legacy styling considerations (like, say, the default CSS for text being so awful) but rather that the OS no longer looks the way people want it to look by default.
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.
Technically native selects do have a very rudimentary form of filtering: start typing text with the select focused and it will auto-select the first matching option.
E.g. if the select is a list of US states, type "N" and it will jump to Nebraska. Continue into "New" and you'll get New Hampshire, etc.
This is better than nothing (and I personally use it all the time) but not a patch on an actual proper select-with-filtering which, yes, you still need JS to implement properly.
On my android phone it just didn't show anything in the drop downs.
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.
Does it bother anyone else that it links to Codepen instead of just putting them on the page?
Like I get this is a blog system but it still feels odd, especially for a "use this plain HTML"-style post...
It doesn’t really bother me.
It seems to link to the authors codepen. If you us code pen you can bookmark the snippets. Codepen colorizes the html/css etc.
Link rot is a thing though, so it’s not always ideal to have dependencies on third party urls staying the same.
Bothered me greatly. Should have done on-page AND a link to codepen for you to play with
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
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
Just been through several frontend interviews in the last few months, where it's clear that they still judge a developer's JS skills (especially React) than being semantically correct on HTML elements.
Every question/exercise is centred around how well you know React hooks, effect, memoization, modern css-in-js etc. Given I've been working with Astro recently, in one interview I talked about DOM APIs and I can see the interviewer raise an eyebrow. In later stage, even I that passed the exercises, still didn't get the job.
Remember that a large part of hiring is finding someone who fits in an existing team. A team that uses react won't appreciate someone choosing to use native DOM APIs instead of a react component.
In every React team I've been part of we've wanted to use as little react as possible and use native DOM apis when possible. React would be used purely for state management or interactivity.
I feel like teams that have used react enough learn that the less React you can use the better :) it's a great tool, but most teams use it because it's all they know and they don't know what they don't know about html.
Weird comment, I'm a web dev that has been using react for 10+ years and I prefer using native browser features whenever possible. I'd honestly avoid hiring framework specific devs because the skills required are never about just one single framework.
Also this is just all JS + HTML here, let's not act like it's impossible to learn the most popular frontend tool at the moment.
Eh. I build apps with Preact, but I prefer candidates who know the core web platform. They’ll be more apt to use the right tool for the job and not be baffled by edge cases.
Having a separate css file make small components so much cleaner. I am not against tailwind, but I wouldn't want to use it in front-end interviews.
Because nobody outside of the HN-sphere cares about HTML purism, nor should they.
It's not HTML purism. It's simply recognizing that HTML and CSS have evolved a lot and many things don't need (or are close to not need) JS anymore. This shouldn't be taken as an anti-JS article, everyone benefits from these gradial improvements. Especially our users who can now get a uniform experience.
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.
> 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.
I would certainly agree that using a little JS can get you further than just HTML. But I think that a plain HTML page is far more pleasant to use (and thus, functional) than the JS monstrosities that dominate the Web today. There's a reason people use the NoScript addon: because a whole lot of website designers use JS in ways that make the experience a ton worse for the user.
> There's a reason people use the NoScript addon
To be snarky, do they? The average user doesn't even know what JS is.
Users want websites that are fast and solve their problems, with a good UI. They don't care how it's made.
Make websites that people enjoy using. A good developer can do that with any set of tools, though a no-JS approach is limited in scope.
It's not an either/or. Modern Javascript is actually really nice to write and use, and you can write it in a tight, minimal way that doesn't bloat the page or slow it down.
>you can write it in a tight, minimal way that doesn't bloat the page or slow it down.
Yet most people don't.
There are some problems with the language itself but it's mostly from a users perspective that I find it frustrating.
Of course you can, but most people still opt to pull in a whole framework (React) or heavy library (jQuery) just to achieve what's essentially a few XMLHttpRequests and some DOM changes.
Maybe because it is easier to track one library, react and jsx. I wouldn't use xmlhttprequest since the request api exist.
> 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.
You're overthinking htmx then. I do some fairly complex stuff with no extra partials. Trick is just always rerender and use hx-select and hx-target to slice out the bits you want to update on the current page.
Server always has authoritative state and code is dead simple to reason about.
> You're overthinking [noun]
Yes, almost certainly!
> I do some fairly complex stuff with no extra partials. Trick is just always rerender and use hx-select and hx-target to slice out the bits you want to update on the current page.
Good trick! My only experience of HTMX in production entailed porting Stimulus code, hence the partials, but your approach is obviously much neater. I'll give it a shot, next time it might be suitable.
OT: marquee tags were a missed opportunity to implement horizontal scrolling often used on shopping websites. Now it uses JS to achieve the same.
I have been trying to find other more commonly known UI patterns that could be done natively. The time has long come for tabular data to be put into HTML tables just by referencing the source. Xslt almost did that. Another one is integrating xml http requests with native html. I think HTMz came close to this.
Sounds great <table type="text/csv" src="mydata.csv"> Then have it generate actual html so that you can target th's, tr's and td's with css.
I believe the lowest hanging fruit would be <div src="article.html">
I think formData should also be available as interactive JSON but perhaps it is possible to also populate a form with fields from a json with something like:
Where mydata.json is: And have something like this come out: It wouldn't cover everything but it is very nice not to have the later if you don't really need it.There's a usability and design issue with that as you lose what you're reading as it scrolls off the screen. Also, scrolling is a styling issue and not a document description issue which is what HTML is for.
Note: <marquee> has never been part of any HTML standard since the beginning except the current one which only has it for the purpose of marking it obsolete so people will quit using it.
> marquee tags were a missed opportunity to implement horizontal scrolling often used on shopping websites. Now it uses JS to achieve the same. I have been trying to find other more commonly known UI patterns that could be done natively.
Are you sure you are talking about the functionality of the marquee tag? What exactly do you mean by "implement horizontal scrolling often used on shopping websites. Now it uses JS to achieve the same"?
For a banner-type text "Sale: 50% off until New Year" I can imagine this. And this is possible with almost no JS, by using a CSS animation on translateX. I think you need to pass the initial width of the content one time from JS to CSS via a custom property IIRC, and update that variable on resize, for example using a ResizeObserver, to avoid a jump when reaching the "wrap around"...
But – sorry if this a misunderstanding – I have a sneaking feeling that you might also have things in mind like swipable horizontal lists etc?
This is also possible using CSS in theory (scroll-snap and overflow-auto, and CSS to hide the scrollbars). But last I tried to use it, it simply wasn't good enough to sell it, compared to a fat JS library that did the trick, perfectly, on mobile and desktop.
When it comes to UX niceties, I feel it's pretty common to have HTML+CSS solutions that are good enough in theory, but suck in practise.
For the horizontal scrolling with "snap", I would also like a good JS-free solution. But I feel that the more interactive and complex the UX patterns become, it would be senseless bloat to build a specific implementation into the platform.
I think that "autocomplete" inputs are a good example for this, as discussed in another thread.
I once tried to implement a custom autocomplete using datalist (including dynamically updating the list with xhrs). In the end, the native element had so many issues that it was a waste of time and a JS solution was way better. At the time, that JS solution was Alpine.Js, because it was a b2b app with minimal a11y requirements and JS-allergic developers.
Within an hour, I was polishing keyboard use while the "near-native" solution using datalist was broken in a thousand different ways in every browser and in the end didn't work well at all.
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).
I haven't used it in anger myself, but if you know Elixir and Phoenix you might like Gleam, which compiles to Javascript.
I appreciate the helpful reply, but I think this is precisely the kind of indirection I need to avoid. I'm a sucker for elegance. If left entirely to my own devices I'd probably design a language / write a transpiler of my own, and wind up with exceedingly elegant tooling for websites, and no websites. :)
This is why I don't use Typescript or frameworks in my own projects, I just constantly seek the cleanest abstraction and never get anything done. Using a deliberately messy solution is annoying but at least I accomplish stuff.
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.
I dont think anyone is arguing Google Earth should be pure HTML. But it is equally false you cant do Gmail with HTML only.
There are things that HTML could do, and should be doing, that is not done or not yet possible simply due to hype and trend from browser vendors. We could continue to polish HTML + sprinkle of Javascript to its absolute maximum before hitting JS Apps. Right now this is far from the case.
Gmail with html only would not be a nice experience. Modern gmail is really bloated but it's actually one of the few web apps I have no problems with.
Gmail used to have an html-only version if I remember rightly. Perhaps still does. It was faster and perfectly usable.
Hey the email services has just proved you could offer better than Gmail experience with HTML + small dose of JS. Another example being the new FE on Github.
At the end of the day it isn't really the tech that is the problem. Is how people use the tech. And for thousands of different reasons keeping it simple has always provided better experience evaluated on the whole.
> Another example being the new FE on Github.
Github's old frontend was mostly HTML with a bit of JS, their new frontend is react. The old UI had its bugs, but it was much better than the react version in my experience. I still commonly find the UI out of sync with itself requiring a reload, but now I also frequently wait for the page to load and viewing large diff's is a performance nightmare.
Not really. I used the HTML version for well over a decade and it was absolutely fine. I guess if you need fancy animations, maybe that doesn't suit you, but I came through Pine and Eudora and Gmail HTML was a million times better than both of those and entirely sufficient for a media that dates back about 50 years.
Gmail used to provide an HTML version. It got removed only recently
Actually, I do think that. Wouldn't it be lovely to have an image format for truly enormous images and have the browser request only the chunk currently visible? It could just be a container format with jpg's in it. Let the file system figure out that x/y means tile number 56436.
You could provide multiple image versions for zooming to get to the TB scale.
Computers are really good, performance is astonishing, no reason why we should never be able to use a TB size image. Never is a really long time.
Have epic panoramas, detailed scans from paintings, extremely easy game design and maps that just work.
I assume you mean htmx. It doesn't have to be either/or. You can supplement htmx with Javascript.
The core idea with htmx is that you transfer hypertext with controls and structure built in, not just a JSON blob that requires additional context to be useful.
I have just shipped a very useful and interactive app surprisingly quickly for my customer using just htmx with a little Javascript.
It shouldn't have to be this way though. There is no reason html can't do things it needs to do to build complete apps. We could use reasonable defaults to allow a new type of html markup without JavaScript.
All the http verbs. Decent html input controls What else?
Depends on how complex it is meant to be. Just like many wordpress sites that could easily have been static websites, many javascript heavy sites could have easily just have been using htmlx.
If your need really, goes beyond what htmx offers, then you may need Javascript. But in my experience people tend to use the tools they know for their job, not the tools that would be best suited.
FYI, it's easy to cache the html output of a WordPress site, resulting in essentially a static site with graphical admin, page builder, and all the other bells and whistles.
> Input with Autofilter Suggestions Dropdown
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.
I don't want to be so negative, but we got details and popover after literally decades, and we still have datalist presented as a plausible option? Html is so underdeveloped and the first we all agree on that the first we'll pretend from committee real advancement
The committee is an unsolved puzzle as old as mankind. That's not to discourage you. If you do solve it it would remedy almost all of our problems. If the solution could be found instantly in 5 seconds someone would have solved it already. This one is going to take some actual thinking and modeling.
I know for sure that Apple, who has an important seat on the standard committee, holded back innovation for so long, it's not a matter of finding or not finding solutions. They're failing us for different interests
> I know for sure that Apple, who has an important seat on the standard committee, holded back innovation for so long, it's not a matter of finding or not finding solutions. They're failing us for different interests
Apple isn't the problem.
Apple was the first to ship :has(), which developers wanted for 20 years but was thought to be essentially impossible to implement [1].
Apple pushed to get consensus on how to implement masonry layouts in CSS [2].
And they were first to ship the new specification in a browser you can use right now [3].
This dashboard shows Apple slightly ahead in terms of new CSS features being implemented and interoperable with Firefox and Chrome [4].
[1]: https://webkit.org/blog/13096/css-has-pseudo-class/
[2]: https://webkit.org/blog/16026/css-masonry-syntax/
[3]: https://webkit.org/blog/17660/introducing-css-grid-lanes/
[4]: https://wpt.fyi/interop-2025?stable
Oh please they pushed back pwas for "security reasons" for years. Safari is the browser with most quirks compared to FF and Chrome, it's considered by many the new IE holding back innovation. Sure they implemented some stuff before other who cares of changes that don't disrupt their apple store model? I don't want mansonry layout if not for designers portfolio or blog? I develop serious appa and I want an api to invent my own layout and I want feature parity with native apps
> Safari is the browser with most quirks compared to FF and Chrome
That may have been true 5 years ago and I get developers have long memories—but that's no longer the case.
> Sure they implemented some stuff before other who cares of changes that don't disrupt their apple store model?
The conspiracy theory Apple, whose revenue was $391 billion last fiscal year sees PWAs as a "threat" is nonsensical. Also, new features for the web platform gives developers another reason to create web apps instead of a native app.
In reality, Safari's PWA support is really good; it has implemented 89% of supported PWA features vs 96% for Chrome according to the PWA scorecard [1].
> It's considered by many the new IE holding back innovation
As someone who lived through the '90s and early 2000s doing web stuff, I can assure you anyone who believes "Safari is the new IE" literally has no idea what they're talking about; they're just repeating a meme they don't understand.
I commented about this on HN recently [2].
[1]: https://pwascore.com
[2]: https://news.ycombinator.com/item?id=46338575
> In reality, Safari's PWA support is really good; it has implemented 89% of supported PWA features vs 96% for Chrome according to the PWA scorecard [1].
I remember, I was like, ohh sounds great! So I tirelessly looked for an "add to home screen" button but couldn't find it.
I had to search google to find the answer, you hve to share it!?
weird but okay, so I open the share menu. No such option there.
Again I search, ahh so you have to first edit the sharing options!
The only thing missing from the experience was a warning dialog.
Moral of the story, it doesn't matter if it works if people cant find it.
The 3rd class experience was funny but then they announced they were going to get rid of pwa's entirely.
> The need to remove the capability was informed by the complex security and privacy concerns...
When a 4T company says such things you know it must be hard.... lmfao....
I've never had to explain to an android user how to "Add to home screen". Explaining it to iphone users honestly sounded like I was trying to hack them. It drifts so far from apples usually polished UI that I cant blame them.
They are the new Microsoft, if the web died it would be good for them. We've also tried to have elected bureaucrats make the decisions. Systems giving everyone one vote also turned out terrible as expertise and thoughtfulness drowns in superficial noise. It is kind of embarrassing how well the dictator model works. Personally I prefer to do everything alone. There are no meetings, barely any paperwork, I get to own the bad choices. So far I get along well with my past self and my future self. I do consider it a temporary hack until figuring things out in groups is solved. Robot overlords sounds increasingly appealing.
When building out a new app or site, start with the simplest solution like the html-only autofilters first, then add complex behavior later.
It's good to know these things exist so there are alternatives to reaching for a fat react component as the first step.
Until your client tells you that it doesn't work in Edge and you find out it's because every browser has its own styling and they are impossible to change enough to get the really long options to show up correctly.
Then you're stuck with a bugfix's allotment of time to implement an accessible, correctly themed combo box that you should have reached for in the first place, just like what you had to do last week with the native date pickers.
Right, don't add complexity until you have to.
I'd argue that adding complexity from the get-go to ensure that all users have a pleasant experience from the get-go is better than simplicity at the expense of some percentage of users.
I think it's important for web devs to spend more than two seconds to think if the complexity is necessary from the get-go though.
When building out a new app or site, which means a percentage of zero users is zero.
Have you no sense of craftsmanship?
It’s great to see practical examples that push us to consider what the platform already offers before adding more layers of complexity.
Before anyone wastes a lot of time like I did trying to use the popover API: it is not ready yet. You can do very basic things in all browsers but positioning is still different and/or totally broken per browser.
Yes, HTML & CSS alone won't replace JS. Of course, for complicated form validation HTML is not sufficient. But IMHO it's very important to provide basic functionality in HTML / CSS as much as possible / reasonable. Moving the functionality to HTML / CSS can potentially improve the SEO.
As for positioning, there is an experimental feature @position-try. Here I made a small demo where it handles overflows.
https://waspdev.com/articles/2025-06-29/css-features-web-dev...
But yeah, that's kind of limited if you need nice animations or some other complicated thing. Although it's fun.
Yes, popover's uses are limited without CSS anchor positioning but it will be supported in all major browsers very soon.
In the meantime, there is a polyfill to load in browsers without support.
https://caniuse.com/css-anchor-positioning
The Pentagram at the top of the page does not load without JS enabled.
So it's.. fitting, how meta.
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.
Progressive enhancement is the way to go if you care about technical excellence. For some reason it fell out of fashion.
https://en.wikipedia.org/wiki/Progressive_enhancement
It fell out of fashion because the entire web was consumed by react.
> if you care about technical excellence
Or accessibility.
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.
Don't use it, it totally blows. For another oddity to not use, check out the multiple select: https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...
Expecting users to press modifiers when clicking on these is so funny.
> Expecting users to press modifiers when clicking on these is so funny.
I mean… 5 year olds can figure out shift-click in Minecraft.
Trying to figure things out in a game is fun! Trying to figure things out on a website is a sign the UI sucks.
Learn it in a game, then use it on a website. It's a UI convention, not merely a quirk to a multi-select list.
Modifier keys are used elsewhere optionally on operating systems. But no other form control demands knowledge of modifier clicks. It's simply a useless bit of UI and should not be used.
> I don't see how this can be a replacement for javascript/XHR based autocomplete.
It can't do complex autocomplete. It's ok for simple cases only. I use it with a 25k long list to ease the input. Works well enough for this.
> If we can hand-off any JS functionality to native HTML or CSS, then users can download less stuff, and the remaining JS can pay attention to more important tasks that HTML and CSS can't handle (yet).
You can't. It's only supposed to be used for a limited list.
And even if you allow XHR and add options to a <datalist>, it still has terrible UX.
The <details> and <summary> elements are great, but I think the bigger missed opportunity is the lack of inline examples/demos on the page itself. Would be much more powerful to actually show these working rather than linking to external codepens.
A few thoughts on the practicality:
1. Progressive enhancement is the real win here, not "replacing" JavaScript. These HTML features provide a baseline that works without JS, then you enhance with JS for better UX (animations, state persistence, etc.)
2. The details/summary approach breaks down when you need: - Custom animations/transitions - State synchronization across multiple elements - Analytics tracking on user interactions - Keyboard shortcuts beyond basic tab navigation
3. What about the <dialog> element? That's another underutilized HTML feature that could replace a ton of modal/popup JavaScript.
4. Have you explored the Popover API? It's getting broader browser support and handles a lot of common UI patterns without JS.
The spirit of "use the platform" is great, but the title feels a bit clickbaity - you're not really replacing JS, just avoiding it where unnecessary. Which is good practice anyway!
I’ve tried replacing my modal components with the <dialog> element, but had to reverse everything due to this issue: https://github.com/whatwg/html/issues/9936
In short: you can’t have an interactive popover (e.g. a toast notification) on top of a dialog modal.
I’d love to use the new native elements but we’re sadly not quite there yet.
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.
What "ancient" browser are you using?
Probably something 300 CVEs ago.
Nobody tell them about how much stuff can go into SVG. That can even be inlined within HTML source code.
And you can target it with css! Slap a class attribute on a path element; it’s fine!
One good thing about NOT having JS is what the page can function in Tor Browser's "Safest" mode!
A step down is to have JS only on your domain. "Safer" mode.
Try to avoid web site that require "Standard" to view and run properly.
"Nothing against JS, but it has better things to do than setup and manage your accordions or offscreen navigation menus... "
Perhaps this is referring to "things" such as data collection, surveillance and ad services
It would be interesting to see how Big Tech and other adtech companies would accomplish the same level of data collection, surveillance and ad services without the use of Javascript
As for "nothing against JS", I think some web users (cf. "developers") who dislike adtech and the ad-laden web they perpetuate might have something against it
Gimme a dark/light mode switch. CSS is allowed.
Use a checkbox, d. Define vars for light mode. Override when checked for dark mode with body:has(#d:checked) and can include the dark mode media query too
See https://lyra.horse/blog/2025/08/you-dont-need-js/, via https://news.ycombinator.com/item?id=45056878 (which discussion contains some deeper explanation).
Why would you build a switch instead of relying on the user’s system settings? The only reason I can imagine is that your dark/light mode is not usable/readable so it forces the user to switch
I often use different light/dark settings between apps and my system. Just because I want system UIs to be dark, for example, doesn't mean I want to read long pages of white-on-black prose on your blog.
Then you still don't need a switch on every website. Just set the browser to display the light version and have it ignore the system setting.
That's what we need, for browsers to have a setting to remember our light/dark preferences per-domain.
Seconded. Just because I like to have the browser toolbar dark and GitHub dark doesn't mean I also want to read lengthy articles (LWN) in thin white text on a black background.
My specific usage is a site to host my own internal training content.
I want to read it in dark mode and give users that option, but I want to present it in light mode because dark mode suffers poorly from video compression when screen sharing.
I currently have a JS toggle for it which uses local browser storage, but ditching JS would be nice if possible.
Having it default to the users preference is nice, but you should still provide an override. I sometimes use my browser in light mode while my OS is dark mode. Many times, I find the contrast for dark mode websites too low unless I’m in a totally dark room.
Because I don't want to toggle my whole system theme based on one special website.
Checkbox and :checked are your friends.
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.
like what?
Tabs, accordion, combobox. There is a whole lot more, these are just the ones I can remember now.
If we've concluded that's it's okay to have elements that change/morph, as we seem to with the introduction of things like details, a native tab-like element feels like a glaring omission. Tabs have been a long-standing UI pattern and forcing every site to implement their own is a nightmare for accessibility. (The page you're reading is maybe already in a browser tab.)
I wouldn't be surprised if it turned out less than half of the custom tab interfaces on the web failed from an accessibility standpoint. When considering ARIA guidance, I don't even think it's possible to build an accessible version in HTML alone.
Other people have recognized it's missing. Open UI has a draft spec for it[0] and CSS Tricks has an article from 2001 about Open UI's experiments with sections for tabs[1]. I have no idea what happened on this front, though.
[0] https://open-ui.org/components/tabs/
[1] https://css-tricks.com/newsletter/281-tabs-and-spicy-drama/
For tabs, see: https://lyra.horse/blog/2025/08/you-dont-need-js/#lyres-and-...
As far as I can tell, my implementation there fits the guidelines.
Accordion behavior is discussed in the article in the "Accordions / Expanding Content Panels" section:
> Use the same name attribute on all related details (like radio buttons) to restrict only one open panel at a time
And tabs can be a <details>-based accordion with some creative CSS to adjust the layout (left as an exercise for the reader, but I could write up an example if that would be helpful!)
It won’t have the necessary keyboard shortcuts.
Yes, the tabs in a tabs pattern should be keyboard navigated using arrow keys (ironically not the Tab key).
Also, the summary for the currently open details element will have the wrong state, 'expanded' instead of 'selected'. And while a set of details can now have a maximum of one open at a time, you can't ensure exactly one is always open (without JavaScript) as the tabs pattern requires.
All of those can be done with pure html/css, eg. https://codepen.io/mikestreety/pen/yVNNNm
Yeah this is true at this point. A lot of more complex patterns require JS to be accessible to screen readers.
We still should do more with HTML and CSS! And reach for leaner solutions than React everywhere.
But be careful going for a pure CSS solution for things like tabs if you don’t understand the accessibility requirements.
(I wish the HTML spec would move faster on these common patterns!)
https://www.w3.org/WAI/ARIA/apg/patterns/ is my go to for accessibility requirements of components.
And yes, being able to do all of these in pure HTML/CSS would be awesome. Though we are getting there with things like `details` and the newer `popover` features which should make things like rich tooltips, menu buttons, etc. a lot easier to implement. IIRC, there are also several anchor CSS properties to make positioning a lot simpler.
> We still should do more with HTML and CSS! And reach for leaner solutions than React everywhere.
It's pretty difficult for anyone to completely understand all the nuances in HTML and CSS. It's a big mess that gets bigger and messier every year.
We should have just given JavaScript even more power over controlling the viewport and leave HTML and CSS for the history books.
Because JS isn’t a big mess?
Yes. But first lets reduce the mess from 3 big mess technologies to 1 and then we can working on replacing JS.
It feels like some variation of this post gets submitted here every week.
That’s a bit of evergreen topic. “stop bloating web with js” comes up fairly often and there are those people who think they found a solution and everyone should start using whatever they imagine is “best for everyone”.
In my opinion most of those people struggle with whatever they encountered in ecosystem and just want to find a way that fits them - while also trying to make others do the same.
*“You didn’t want to make things perfect. You just hated things the way they are.”*
And it will continue until node_modules shrinks!
Brilliant I will be adopting a few of these, I have been on a personal quest to reduce js use recently, I feel like I spend more time debugging js than producing the end result.
Most people think that you should remove JavaScript to load your sites faster or for reasons like that. You have to learn to balance things, always use it if you need some good interactivity, validation etc. Don't try to use HTML only to force things.
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.
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.
I was stuck on the backend while CSS3 absorbed most of the functionality of Less and Sass and now I’m trying to play catchup. If there had just been a CSS4 I’d be able to find a tutorial to teach me everything I missed in the interim.
JavaScript is the primary language of the web, HTML is just the payload carrier.
I don't want it to be this way, but HTML has nothing approaching even one tenth the ambition of XSLT and XForms.
If HTML were proposed today, you would be laughed out of the room.
I really try not using JavaScript unless absolutely needed. On my latest project, the whole site actually functions without JavaScript and is server side rendered. However, there's some small piece which I really needed JavaScript for couple reasons.
Basically, I have a site which collects the top STEAMD posts from places like HN, lobsters, tildes, slashdot, bear, reddit etc and displays them in chronological order. I wanted a way for users to block posts with certain keywords or from specific domains. I didn't want to do this server side for both performance reasons plus privacy reasons. I didn't want users to need signing up or something to block. I also didn't want to collect block lists for privacy reasons. So, I resorted to using JavaScript and local storage. All posts within the filter for the date are sent and JavaScript is used to block posts with keywords before displaying. So my server never knows what keywords are blocked.
Site for anyone curious:
https://limereader.com/
Interesting. Nice way to get headers quickly, I'll have a look.
Fun project I'm sure, but out of curiosity, is this something that you can monetize somehow? because the fun only goes so far.
The Popover API looks really cool. Could see it for tooltips or lightboxes.
This is helpful when development revolves around static environment.
What would make this super easy to adopt?
A simple page which shows what native components are available with/without the need for polyfills for a given browserslist config
why are people so obsessed with restricting details/accordion elements to only one open at a time? let me open what I want to
It seems like an oversight that there isn't a native way for a popover to be activated by hovering over the target element.
i like the points the article makes, but i really wish it used looping videos instead of actual GIFs
i don't really see any reason to use GIFs here; any widely available video codec like H.264, VP8/VP9 or AV1 will result in significantly smaller file sizes, look better, and will allow enabling controls for seeking and play/pause
I love semantic html. It feels so much more modern and efficient than all of these fashion-driven front end tools.
I am reading the CodePen example for summary/details. Especially the CSS part.
Its so easy, like a breeze!
My personal pet-peeve everytime a "you don't need JS" post comes up on HN, is the disconnect between the interface designers and the developers. In my dayjob as a (mostly react) freelance contractor doing B2B and LoB apps, there are always UX designers coming up with the screen- and interface designs. I don't think any project I ever were, could have matched a screen design I was passed without JS. Whether it being business requirements (has to work in IE, or nowadays has to work in Edge), or simply hard visual design choices.
My favorite example is that of a date, date-time or date-range picker. Yes, there are HTML native elements. But they look absolutely ugly, styling only goes so far, and good luck with requirements such as "oh, but in the popup on the date-range picker, add a topbar with 3 buttons that trigger preselection and a dropdown". Now you can argue and communicate back that we save a lot of technical complexity in the stack if we stick to the HTML native solutions. But all those discussions basically end up managers and UX designers having no clue about the actual complexity and savings (time and money wise for future maintenance) and simply don't care.
And if I am the one telling them "Look, in the HTML native date-time picker, you can't add custom elements, you can't fully customize every bit and piece of behaviour so change the screen designs" they will just fire up random corporate website XYZ and show a similar version of what they have in mind (and it is always JS-based) and suddenly it looks like me being unable or unskilled to achieve something, that is clearly doable as others have done it.
Now not all is nice and shiny in the JS/React world. We use MaterialUI in a current project, and the commercial MUI-X DatePickers. They also come with their limitations, but it is just they are far more powerfull and customizable to actually meet the requirements and demands of UX and management, compared to the HTML versions.
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?
> Writing a web server in C++ is a way to get excellent performance. So why don't most people do it?
Because they already wrote it in C.
Apache and Nginx are both written in C. Together they run 57.7% of all web servers:
https://w3techs.com/technologies/overview/web_server
JS got popular because some devs were trying to realize a world where the same code can be shared on the front and backend. I think on the surface, it was a noble goal with good intentions. Having only one programming language to handle is going to create some efficiency gains when you work in a large company with thousands of devs who all need training want to share knowledge as a larger organization.
In the past decade, we went full JS as an industry and now we’re starting to swing back. Server side interactivity like Phoenix Liveview, C# Blazor, HTMX, PHP/Laravel Livewire, Rails Hotwire, all of these are different abstractions around JS to make interoperability between the frontend and backend more manageable and they’ve come a long way to closing the gap. Advancements in HTML/CSS standards also deserve credit for closing the gap but we’re still not quite there yet.
But at the end of the day, the web is dynamic. As new tools and techniques are discovered, the industry will continue to evolve and certain “hacks” will become new standards and ignorant newcomers will reinvent the wheel again to achieve some crazy interactive design because they didn’t know any better! And it wil work, mostly.
Until the way we interact with browsers changes, I feel that we’ll continue to bolt on new features over time and the web will continue to evolve. Just like the iPhone, a surge of use of smart glasses could change the computing paradigm or perhaps its some other device entirely.
So you can (and should!) try to optimize for today, but trying to optimize for tomorrow will always carry the risk irrelevance if the market pivots quickly. Bleeding edge is risky but so is falling behind.
In my mind "Just HTML" does not include CSS.
The problem is that CSS continues to be a pain in the ass, even as it evolves. There is no other reason why something like tailwind should have the traction it has.
The switch from everything tables to everything divs was one of the worst for usability on the web. Every day I run into a table of data that doesn’t sort, copy/paste, search, resize columns or any of the very trivial items to do with tables. It always infuriating.
<blink>
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.
Free book and open source libraries if you are curious: https://dataos.software/book
> Nesting the elements is a truly hideous choice. The summary is part of the details?? I thought they were opposites.
It gives them a semantic connection. Last I checked, HTML isn't really based on giving special meaning to combinations of sibling tags. A summary is part of the thing that conceptually requires detailing.
> If you find 1000 websites using a toggle I doubt there is one using an ugly arrow like that.
I think the default looks fine. But TFA clearly explains right there that it can be styled. (Specifically, by styling ::before on the summary tag.)
> The default styling gives no clue about it being clickable?
You asked what the arrow is, and then asked about the lack of indication that the summary header is clickable. The arrow is exactly that indication.
> Maybe I'm dense but I also want my url to reflect the state of the page.
If you scroll, should the fragment automatically update as you scroll past anchors? I think I'd find that quite annoying.
Thanks for your thoughts.
>It gives them a semantic connection.
I understand the logic but I don't agree with it.
An element should be visible or not be visible. There shouldn't be a 3rd state. It is a new idea and it is bad. Try writing a polyfill.
Even if you insist it shouldn't be the only way to use it. There should at least be a <summary for=""> so that the clickable thing can be put wherever one likes.
The goal is to make things convenient for the user not to sacrifice usability for some semantics.
But if it was a summary is not semantically part of the details.
I don't actually care about that, I just want to use it.
A summary should be allowed to have hyperlinks. I passionately hate clickable paragraphs but if you are going to do that at least change the pointer into a hand.
I could put the <summary> under the summary the way almost everyone does but then the name makes no sense.
>I think the default looks fine.
A summary (longer than a few words) starting with an arrow looks weird.
The arrow would be reasonable UI for fold out menus but those are not summaries.
I would want some margin on the left for the <details> of the sub menu.
What I don't want is to also have padding on the parent(!) menu item. Seems like a very confused parent child relationship.
>> Maybe I'm dense but I also want my url to reflect the state of the page.
>If you scroll, should the fragment automatically update as you scroll past anchors? I think I'd find that quite annoying.
Depends, if the thing is infinite scrolling and the user needs to send a permalink it would be nice to update it.
If I have an accordion with say frequently asked questions it would be necessary to link to the items.
It often isn't needed but I can't really picture when it would be annoying.
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