The only hard thing is still to position a popover near the element that triggers it, such as when you want to create a context menu that has to render above/below the button that triggered it. There is anchor positioning in CSS now but support is still limited and I find it hard to wrap my head around.
LLMs are also terrible at these new standards. If they even know about them, they often think they're not baseline yet and they have almost zero training data compared to the giant mountain of weird JS and CSS that people had to use before the introduction of these standards.
I was going to suggest anchor positioning. I found it difficult to wrap my head around too, but once it clicks it's pretty simple. As a bonus, you can use it to position many other things than just popovers.
Testing for accessibility and on mobile devices has a tendency to derail the best intentions. What tools are you using for those concerns? I'm not asking because I need advice. I'm asking because I want to know what you or your team did.
>Just a heads up but datalist is not really a great solution if you need a strong contract. The user can still type whatever they want into the field and there is no fuzzy filtering or typo mitigation. Once you add those requirements, a library that gives you a more fully featured combobox is likely going to make a lot of sense in your project.
It is true! HTML can do a lot of cool stuff, it might get you 100% of the way depending on what you're doing. But if you have a lot of forms where users pick from a value set, and want to enforce no other strings and get a good search experience, datalist does not get you there.
So, let the user type, then validate in javascript if you want instant feedback (by changing colors, say, to red / orange), but ideally don't fully block it from being seen by the server. And do the real validation on the server side. This is what I found to be fairly robust, while allowing mitigations if a bad rollout breaks something (delivering to clients is slower than updating something on the server side, most often).
I’m not advocating for willy-nilly package inclusion, just highlighting a current shortcoming of datalist that is often not mentioned in these sorts of articles.
Hopefully these and others modern HTML features gain adoption, along with realizing perhaps a Single Page Application isn't necessary in most instances.
I don't often have to write frontend code, but when I do, there is very little in terms of interactivity you cannot do with HTML these days, worst case a little sprinkle of something like HTMX.
(+1)
It's a small problem compared to the ease of use for development you can gain via Blazor, so I don't see any reason not to solve it.
Even if a site doesn’t monetize with Google Ads, there’s a decent chance it’s pulling a script from ajax.googleapis.com, and Google still knows that you visited the site from the Referer of the script download.
For some multi-country companies it makes sense to have all admin pages in English no matter the underlying OS language. Imagine sending a screenshot where the OS date format is different from what everybody else expects from an English page.
But yes, there's also a very good argument to be made in favor of having such localized elements follow the content's `lang` attribute - potentially with a `lang="initial"` to reset it to "whatever the user has configured for their OS".
Of course most JavaScript-based tables get this wrong, too.
It's really easy to do this with server rendered HTML. Put a link with the sort param in the column headers and be done.
It does make sense in one situation, if the table is a large server-side paginated one and the sorting is really an ORDER BY clause. But for a basic table that fits entirely on the client, it doesn't make sense at all. There are tiny JS libraries that will make <table>s sortable when you add a particular class name.
HTML describes layout, CSS describes style, JS adds interactivity.
Want sortable tables? Get a jquery plugin and spend five minutes, done.
This was all solved a decade or more ago.
I want sortable tables without having to rely on a third-party plugin to a third-party library. HTML describes content, not just layout. It would be a `sortable` attribute on the table, just like you already have attributes that have nothing to do with layout such as `autocomplete` or `aria-*`.
News to me.
If HTML had <inline> <block> <column> <row> or <grid> tags, sure. But CSS determines the layout via display/position properties.
https://css-tricks.com/covering-hiddenuntil-found/
https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...
So you could use it for additional notes, things like "view pricing terms" or "show exclusions" on product listings — stuff people need to read only when they need to read it — without it being hidden from them if they search for it.
Though humans will accidentally find it too, so using a details tag with appropriate summary as a warning would be more friendly than just hidden content. It'll still get opened, but the user at least has a way of closing it again afterwards.
Also before using it I'd want to check what old UAs including accessibility tools tend to do when they hit a value that they don't recognise for the hidden="" attribute - would what they don't recognise as a valid value result in defaulting to the content being hidden or visible/read/other?
I think the big issue with some of items listed is not all the browsers either implement it or they implement it differently. I'm sure your first instinct will be Safari but Chrome, while it may implement a lot, tends to do it quite different than the others. The date picker in browsers is one feature that comes to mind.
HTML can do that. yes. but adoption? welp, I don't really care nor will I use it unless I have to. I will use whatever was available in practice and continue to use them.
Now everybody needs to support it and nobody can really use it.
I’m talking about the features in work like media controls on dialog buttons.
And the date/time picker controls are too limited for many applications.
I guess the best way to render it would be exactly like `<select>` when closed, but when opened there should be a search box where it'd normally show the first option.
Clicking search would call a javascript function, which could then adjust the set of available options via the standard DOM APIs.
Alternatively they could add support for a special element `<selecthead>` which can contain whatever you want, which would render fixed at the when the drop down is opened and can be interacted with like normal html elements. Then you could place your own search fields inside.
It’s all binding. This is what JavaScript is for: dynamic content.
Wait, that wasn't what you meant?
Why are we cool with popups again? Anything that interrupts and blocks content is annoying, and is nearly guaranteed to make me leave immediately. It can be used responsibly, but it almost never is.
a bit off topic but wish we could bring back <frames> and <tables>. just good old fashioned stuff from the late 90s
Adopting them makes a future with multiple browser engines more labor intensive and unlikely as the number of standards targets one is required to support grows and it becomes a game of asking yourself what sites you want your browser to support.
If you don't have a lot of experience in web software, you might think, that's a silly thing to think about, but I think it's that level of maybe exceptional thoughtfulness that has really profound ramifications. If you do have a lot of experience in web software and you think it's silly to think about, you suck.
Hard pass, that's essentially unusable.
How you handle it is project-dependent. But if you're doing a real web site, not an SPA, you can show an error/help page, or re-load the current page with the error/help message.
FWIW I find the native date picker to also still be quite poorly performing in practice, despite quite robust browser support. I wish it worked better but for many reasons, I still see plenty of users (or bots?) who submit dates in the wrong format for whatever reason. My current hypothesis is largely focused on password managers though since they will often do whatever they want directly in the value attribute of an input element.
Hopefully, never. There's enough ad-blocking arms race as it is.