alt.hn

8/19/2026 at 3:11:36 PM

HTML Can Do That

 https://chrisburnell.com/html-can-do-that/

by encyclopedism

8/20/2026 at 6:10:02 PM

Popover, dialog, invoker commands, our entire production app uses these everywhere and it works really well! The fact that dialogs and popovers are rendered on the "top layer" and that nested popovers are also automatically stacked on top of each other and have 'cascading close' shows how well these standards were designed.

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.

by dajonker

8/20/2026 at 6:56:31 PM

> 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.

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.

by nozzlegear

8/21/2026 at 8:27:38 AM

Baseline newly available. For Germany that means 80% vs the usual 90% (I wonder how the Internet looks for those 10% who use ie, Firefox 20 and Chrome 1 or whatever), which, considering that it doesn't really degrade well, makes it pretty much unusable for serious sites.

by Semaphor

8/20/2026 at 11:21:39 PM

> LLMs are also terrible at these new standards. If they even know about them, they often think they're not baseline yet…

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...

by alwillis

8/21/2026 at 1:15:32 PM

Can we stop calling them skills? They're mostly just documents like any other. Call them cheat-sheets or guides.

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.

by chmod775

8/21/2026 at 1:24:50 PM

Skill is the terminology the industry has adopted.

by edgyquant

8/21/2026 at 1:58:33 PM

And people once called radio "the wireless", vacuum tubes "valve", and computer processors "the mill".

Some terms and ideas are just shit, especially in the early stages of something new.

by chmod775

8/21/2026 at 1:18:50 PM

I have started hearing echoes of how LLMs are "conscious" on every forum I go. Strange times.

by WelkinFolk

8/21/2026 at 9:13:06 AM

> LLMs are also terrible at these new standards.

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)

by bjackman

8/20/2026 at 9:17:23 PM

> 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.

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.

by doginasuit

8/21/2026 at 12:23:37 AM

All current browsers support anchor positioning including popover buttons being the implicit anchor. However, the anchor positioning polyfill does not support this, it requires an explicit anchor-name.

by extra88

8/21/2026 at 8:42:30 AM

I believe CSS anchor is now widely supported.

by meerita

8/20/2026 at 8:32:38 PM

> often think they're not baseline yet

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?

by commandlinefan

8/20/2026 at 8:38:58 PM

Support is pretty good in general for these. Click any of the element links in the article and you get taken to the support grid.

by jxf

8/20/2026 at 10:07:54 PM

> 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 really wonder if AI coding is just going to lock us into 2024-ish era languages and libraries forever.

by Wowfunhappy

8/20/2026 at 10:17:18 PM

At least one thing to hold the torrent of churn back just a little. Silver linings..

by actionfromafar

8/20/2026 at 10:29:28 PM

Yes. The maintenance costs of these models are very high. Something's gotta give soon.

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.

by sublinear

8/21/2026 at 12:22:10 AM

> LLMs are also terrible at these new standards.

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.

by jmpeax

8/20/2026 at 6:26:05 PM

I'm curious how many people are involved in the design of your app and what their concerns are.

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.

by sublinear

8/21/2026 at 8:03:05 AM

[flagged]

by maya335

8/20/2026 at 7:47:28 PM

[dead]

by vee-kay

8/20/2026 at 3:28:56 PM

This comment by yurishimo should not be [dead], imo

>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.

by dematz

8/20/2026 at 5:43:10 PM

Thanks for the vouch! The rest of the article was indeed good but I find a lot of value in hacker news comments precisely because someone comes back to the comments and lays out why what I just read might need a different perspective. If you just want to see cool stuff that a browser can technically do, we are all capable of reading the Chrome dev blog, but we come to HN for a wider perspective. Someone telling a war story about how some little tidbit came back to bite them is also valuable (imo).

by yurishimo

8/20/2026 at 5:15:04 PM

I mildly disagree. You still have to validate what the browser gives you. The user could have edited the "strong contract" using browser dev tools.

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).

by honr

8/20/2026 at 6:48:16 PM

GP was addressing the client-side UX, not backend validation, which is an orthogonal concern.

by jonahx

8/20/2026 at 5:45:46 PM

Where did I say to forgo backend validation? Of course you validate on the backend as well, but the better UX would be to prevent the user from entering a bad value to begin with, assuming it fits within your team’s performance budget.

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.

by yurishimo

8/20/2026 at 5:24:09 PM

That solves the validation portion, but not the rest of the UX issues

by c-hendricks

8/20/2026 at 3:42:07 PM

I seem to recall there was a proposal to add such thing to <select>s

by Gualdrapo

8/20/2026 at 4:24:04 PM

I definitely remember seeing a post by a Chromium maintainer talking about starting development on a proof of concept implementation and surveying for semantics.

by bulder

8/20/2026 at 3:46:54 PM

(iirc if you have [showdead] on you can click on the timestamp to the comment and will get a [vouch] option as a reverse-flag, fwiw. i see it and don't have showdead enabled, so enough people have re-vouched it!)

by kotaKat

8/21/2026 at 1:05:41 AM

The field can be enhanced with JavaScript to support filtering or typo mitigation.

by gulugawa

8/20/2026 at 3:19:43 PM

I'm that minutia in your statistics that is still rocking NoScript in 2026, enabling JavaScript on a site-by-site basis, but this is increasingly difficult with the modern web.

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.

by jamescun

8/20/2026 at 3:48:47 PM

Thank goodness you exist, the fingerprinters will be confused as to which one of the two of us went to their website!

by bee_rider

8/20/2026 at 4:22:49 PM

How? There are dozens of us! DOZENS!

by jamescun

8/20/2026 at 4:40:37 PM

How would you count?

by Perz1val

8/20/2026 at 5:04:08 PM

"you don't have to, they'll tell you."

(+1)

by steanne

8/20/2026 at 6:23:41 PM

i'm right there with you!

by jccalhoun

8/21/2026 at 4:02:02 AM

> 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.

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;
          }
      }
  )
0 - https://parsleyjs.org/

by AdieuToLogic

8/20/2026 at 4:27:16 PM

Single page applications are one of the most anoying web patterns i know of. Please just let me have one page for each ting to do so i actually can bookmark it properly.

by gunalx

8/21/2026 at 1:46:52 PM

I remember when it was considered ridiculous to have a page take more than 250ms to complete its loading. Now nobody bats an eye at a 25MB page that takes over 30 seconds to load. I'm sticking with the old ways, thank you very much.

by lo_fye

8/20/2026 at 4:33:57 PM

Once backend and frontend became two separate teams frontend people didn't want to keep asking backend to make logic changes for state, so frontend took things into their own hands. The mistake was making it two separate teams.

by phyzix5761

8/21/2026 at 11:15:31 AM

the frontend team can write a BFF to make all pages render server-side. there is an advocacy group for keeping oauth2 clients out of browsers which gives this idea some _political_ merit. in ways more than one, SPA is not the only solution when a dedicated _frontend team_ is employed.

by impulsivepuppet

8/21/2026 at 12:26:59 PM

The separation of teams happened before the BFF pattern came into existence so all frontend engineers became specialists in frameworks like React. Unless you can do it with React, FE's won't touch a BFF or anything else for that matter.

by phyzix5761

8/20/2026 at 5:00:44 PM

This is possible and, in my experience building them, the norm. SPAs have routers and update navigation state, including history for browser Back/Forward

by tyre

8/21/2026 at 11:54:48 AM

It's the norm to try to re-implement browser functionality in JS but it is very far from the norm for the re-implementation to work as well and as reliably as the native browser functionality.

by account42

8/20/2026 at 5:25:36 PM

Yes true. But also way to often neglected.

by gunalx

8/21/2026 at 12:52:49 AM

Right but most of the time they don’t work. For example, LinkedIn, and instagram. I understand they have apps but… come on.

by preg_match

8/20/2026 at 4:52:42 PM

Ive made SPAs in Blazor that make it a point to update the URL whenever a "navigation" occurs. I also made it a point to ensure refreshing or loading the URL restored the state.

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.

by ThunderSizzle

8/21/2026 at 7:42:12 AM

This. I also create a lot of Blazor apps and I always make sure things like filters are based on GET query parameters.

But this can be done in any JavaScript framework and ofcourse Vanilla JavaScript. It takes some effort, but creates a much better user experience.

by bdhdhduuyd

8/20/2026 at 5:33:07 PM

On the other hand, converting a SPA to a PWA is often a breeze

by culi

8/20/2026 at 6:32:09 PM

One thing you notice running NoScript is how prevalent Google is.

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.

by evenhash

8/21/2026 at 11:56:49 AM

And lucky for Google, browser vendors (including Google) even decided that caches shouldn't work cross origin so this request needs to be made for every site even if you already visited another site that used the same resource.

by account42

8/20/2026 at 4:41:01 PM

This is part of how I judge how well made or how shitty a website is. If it requires scripts from a dozen third parties, then it usually sucks and one can easily recognize when not much effort has been put into making it.

by zelphirkalt

8/20/2026 at 8:27:54 PM

I got frustrated with sites that should just be documents bolting on a pile of javascript libraries, third-party requests etc so I made a standard for sites that are just documents, and wrote a checker for document-only pages. For SSL, the thing that actually changed the web was browsers flagging non-SSL - probably similar is needed here. https://certifiedweb10.org/ if you're interested.

by edparcell

8/21/2026 at 7:23:27 AM

I always try to develop having in mind that some people have disabled JavaScript or isn't running the last version of Firefox or Chromium bases browsers. So if someone enters with disabled JavaScript, keeps having the basic functionality of search, navigate and download. I do webservices for public digital libraries that shares public domain stuff and I true believe that always should be accessible to everyone.

by Zardoz84

8/20/2026 at 6:58:16 PM

Does HTMX work with NoScript? Doesn't it require JS?

by nozzlegear

8/20/2026 at 7:11:00 PM

Nope, doesn't work. Doesn't stop you from making it a PWA, though.

by ipsod

8/20/2026 at 4:38:04 PM

oh my. Looks like NoScript is way better than what I've been using. Thanks!

https://noscript.net/

by djoldman

8/20/2026 at 4:11:20 PM

I'd really wish I could force ISO format for the date input as the current "platform native" is confusing for some users when the OS use a different language than the web page that is shown.

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.

by silvestrov

8/20/2026 at 6:03:17 PM

Alternatively: have the <time> element actually do something by hooking it up to the new Moment API and having it display the specified timestamp in the user's locale. That would at least provide an easy way to have the input format and the display format be the same.

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".

by crote

8/20/2026 at 4:43:30 PM

I'd be okay with regional date format for the user but it always submits as ISO 8601 date format.

by hk1337

8/20/2026 at 6:03:45 PM

That's already how it works, is it not?

by crote

8/20/2026 at 6:36:02 PM

Dealing with this right now. Got some people whose devices are set to display dates as dd/mm/yyyy and the janky pay submission form records it verbatim rather than translate to its internal mm/dd/yyyy format. If it's invalid date it will reject, but a guy submitted for August 4 and got denied for the system recording it as April 8. Spreadsheet MS Forms nonsense. Nobody cares.

by jimmygrapes

8/20/2026 at 3:45:39 PM

Related to this, I’d love that HTML natively support sortable tables. This is a common need but every single time I have to reimplement it.

by hk__2

8/20/2026 at 6:54:48 PM

This is… not obvious. It's only easy if you want the simplistic approach of sorting lexicographically or numerically. But in more complex tables, you will often encounter cases where the data representation for sorting is different from data representation for display.

Of course most JavaScript-based tables get this wrong, too.

by jwr

8/20/2026 at 7:41:49 PM

You could have a `sortkey` attribute, a bit like <option> that has a `value` attribute in case the value you want is different from the value you display.

by hk__2

8/21/2026 at 11:56:05 AM

Even then how does it interact with rowspans and colspans...

by donatj

8/20/2026 at 8:39:56 PM

I had always thought that table sorting seems like the perfect job for HTML, given its data-driven nature, and the possibility of implementing sort information into the attributes of table cell elements.

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.

by dansalvato

8/21/2026 at 12:33:27 AM

CSS now also has `reading-flow` to instruct the browser to change the reading order to match the visual order created by Flex or Grid. Unfortunately, not all browsers support it and it has some limitations.

by extra88

8/20/2026 at 9:37:06 PM

XSL has sorting, so kind of, depending on which document you're referring to when you say DOM.

by ndriscoll

8/21/2026 at 1:08:54 AM

And related to that, native cell recycling for long lists would be nice, particularly with cases where the cells are on the heavy side.

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.

by cosmic_cheese

8/20/2026 at 5:39:38 PM

I feel like there's so few times it would actually work how I want it that it seems like there's little point.

by hahn-kev

8/20/2026 at 4:33:19 PM

You want client side table sorting?

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.

by wild_egg

8/20/2026 at 4:55:53 PM

I used to do this in the early 2000s! Some folks back then would ask whether i was afraid that clicking a link (which loads a "new" web page) would slow things down and create an awful experience for users...but, my team and I would really focus on keeping web pages slim/lightweight to begin with...so it rarely was a problem. I don't think we were geniuses or anything like that, but keeping things light (always and from the beginning) enabled us to "cheat" (like this "hack" of the links in the column headers) in ways that were beneficial but with very low risk. Sometimes it took an extra moment or two at the beginning of an effort...but it ALWAYS paid off down the road, and in many different ways.

by mxuribe

8/20/2026 at 5:15:32 PM

It still works exceptionally well in 2026 and generally creates better and faster experiences than an SPA with far, far less code.

by wild_egg

8/20/2026 at 7:44:28 PM

You don’t need an SPA for that; Wikipedia has client-side sorted tables for example.

by hk__2

8/20/2026 at 5:38:03 PM

I hate what it does to my back button

by culi

8/20/2026 at 5:48:39 PM

HTMX is the solution

by hnal943

8/20/2026 at 6:36:09 PM

So instead of using JS to sort the table directly, now you make a JS fetch() request to sort the table?!

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.

by zarzavat

8/20/2026 at 9:18:15 PM

> tiny JS libraries that will make <table>s sortable

What are some good ones?

by everybodyknows

8/21/2026 at 12:05:15 PM

No to sorting tables where all the data is already available locally.

by account42

8/20/2026 at 7:00:24 PM

Trading one javascript for another?

by nozzlegear

8/21/2026 at 1:30:06 PM

It's not as fast.

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.

by CrimsonRain

8/21/2026 at 12:06:24 PM

It's a bit annoying when the sorting leaks into URLs people share, a bit like if the scroll position would be automatically included there.

by account42

8/20/2026 at 5:46:35 PM

I want tables that can be sorted on multiple columns without triggering a page refresh on every click.

by xboxnolifes

8/20/2026 at 7:24:44 PM

View Transitions are your friend

by wild_egg

8/20/2026 at 4:10:29 PM

That's what javascript is supposed to be for. All of this is what javascript is supposed to be for.

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.

by krapp

8/21/2026 at 12:09:16 PM

HTML has done interactivity before JS existed. No reason to not add support for sorting tables. JS is better suited to only handle non-standard cases where no native functionality exist as browser vendors can afford to spend infinitely more time to make sorting better than you can spend on doing it for one website.

by account42

8/20/2026 at 7:46:50 PM

> Want sortable tables? Get a jquery plugin and spend five minutes, done.

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-*`.

by hk__2

8/20/2026 at 8:13:04 PM

Everyone already complains that browsers are too bloated and now you want to have every browser support sortable tables when a single, simple JS file would work?

by krapp

8/20/2026 at 9:40:21 PM

The overwhelming majority of web pages are static documents, and it's a document format, so basic document primitives make sense. Same with something like line charts or pie charts. Bloat is things like USB APIs that present obnoxious security surfaces.

by ndriscoll

8/20/2026 at 8:46:02 PM

>single, simple JS file

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.

by ducktective

8/20/2026 at 8:57:16 PM

What "marketing bros?"

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.

by krapp

8/21/2026 at 2:25:45 AM

My point was, people block js of websites by default. Why? Cause website devs abuse js and don't exclusively use it for basic interactivity of stuff like sorting table columns.

There is an incentive to use HTML for common interactivity purposes.

by ducktective

8/20/2026 at 7:03:34 PM

> HTML describes layout

News to me.

by zephen

8/20/2026 at 7:13:44 PM

That's understandable, because almost no one actually works with HTML directly anymore, but it's true. HTML contains tags like <H> for headers, <p> for paragraphs, <br> for line breaks <pre> for prerendered text, <ol> and <ul> for ordered and unordered lists, <table> for tables as well as <main>,<div>,<header>,<section>,<nav>,<article>,<aside>,<summary> and <footer> to both explicitly and implicitly describe the layout of an HTML document. In fact, "HTML" itself is an acronym (HyperText Markup Language) 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.

by krapp

8/20/2026 at 7:27:36 PM

HTML describes the structure of a document, not really the layout.

If HTML had <inline> <block> <column> <row> or <grid> tags, sure. But CSS determines the layout via display/position properties.

by crab_galaxy

8/20/2026 at 8:06:38 PM

<span> is inline

<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.

by krapp

8/21/2026 at 7:27:41 AM

Suddenly it's 1999

by Zardoz84

8/20/2026 at 10:20:58 PM

Thanks for the downvote, but you're wrong.

> 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.

by zephen

8/20/2026 at 10:39:07 PM

[flagged]

by krapp

8/20/2026 at 11:39:07 PM

> And all you're responding with is invective.

This statement is mendacious, at best. I have explained that HTML has fuck-all to do with layout. I can explain it to you, but I can't understand it for you.

Here, check out what the W3C has to say about it:

> Because HTML conveys meaning, rather than presentation, the same page can also be used by a small browser on a mobile phone, without any change to the page. ... But it goes further than just differences in screen size: the same page could equally be used by a blind user using a browser based around speech synthesis, which instead of displaying the page on a screen, reads the page to the user, e.g. using headphones. Instead of large text for the headings, the speech browser might use a different volume or a slower voice.

(Emphasis in the original.)

https://html.spec.whatwg.org/multipage/dom.html#semantics-2

Also, check out the ACID series of specifications which require and always use CSS, because otherwise, there is no mandate on how a browser should display stuff.

And, just for completeness, here are a couple of quotes from Tim Berners-Lee:

> HTML should convey the structure of a hypertext document, but not details of its presentation. This was the only way to get it to display reasonably on any of a very wide variety of different screens and sizes of paper.

> The separation of presentation from structure is a fundamental principle of the Web. HTML documents represent the logical structure of the document; style sheets provide formatting instructions.

Now, I will grant you during the browser wars of the 90s when everybody was trying to get ahead, some layout elements were stupidly added to HTML, and copied by other browsers. But these came nowhere near close to being definitive layout descriptions, and since at least 1997, the W3C has advocated for separating content into HTML, and presentation into CSS.

by zephen

8/21/2026 at 9:18:29 AM

This article is very close to the idea behind a small website I’ve been maintaining mostly as a reference for myself, but which others might find useful too: https://htmlcat.net

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!

by marcomezzavilla

8/21/2026 at 6:47:13 AM

I'm currently in the process of taking a lot of risk rewriting a large-ish app that I maintain to fully eliminate the use of frontend frameworks (and the larger JS ecosystem in general) and to switch to simple SSR + semantic HTML and CSS.

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

by knadh

8/21/2026 at 2:02:15 PM

Oat.ink is very cool, thanks for sharing!

by lionkor

8/20/2026 at 4:40:57 PM

I started textlog.cc as an experiment to see how far I can go without introducing JS. It turns out, pretty far! If you exclude the Web Push notifications which required a Service Worker script, all the rest is server-side rendered React. As a visitor, with all the hover cards and popovers you would think there is some JS going on, but it’s all HTML-only. I am enjoying very much the constraint and it hasn’t hindered any progress. It’s a proof a lot can be achieved by just HTML.

by stagas

8/20/2026 at 3:27:21 PM

Yeah, I'm a great fan of both HTML and CSS "can do that". I find more useful things on the CSS side like :has, keyframes and container queries. Why duplicate code when you have it for free :)

by hakesson

8/20/2026 at 3:35:14 PM

Yeah I've seen a page that described a whole bunch of things you can do with CSS. So many animation options!

by Sohcahtoa82

8/20/2026 at 3:16:57 PM

The “hidden until found” feature surprised me. What’s the use case for something like that?

by jdlshore

8/20/2026 at 3:31:35 PM

Looks like it's basically like a one way show-hidden mechanism, but the browser's built-in search will pop it open on matches.

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.

by dofm

8/20/2026 at 5:52:40 PM

There is a common accessibility pattern where the first tab focusable item is a "Skip to content" link in the top left corner. The link is initially hidden until you tab to it. That is the only use case I could think of when checking it out.

by pseudosavant

8/21/2026 at 12:47:45 AM

That's not what it's for, that's solved by showing the link when it's focused.

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.

by extra88

8/20/2026 at 4:48:33 PM

It won't be an intended use case, but it might be a convenient place to put poisoned content for the “benefit” of scrapers…

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?

by dspillett

8/21/2026 at 12:26:12 PM

What would be the advantage of using this attribute compared to the various ways to permanently hide elements?

by account42

8/21/2026 at 2:35:14 PM

> compared to the various ways to permanently hide elements?

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.

by dspillett

8/20/2026 at 3:55:24 PM

Pretty cool! I’ve been using <details> for this. One example would be a collapsible tree hierarchy of our organization that you can CTRL+F and still find collapsed teams and people. Or an accordion, or anything collapsible, really.

by wvbdmp

8/20/2026 at 6:06:13 PM

On a big page with lots of collapsed content, I want control+f to search it and find anything in the collapsed sections without having to manually expand them all before I hit control+f

by akersten

8/20/2026 at 7:19:05 PM

I use it for tabbed content. That way search will reveal the tab and content on page search match.

by megaman821

8/20/2026 at 3:37:11 PM

One thing that comes to mind is JS-less image preview, clicking on an image thumbnail reveals the full preview.

by seki285

8/20/2026 at 4:37:06 PM

Though that wouldn't have a method of closing the full image afterwards, if you have a few thumbnails and want one full to be open at a time (closing when the next is selected).

by dspillett

8/21/2026 at 5:40:45 AM

Having worked on rich text editors for several years, I've developed a strong sense of the limitations of native HTML capabilities.

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.

by cyteeditor

8/20/2026 at 8:44:47 PM

The color input looks different depending on your browser and OS. https://master.dev/blog/the-color-input-the-color-picker/

Firefox uses the native OS color picker, which in Windows 11 still looks unchanged from Windows 95.

by waltbosz

8/21/2026 at 12:43:13 AM

That's fine, everything doesn't have to look the same everywhere. It does matter when there's functionality a site relies on but it's not available in one out more browser/OS combinations.

by extra88

8/21/2026 at 1:47:07 PM

Yes, I agree that using the native OS UI is the right choice. Imagine if every web browser had a different file picker dialog, it would be a pain to have to reorient yourself just for that product.

However, I do lament the antiquated Windows 95 color picker. It seems less functional than others that I've used.

by waltbosz

8/21/2026 at 12:16:35 PM

Exactly. I want tings to work as defined by the OS I deliberately chose.

by account42

8/21/2026 at 5:08:49 AM

The main thing I'd like to see HTML (maybe more accurately, without-Javascript) do is AI-bot protection.

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.

by bsammon

8/21/2026 at 5:31:09 AM

Rate-limiting was always a server-side feature, and HTML has nothing to do with this.

"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.

by userbinator

8/20/2026 at 3:39:34 PM

<img> also supports "srcset" which can make the image component responsive. Hope they add a placeholder to it which can account for loading state.

by bingemaker

8/20/2026 at 11:33:45 PM

I find using <picture> with <source> and <img> is more flexible, particularly with multiple image formats (AVIF and JPG in my case).

by theandrewbailey

8/21/2026 at 12:20:18 PM

I wish both srcset and <source> elements wouldn't be so redundantly verbose by forcing you to specify the full (relative) URL for each image when they usually only differ by a small part specifying the resolution or format. Sure, transfer-encoding will mostly nullify the overhead but it's still annoying when editing the HTML manually.

by account42

8/21/2026 at 2:45:11 AM

One more thing thats nice with <picture> and <source> and <img> over <img> with srcset is the former can responsively change images, while some browsers (Chromium based IIRC) will assume srcset corresponds to the “same looking” image.

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

by callc

8/21/2026 at 8:36:20 AM

LLMs defaulting to old patterns for new standards is the same bootstrap problem as Stack Overflow answers lagging behind spec changes. The training data always looks backward.

by chukar

8/20/2026 at 8:39:56 PM

HTML did <select> since inception but that didn't stop people from trying to reinvent it using <div> and a bunch of JS.

All these great built in features, especially typeahead, wont be mainstream until they can be excessively styled.

by t1234s

8/20/2026 at 8:45:31 PM

Isn’t that because select wasn’t style-able?

by vips7L

8/20/2026 at 4:39:03 PM

The only one not mentioned I think should be utilized more is properly names in html forms. Everyone has gotten used to just doing things in javascript when a lot of times if you name the fields in a correct way, you can do a simple form post and let the backend validate it with little to no modifications (hopefully none if you did it correctly).

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.

by hk1337

8/20/2026 at 9:25:30 PM

It seems like the future is doing things like we did in 1998 but with HTML and CSS that isn't terrible.

by bigbuppo

8/20/2026 at 6:14:33 PM

I’m a big fan of simple things but I always go back to using a library or framework because it’s much easier to create a good, consistent UX

by florianherrengt

8/20/2026 at 5:44:34 PM

JS has been in front-line for these functionalty, and HTML has been dog-slow to catch up with slow standardization (not based on usage more academical) and recommendations.

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.

by yipinwong

8/20/2026 at 6:13:00 PM

Odd to both complain about adoption and out yourself as someone unwilling to move to a better solution because it’s less familiar. What do you expect the answer to be here?

by afavour

8/20/2026 at 9:26:34 PM

I suspect he's still optimizing for IE5 compatibility.

by bigbuppo

8/20/2026 at 3:40:29 PM

I think it’s neat but at the same time I’m cautious about implementing an “almost feature” in what’s supposed to be a declarative language.

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.

by yoz-y

8/20/2026 at 9:46:52 PM

HTML in 2026 is starting to do most of what native desktop GUI frameworks did in 1996…

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.

by pavlov

8/20/2026 at 6:32:53 PM

once again, i will ask: why do people care so much about only having one <details> element open at a time? let me see what i want to see!

by peesem

8/21/2026 at 1:55:56 PM

When a form has two sets of mutually exclusive options it might be appropriate? But I find the user experience confusing. It's hard to tell what happened when all the elements moved around, at least without animations.

by ptx

8/20/2026 at 9:49:17 PM

Yes, absolutely, and UX experts such as those at the Nielsen-Norman group have for years been advising against auto-closing the already-opened options when opening another. For good reason - user frustration in their research.

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!

by abanana

8/21/2026 at 2:55:28 AM

Skimming/scanning. For a couple of items, it is not an issue, but say for a long list of FAQ, being able to scroll past fast is nice.

by asdfsa32

8/21/2026 at 3:03:54 AM

but then just close the elements yourself if you need that? don't force one behavior onto everyone

by peesem

8/21/2026 at 4:00:09 AM

Most people are lazy, so it is designed for most, including myself.

by asdfsa32

8/20/2026 at 6:39:44 PM

I use most of these but the one that somehow slipped past me was the name attribute for details. That's going to be incredibly useful. I want to go rip out all of the js accordions now.

by dawnerd

8/20/2026 at 4:28:56 PM

What I'd like to see are searchable drop-downs (not to be confused with text input with suggestions).

And the date/time picker controls are too limited for many applications.

by CodesInChaos

8/20/2026 at 5:10:09 PM

Do I understand that first one correctly as datalist without allowing the user to submit a value not on the list?

by Aachen

8/20/2026 at 5:20:07 PM

That, and how it's rendered needs to be separate from the value the the input gets. Just like `<option value="123">John Doe</option>` or ideally even rich html like `<option value="123"><small>123</small> John Doe</option>`.

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.

by CodesInChaos

8/21/2026 at 6:25:09 AM

Hidden content was not hidden in Android Firefox.

by sehw

8/21/2026 at 12:15:44 PM

That's weird, it works on my phone. Are you sure you didn't refresh the page with the anchor tag still in your URL parameters?

by bluedel

8/20/2026 at 4:49:35 PM

Most people use divs for everything now. This is a breath of fresh air.

by hendurhance

8/20/2026 at 5:21:16 PM

With the exception of using divs for things that have a more appropriate element. Buttons for example - for the love of all that is holy - when I see an onclick handler and aria attributes on divs, I think, "couldn't you have restyled the button??"

by nobleach

8/20/2026 at 5:48:58 PM

Even worse, using buttons everywhere that you should use an a href.

by xboxnolifes

8/20/2026 at 7:14:30 PM

Grouped Details example really needs a hand cursor. An "I" cursor for selecting text doesn't tell you that an element is interactible.

by Dwedit

8/20/2026 at 7:19:15 PM

I eagerly await the day we can fully style the date & time component so that we can put all those JS libraries to (a well deserved) rest.

by prinny_

8/20/2026 at 3:25:09 PM

I don’t understand why the group invented these new attributes and methods of action for dialogs that don’t seem relevant to anything else. Was there some silly patent to work around?

by hyperhello

8/20/2026 at 3:41:11 PM

As opposed to what? Not sure what the alternative you're picturing is.

by esprehn

8/20/2026 at 3:48:01 PM

popovertarget="example-dialog" popovertargetaction="hide"

It’s all binding. This is what JavaScript is for: dynamic content.

by hyperhello

8/20/2026 at 5:17:32 PM

Input fields are dynamic elements. Textareas can be resized. Pages can be scrolled. Why implement everything anew in custom code if it can be implemented once per browser engine in native code, native UI, and expected/homogenous UX?

by Aachen

8/20/2026 at 5:57:47 PM

I mean the action and target attributes don’t seem to appear anywhere else but the popover api. I’m in favor of HTML dialogs, I just don’t see the point in the trend of making everything into this declarative nightmare it’s becoming when we have onclick=dialog.show() without even quotes.

by hyperhello

8/20/2026 at 8:19:10 PM

Script attributes are very often disabled for security reasons.

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.

by esprehn

8/20/2026 at 10:10:56 PM

What I guess this all leads to is that we’re trying to create some kind of DSA that doesn’t have the possibility to hang or crash the way imperative programs must have the ability to if they are to be effective. So it seems like web design is an avalanche of sort of silly css prefixes and selectors and attributes that refer to object ids and everything, when what we might have said instead is that if a script takes more than one second wall clock or something equivalent adjusted to standard then it gets rolled back like a transaction.

by hyperhello

8/21/2026 at 6:39:45 AM

And yet websites are going to do it with custom JavaScript anyway, because it's a nice excuse to force you to accept their surveillance^W analytics, which you will be enabling on the way. Oh, and also because shoving their BRAND™ in your face by micromanaging the appearance and behaviour of everything is apparently more important than user experience being predictable and consistent from one website to another.

by pwdisswordfishq

8/20/2026 at 5:54:54 PM

It's weird that the pure html dialog still doesn't handle inertness yet

by cush

8/21/2026 at 12:58:34 AM

Sure it does. Open a modal <dialog> using <button command="show-modal">.

by extra88

8/20/2026 at 6:36:05 PM

Here we all are in 2026, talking about HTML, like madmen.

by 220hertz

8/20/2026 at 7:00:04 PM

my personal favorite, although css not html, is “field-sizing: content”. Finally with iOS 26 we can have input fields that expand to fit the content

by ChadNauseam

8/21/2026 at 7:13:55 AM

Sadly, Firefox for Android don't support <datalist>, needing a polyfill.

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.

by Zardoz84

8/20/2026 at 9:44:35 PM

>98% of FE/Web developers: no we need hottestnewrandomslopjslibrary.js for this

by fHr

8/20/2026 at 7:50:34 PM

Loved the Zelda reference.

by underdeserver

8/20/2026 at 6:01:45 PM

What on Earth is hidden-until-found for?

by metalliqaz

8/20/2026 at 5:30:51 PM

>popover

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.

by encom

8/21/2026 at 1:16:38 AM

Very handy for nav bars with expandable drop-downs for more links - can now be done with zero JS. Requires much less CSS boilerplate now, and you don’t have to use z-index at all (which eliminates a whole bunch of tricky issues). They also handle all the tricky aria/keyboard/focus mgmt bits for you, too. It works really, really well.

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

by stefan_lec

8/20/2026 at 5:58:19 PM

It is commonly used in dashboards when you want a confirmation dialog

by vazark

8/21/2026 at 7:36:29 AM

I find it very useful to create complex dropdowns. Also, to generate popover that shows previews...

by Zardoz84

8/20/2026 at 12:23:38 AM

I've been tooling with site for years now and I'm always shocked at what can be done with raw HTML. These are some really neat examples, some work a bit funny when it comes to mouse vs. arrow key functionality though (in particular the dropdown/autocomplete), I'm wondering if that's an Edge specific issue or Chromium.

by totallygeeky

8/21/2026 at 1:02:31 AM

The grouped details element sounds very useful. I'm going to add it to my website.

by gulugawa

8/20/2026 at 4:41:14 PM

Just because you can, it doesn't mean you should

by mabini

8/20/2026 at 5:12:26 PM

Exactly. Why reïmplement features in JS just because you can? Waste of effort and usually a worse user experience!

Wait, that wasn't what you meant?

by Aachen

8/20/2026 at 9:57:11 PM

Although I've used that phrase myself in the past, I've come to hate it. Somebody will post it on every HN thread where any form of suggestion has been made.

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).

by abanana

8/21/2026 at 2:18:05 AM

IMHO datalist is a typical example of "just because you can doesn't mean you should"

by novoreorx

8/21/2026 at 1:37:54 AM

Can we start having a label for aislop content?

Maybe it is useful, but I am not reading it. I could barely read 2-3 lines before I closed the tab. Next.

by asdfsa32

8/20/2026 at 6:14:26 PM

ngl i was surprised for the modal dialogs i always thought we needed javascript as i have been doing so forever with jquery

a bit off topic but wish we could bring back <frames> and <tables>. just good old fashioned stuff from the late 90s

by zuzululu

8/21/2026 at 7:39:59 AM

They are yet here. Tables are being used a lot. Also, you have <iframes>

by Zardoz84

8/20/2026 at 4:32:15 PM

The older I get, the less I want to use new browser features that have already been somehow possible with existing ones that typically have been around for literal decades.

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.

by bellowsgulch

8/20/2026 at 10:08:06 PM

You started that off by raising an interesting point. Pity you had to ruin it by telling us you're exceptionally thoughtful and profound, and that those who disagree, 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.

by abanana

8/20/2026 at 8:06:10 PM

js is web remote code execution. we need to return to an html only browser world.

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?

by br0ceph

8/21/2026 at 5:01:00 AM

> Open one and the others close automatically.

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.

by LoganDark

8/19/2026 at 11:40:56 PM

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.

by yurishimo

8/20/2026 at 3:41:02 PM

Very true, and ran into this one specifically myself when going down the "HTML can do this!" road. HTML can NOT, in fact, replace a good combobox with search input. Datalist has significant shortcomings. I wound up using a React island for this single input inside otherwise normal HTML, despite my own objections, because it really it just that much better than the native options.

by vlucas

8/20/2026 at 11:29:22 PM

Not having fuzzy filtering could be OK if you could filter the datalist and force it to display anyway. (There is no way to force it to display.) I gave up and used <ul> or <ol> instead.

by theandrewbailey

8/20/2026 at 5:45:31 PM

Wow, yeah - years later and I still get nothing in Firefox, and support is quite spotty in general (and clearly still buggy): https://caniuse.com/?search=datalist

Hard pass, that's essentially unusable.

by Groxx

8/20/2026 at 3:39:38 PM

There’s still browser/OS typo mitigation.

by sarchertech

8/20/2026 at 3:44:17 PM

That's the whole sanitize vs. validate argument debate that keeps coming up.

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.

by reaperducer

8/20/2026 at 5:50:41 PM

For sure; and it will continue to be an issue as long as we allow old browsers to exist. I’m definitely not saying you shouldn’t have backend validation, just highlighting where the frontend validation provided by the browser is not as universal as it might appear on the surface.

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.

by yurishimo

8/20/2026 at 5:50:32 PM

This is specifically about good UX not about security, validation, or sanitisation.

by Arch-TK

8/21/2026 at 10:15:48 AM

[flagged]

by TechLatestnet

8/21/2026 at 4:41:00 AM

[dead]

by dxroshan

8/20/2026 at 3:41:14 PM

[dead]

by iamgopal

8/21/2026 at 9:56:16 AM

[dead]

by vishalgoyal88

8/21/2026 at 12:17:33 AM

[dead]

by poopiokaka

8/20/2026 at 4:10:47 PM

[dead]

by karamalaskar

8/20/2026 at 6:13:14 PM

[flagged]

by Theoleff

8/20/2026 at 6:08:44 PM

This page loads so slow it did not evenwork for me. guess html was not enough

by devinhades333

8/20/2026 at 4:22:27 PM

An "HTML Can't Do That" would be hundreds pages long, and at the pace of getting features like dialogs every decade we're limiting ourselfs on any further development and creating serious apps. It wasn't created for apps, it was created for light document formatting. When we will pretend a drawing api we can call directly from webassembly? Outside of web ui frameworks are doing just fine and way better and more performantly than html and dom

by hollowturtle

8/20/2026 at 4:24:05 PM

> When we will pretend a drawing api we can call directly from webassembly?

Hopefully, never. There's enough ad-blocking arms race as it is.

by gear54rus

8/20/2026 at 5:42:10 PM

You confuse marketing websites with productivity apps, google docs, figma and many more already render on a canvas using webassembly or not. It's a matter of exposing the right tools

by hollowturtle

8/21/2026 at 4:43:28 AM

There's friction to doing it this way right now, though. You lose out quickly on accessibility, SEO, performance and developer experience (you need developers that are more experienced).

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.

[0]: https://en.wikipedia.org/wiki/Game_theory

by doodlesdev

8/21/2026 at 8:40:42 AM

You can have programmatic apis for accessibility, SEO pages can be dom based, performance of figma is better than if implemented via the dom api, developer experience? you just get the best and stop pretending you have capable people that spend a day on discussing effects in react.

> 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

by hollowturtle

8/21/2026 at 2:31:38 PM 

   > stop pretending you have capable people that spend a day on discussing effects in react.
Figma uses React for the UI panels. Google Docs uses the DOM extensively too.

   > have pushed for manifest v3
I don't use Google Chrome.

   > since we have decided app distribution to be web based
No one has decided this, it just happened because web browsers were in the right place at the right time. It's not set in stone and developer tooling for the desktop could easily revert this trend in a decade or so.

by doodlesdev