It even saves you the effort of all the aria control and expanded tags: these tags don’t need them.
We can also use pure css to implement tab panels. A demo: http://tmd.tapirgames.com/demos.html#section-demo-4
Modern css is powerful.
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...
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.
Animating the details element is tricky. By the spec, browsers don’t natively support transitions between display: none and display: block.
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...
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.
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.
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"
2. CSS integrates better with HTML, as it has selectors to automatically bind to elements (yes there custom elements for JS)
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...
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.
The biggest gap is Chrome versions > 2 years old.
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.
You’ve described software.
In general I find animations on the web overused and unnecessary
So far as I can tell, all that the stakeholders want from the UI, animations included, is pizzazz.
Animations are like bass in music: most people notice them only when they're missing or bad.
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 say that like it's a bad thing.
https://developer.mozilla.org/en-US/docs/Web/API/HTMLDetails...
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.
[1] https://developer.mozilla.org/en-US/blog/html-details-exclus...
It’s odd and frustrating that such an essential tag is not defined to be accessible, afaik.
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.
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
A lot of devs simply don’t look any further when it comes to what HTML and CSS already provide.
<datalist json="search.php?q=toyota+corolla">
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.
<option value="* days"></option>
<option value="* weeks"></option>
<option value="* years"></option>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/...
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.
Like I get this is a blog system but it still feels odd, especially for a "use this plain HTML"-style post...
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.
But as much as I hate to admit it, it is very difficult to build something functional today with plain HTML and no/minimal JS. If you want, say, a model form that manages its children as well, you're basically going to end up with a 2003-era ASP-feeling application with way too many views and forms (as seen on your employer's current HR system). Or you use HTMX... and you still end up with just as many (partial) views, but now with so much implicit state that you're veering into write-only code.
I dislike modern JS to the extent that I opted for Phoenix LiveView, just so I could achieve interactivity without ever having to touch JS, but in truth it's not a comprehensive solution. Still had to write a web worker, a bridge to handle things like notifications, etc. Plus the future direction of Phoenix, all in on AI, is worrying.
Honestly, I should probably just swallow my disdain and learn to appreciate and use modern JS, as painful as that sounds. I want to write and release cool things, not get caught up in navel-gazing language wars.
I 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.
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.
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.
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.
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.
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.
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.
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:
<form src="mydata.json">
<table>
<input name="baz" type="number">
</table>
</form>
{"foo" : "bar", "baz" : "42"}
<form><table>
<tr>
<td><label for="foo">foo</label></td>
<td><input type="text" name="foo" value="bar"></td>
</tr>
<tr>
<td><label for="baz">baz</label></td>
<td><input type="number" name="baz" value="42"></td>
</tr>
</table>
</form>
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.
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.
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.
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.
All the http verbs. Decent html input controls What else?
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.
Or accessibility.
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.
It's good to know these things exist so there are alternatives to reaching for a fat react component as the first step.
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.
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.
Expecting users to press modifiers when clicking on these is so funny.
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.
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 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/
> 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!)
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!)
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.
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.
BTW the toggle solution (expanding content) is good.
Its so easy, like a breeze!
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.”*
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:
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.
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.
A simple page which shows what native components are available with/without the need for polyfills for a given browserslist config
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.
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.
>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.
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: