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?
That it might look more like it is intended for human consumption where the others might get their content filtered out due to looking like an obvious trap? More so in the case of the detail tag. Of course they might not be filtering on that sort of thing at all, after all there are many cases of content for humans being hidden that way until activated by script and they won't want to be filtering those out, so it doesn't actually matter and the key will be not showing the otherwise pointless content to human viewers.
My guess is there was a desire to make Find-in-page automatically expand <details> elements and someone realized they could make it also work for custom disclosure widgets by giving the boolean attribute `hidden` an optional value.
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.
But this can be done in any JavaScript framework and ofcourse Vanilla JavaScript. It takes some effort, but creates a much better user experience.
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.
https://developer.mozilla.org/en-US/docs/Web/API/View_Transi...
https://view-transitions.chrome.dev
Best part about it is how gracefully it degrades.
And for some front-end form field validation in the spirit of htmx, ParsleyJS[0] is quite nice. Below is one way to enable the former to support the latter:
htmx.defineExtension (
'parsley-validation',
{
onEvent : function (name, evt) {
var allow = true;
if (name === 'htmx:load')
$(evt.target).parsley ();
else if (name === 'htmx:confirm') {
var theForm = $(evt.target).parsley ();
theForm.validationResult = allow = theForm.isValid ();
if (!allow)
evt.preventDefault ();
}
return allow;
}
}
)
It’s all binding. This is what JavaScript is for: dynamic content.
The declarative actions API is currently only used for popover, but it's been discussed for over a decade to allow SSR of rich content that's interactive before script loading. See also https://developer.chrome.com/blog/command-and-commandfor
For a long time I also pushed back on these interactive APIs because script is a better primitive and every site seems to have quirky requirements. I've come around on it though because there's huge demand for SSR again and businesses are seeing the value in very fast TTI.
I do still think the date picker API is a disaster. Everyone actually needs something much richer than the system date picker. Travel websites want ranges. People want to put dots and day highlights. I wish they'd fix that next.
>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.
https://github.com/minimaxir/hacker-news-undocumented#flaggi...
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.
IIRC Chromium based srcset will never “downsize” to a smaller image, whereas <source>’s media is like a real media query.
Use if you want jumpscares at specific sizes lol
My blog has some code that searches for <img> tags just after markdown conversion, then uses the src to find similarly named images (image×1.jpg, image×2.jpg, etc.) to use in <source> tags.
https://github.com/theandrewbailey/gram/blob/master/gram/src...
https://github.com/theandrewbailey/gram/blob/master/gram/src...
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.
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.
News to me.
If HTML had <inline> <block> <column> <row> or <grid> tags, sure. But CSS determines the layout via display/position properties.
<div> is block
<table>,<tr> and <td> are your grid, row and column.
CSS improves on describing layout with positioning but HTML was still doing that before CSS even came along.
> explicitly and implicitly describe the layout of an HTML document.
No, this doesn't happen.
> In fact, "HTML" itself is an acronym (HyperText Markup Language)
Duh.
> in which the "Markup" describes the function of HTML to "mark up" text in a similar way that editors once did in the print industry, describing which parts of the text should be bold, italicized, etc. or divided up and in what way.
Which has fuck-all to do with the layout.
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-*`.
It's all fine and dandy until marketing bros decide to shove all kinds of shady modals into that JS file. The JS side is not exclusive to trivial interactivity.
It's open source software. You can see what it does, and you just put it on your server. We're talking about pre NPM javascript here, no continuous deployment, everything is vendored and local and no one is going to change that file without your knowledge and permission. And if someone does, you have much bigger problems on your hands.
What you can't own and control is the browser vendors and how they choose to implement things, or not to. You can edit a JS file to your specific needs, but you're stuck with whatever the browser decides.
There is an incentive to use HTML for common interactivity purposes.
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.
What are some good ones?
It is far more resources hungry when dealing with beyond 50 rows or more.
Puts needless pressure on backend.
It is not a good idea when sending whole dataset to client is feasible/better choice.
Of course most JavaScript-based tables get this wrong, too.
But thinking about it: Is there a precedent for HTML to be able to include information that instructs the device to present the DOM out of order? Maybe it's out of scope for HTML to have information about presentation order, when the order is supposed to be implied strictly by the DOM hierarchy itself.
Of course, CSS can visually reorder stuff (e.g. `order` on flex/grid items), but MDN has accessibility warnings regarding the use of `order` and visually presenting the data in an order not reflected by the DOM. So, maybe sorting is best done by reordering the DOM after all.
Yes, it can be done with JS, but nothing is going to beat the browser engine for frequent DOM manipulation of that sort. It's also just one less dependency to have to pull in.
https://css-tricks.com/covering-hiddenuntil-found/
https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...
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".
Hopefully, never. There's enough ad-blocking arms race as it is.
Unfortunately, thinking about it in terms of game theory [0], I believe this is a good thing: I don't want most websites migrating to canvas-like APIs for rendering. My web browser is my agent and I'd like it to mostly render DOM-rendered pages with CSS styling and, perhaps, funny JavaScript that doesn't track me around.
Also, I wish Figma and Google Docs were just offline-usable desktop applications. Both are great _products_ and I use them, but using them on a browser tab makes me unhappy.
> My web browser is my agent
It's very likely not anymore, otherwise Chrome wouldn't have pushed for manifest v3
> I wish Figma and Google Docs were just offline-usable desktop applications.
I wish this too, but since we have decided app distribution to be web based, we need serious tools for making serious apps
> stop pretending you have capable people that spend a day on discussing effects in react.
> have pushed for manifest v3
> since we have decided app distribution to be web based
Tangential uses of the dom, the core app is on the canvas
> I don't use Google Chrome.
Who cares? They have an almost monopoly and they dictate what to implement on the web, it's already happening that many sites don't work on firefox because they've been only optimized for Chrome. And btw Firefox will implement manifest v3 as well. If you're not using Firefox or Safari you're still using chromium. We don't even have the capability anymore of developing alternative browser engines, the spec is a monster and the various attempts are still very far away.
> No one has decided this, it just happened because web browsers were in the right place at the right time
Exactly and since this is the current reality I don't see why we couldn't have better browser tooling for rendering near native stuff like we do on desktop frameworks. Developer tooling for the desktop already exists since ages but web folks have injected desktop apps as well with bloated stuff like electron
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.
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.
It's true, the amount of work that would be needed nowadays has made the idea of building a new browser engine almost impossible (I don't know how the Ladybird devs are getting on). It's a reason to encourage people to support Firefox on desktop, since just about everything else is based on the other browser engine. I still miss Opera's Presto - we don't want to lose another one, or there'll be no competition at all.
But as we've already crossed that threshold where the workload is preventing new engines from being built: choosing not to use new features, after they've been added to all the existing browser engines, isn't going to help that situation in any way.
It's just a comment on the Internet, you don't have to take it so seriously.
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.
Wait, that wasn't what you meant?
If it's part of a paragraph of insightful commentary, it's meaningful. On its own it's not, it appears as though the poster chose to copy-and-paste a cliché instead of bothering to tell us what their specific disagreement even is (perfectly reasonable sarcasm from the sibling comment notwithstanding).
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.
Supposed to be real handy for tooltips too, but haven’t used that myself yet.
Edit to avoid potential confusion: these are separate from modal dialogs, think more like very small popups anchored to one point on the page that still allow you to interact with everything else. Theoretically you can make them modal, but it would be silly to - you’d be better off using <dialog> and the invoker api
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.
Be gone, trollbot, if you ain't have anything better to say
"Better" in my case is being able to move fast by implementing quickly, test fast, and move on with my tasks.
HTML might be "better" in terms of standards, but if nobody follows it, what good is it?
https://austingil.com/animating-details-element-with-only-cs...
https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/S...
Here's an example of "show-modal". It also has an opacity transition.
https://codepen.io/ccwilcox/pen/vEKXeER/b705840fccd607237a4e...
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.
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.
It's a niche B2B SaaS app and luckily we know most of our users personally. They all use modern browsers, usually Chrome or Edge on Windows. There is not a lot of mobile usage although we do support it.
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.
Here's a live example: https://www.w3schools.com/howto/howto_css_dropdown.asp
I'm not an LLM, but that was my immediate thought - how new does a browser have to be to support these and which browsers am I excluding by using these features?
If you put something like this in your popover class, it will resolve to the button that called it when position-anchor is not set:
top: anchor(bottom);
I'm not sure how widely supported it is but I've been using it in Firefox/Chrome.
I really wonder if AI coding is just going to lock us into 2024-ish era languages and libraries forever.
It's exactly like trying to acquire a bootleg of a movie, but all you can afford is a single blurry jpeg taken from the back row of a theater.
What's worse is you're an alien who wants to understand life on Earth by watching this single movie. That's how far away we are from AGI.
It doesn’t have to be that way.
You could create a Skill [1] that tells the agent to use modern css; the newer models like Opus 5 are probably much better with modern css.
Google released a set of skills at I/O called Modern Web Guidance [2] that steer coding agents to use modern css and best practices.
[1]: https://www.skills.sh/paulirish/dotfiles/modern-css
[2]: https://developer.chrome.com/docs/modern-web-guidance/get-st...
Wrapping an .md file in all this circus, with lingo carefully designed to hide the fact that under the hood you're really just dumping another text file into the LLM's context , helps nobody but people's AI psychosis.
But I guess "my LLM can use skills" sounds a lot cooler than "my LLM can read text files", so we'd rather keep pretending really hard.
Some terms and ideas are just shit, especially in the early stages of something new.
Skill issue? I mean, I wonder if adding a skill to use these newer standards can push it over the edge from the crappy JS it was trained on.
On positioning: we got farther with CSS anchor positioning once we stopped treating it like absolute offsets and started from "this is the preferred edge, then let the browser flip." Still awkward for nested context menus, but far less brittle than measuring getBoundingClientRect in a resize observer.
This seems like a common enough issue that it would be worthwhile publishing a "Markdown library" of "stuff HTML can do" that you can "call" from your AGENTS.md.
Edit: lol, a sibling commenter shows I am not the first to have this idea! https://developer.chrome.com/docs/modern-web-guidance/get-st...
(They made it a skill, which brings me to another thing I've had on my mind lately: that's annoying if you know when you start the harness that you will want it to read the skill. It's a roundtrip through the model to activate it. But maybe there's a way to fix that?)
(Edit2: Claude says if you activate the skill via /skill-name in the initial prompt, you get what I want)
a bit off topic but wish we could bring back <frames> and <tables>. just good old fashioned stuff from the late 90s
If I clicked it to open it, then if I want to close it, I'll click it again. Don't hide content I might still be reading!
theres no reason for a browser to be an OS/compiler/abi, for remote code.
this is the dumbest shit in the history of computers. why didnt everyone have they torches and pitchforks, when web2.0 became a thing?
All these great built in features, especially typeahead, wont be mainstream until they can be excessively styled.
Firefox uses the native OS color picker, which in Windows 11 still looks unchanged from Windows 95.
However, I do lament the antiquated Windows 95 color picker. It seems less functional than others that I've used.
Well, honestly “most” is an exaggeration, when I think of what NeXT/Apple AppKit was offering around the turn of the millennium already.
It was a tremendous setback for front-end that Web 2.0 put everybody on the very lowest common denominator of UI frameworks, and then we spent decades just poorly rebuilding checkboxes and menu buttons.
Microsoft played a significant role here because they overreached around 2001, thinking their overwhelming desktop dominance will allow them to single-handedly decide the evolution of the internet’s UI layer. So they deprecated Internet Explorer (the browser with 95% marketshare) and put all their engineering bets on proprietary solutions like XAML as the HTML replacement.
Maybe it is useful, but I am not reading it. I could barely read 2-3 lines before I closed the tab. Next.
I'm not sure that I've ever wanted this!! In fact, whenever I encounter something like a FAQ section where every single heading is its own collapsible, I typically expand all from the bottom up so that I can read everything without having to scroll-click-scroll-click etc. Whenever I encounter this behavior it's disgusting and user-hostile and I hate it.
Browsing the web with Javascript turned off makes things much more tolerable on my low-RAM computer. Until a year or two, I could access the vast majority of the sites that I cared to. With anti-AI-bot protection becoming prevalent, this has gotten a lot worse lately.
I've read somewhere that recent versions of Anubis support no-JS mode. I haven't seen it in use much yet. I wonder if that's because sites are still using old versions of Anubis, or because it's turned off by default in the new version, and sites haven't bothered to enable it, or some other reason.
One instance I've noticed is codeberg, which seemed to be using some no-JS-compatible bot protection -- I'm not sure if it is/was Anubis -- I don't use codeberg regularly (I haven't needed an account there yet), so I'm not sure about details.
"AI-bot protection" is the latest boogeyman for driving the Internet towards centralised control, along with age/identity verification and the rest of the DRM "trusted" computing crap. So much manufactured consent. It's sickening to see so many fall for that propaganda, especially those who should know better. Tell everyone who still thinks "AI bots" and not just plain old DDoS'es from those in bed with Big Tech are somehow pummeling their site, that the misdirection and lies are no longer working, and we might see things improve.
Popovers and dialogs are indeed useful; our project's color picker popup has been moved to a popover, which is much cleaner than manually managing z-index and closing it by clicking outside.
However, contenteditable is an exception. While it appears to be a native rich text editing capability of browsers, the implementation varies significantly across different browsers. The same operation will produce completely different HTML in Chrome, Firefox, and Safari. Not to mention mobile browsers with their various unpredictable input behaviors. This is why editors like ProseMirror and Wordgard don't trust contenteditable output; instead, they maintain their own document model and only use contenteditable as an input layer.
While native HTML capabilities are improving, for complex interactive scenarios, such as rich text editing and clipboard parsing, JavaScript is still essential.
Using this tiny lib [2: shameless plug] I wrote specifically incorporating the "HTML Can Do That"-style realisations going into the big rewrite.
[1] - https://github.com/knadh/listmonk/issues/3073
[2] - https://oat.ink
Also, I run in issues where clients like to customize the style of the <datalist> drop-down selector in desktop. However, it could be styled, the element itself, and with the help of a little JavaScript that makes this visible element I lay when needed and accesible.
It’s a collection of short "post-it" notes about useful native HTML, CSS, and JavaScript features. It seemed directly relevant to the thread.
Corrections and suggestions are very welcome!
That said, is _is_ quite nice that HTML can do so much natively. Now that I'm using LLMs more and more to build front-ends I find myself using fewer libraries and leaning more towards native HTML behavior, and it's been a nice experience.
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.
Hard pass, that's essentially unusable.