15 ms·

HTML Can Do That

1023 points by encyclopedism 28d ago

aitchnyu 27d ago
Saw Grouped <details>, ctrl+F'd the hidden content and it opened and highlighted the text in Firefox. Was waiting for this fix ever since I learned about details.
- culi 27d ago
  You can also control this behavior for almost any hidden element with the `hidden="until-found"` attribute https://css-tricks.com/covering-hiddenuntil-found/ https://css-tricks.com/covering-hiddenuntil-found/ https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Global_attributes/hidden https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...
peesem 27d ago
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!
- abanana 27d ago
  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!
- asdfsa32 27d ago
  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.
  - peesem 27d ago
    but then just close the elements yourself if you need that? don't force one behavior onto everyone
    - asdfsa32 27d ago
      Most people are lazy, so it is designed for most, including myself.
- ptx 26d ago
  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.
Dwedit 27d ago
Grouped Details example really needs a hand cursor. An "I" cursor for selecting text doesn't tell you that an element is interactible.
yurishimo 28d ago
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.
- sarchertech 27d ago
  There’s still browser/OS typo mitigation.
- vlucas 27d ago
  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.
- reaperducer 27d ago
  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.
  - Arch-TK 27d ago
    This is specifically about good UX not about security, validation, or sanitisation.
  - yurishimo 27d ago
    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.
totallygeeky 28d ago
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.
jdlshore 27d ago
The “hidden until found” feature surprised me. What’s the use case for something like that?
- dofm 27d ago
  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.
- seki285 27d ago
  One thing that comes to mind is JS-less image preview, clicking on an image thumbnail reveals the full preview.
  - dspillett 27d ago
    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).
- wvbdmp 27d ago
  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.
- dspillett 27d ago
  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?
jamescun 27d ago
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.
- bee_rider 27d ago
  Thank goodness you exist, the fingerprinters will be confused as to which one of the two of us went to their website!
  - jamescun 27d ago
    How? There are dozens of us! DOZENS!
    - Perz1val 27d ago
      How would you count?
      - steanne 27d ago
        "you don't have to, they'll tell you." (+1)
  - jccalhoun 27d ago
    i'm right there with you!
- gunalx 27d ago
  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.
hyperhello 27d ago
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?
- esprehn 27d ago
  As opposed to what? Not sure what the alternative you're picturing is.
  - hyperhello 27d ago
    popovertarget="example-dialog" popovertargetaction="hide" It’s all binding. This is what JavaScript is for: dynamic content.
    - Aachen 27d ago
      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?
      - hyperhello 27d ago
        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.
        esprehn 27d ago
        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 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.
hakesson 27d ago
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 :)
- Sohcahtoa82 27d ago
  Yeah I've seen a page that described a whole bunch of things you can do with CSS. So many animation options!
dematz 27d ago
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.
- Gualdrapo 27d ago
  I seem to recall there was a proposal to add such thing to <select>s
  - bulder 27d ago
    I definitely remember seeing a post by a Chromium maintainer talking about starting development on a proof of concept implementation and surveying for semantics.
- kotaKat 27d ago
  (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!)
  - mdemare 26d ago
    I did not know that and I’ve been here quite a while…
    - kotaKat 26d ago
      Then you get to be today's 10,000 to the rest of the undocumented Hacker News features: https://github.com/minimaxir/hacker-news-undocumented#flaggingvouching https://github.com/minimaxir/hacker-news-undocumented#flaggi...
bingemaker 27d ago
<img> also supports "srcset" which can make the image component responsive. Hope they add a placeholder to it which can account for loading state.
- theandrewbailey 27d ago
  I find using <picture> with <source> and <img> is more flexible, particularly with multiple image formats (AVIF and JPG in my case).
  - callc 27d ago
    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
  - account42 26d ago
    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.
    - theandrewbailey 26d ago
      Ah, don't edit the HTML manually. Name your images brain-dead predictably, and use a script with some regex. 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/java/gram/ArticleProcessor.java https://github.com/theandrewbailey/gram/blob/master/gram/src... https://github.com/theandrewbailey/gram/blob/master/gram/src/java/gram/PictureTag.java https://github.com/theandrewbailey/gram/blob/master/gram/src...
iamgopal 27d ago
[dead]
yoz-y 27d ago
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.
hk__2 27d ago
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.
- krapp 27d ago
  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.
  - zephen 27d ago
    > HTML describes layout News to me.
    - krapp 27d ago
      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.
      - crab_galaxy 27d ago
        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.
        27d ago
karamalaskar 27d ago
[dead]
silvestrov 27d ago
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.
- mdemare 26d ago
  Also temperature, weights, distances…
- hk1337 27d ago
  I'd be okay with regional date format for the user but it always submits as ISO 8601 date format.
  - crote 27d ago
    That's already how it works, is it not?
- crote 27d ago
  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".
- jimmygrapes 27d ago
  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.
hollowturtle 27d ago
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
- gear54rus 27d ago
  > 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.
  - hollowturtle 27d ago
    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
    - doodlesdev 27d ago
      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 https://en.wikipedia.org/wiki/Game_theory
      - hollowturtle 27d ago
        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
CodesInChaos 27d ago
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.
- Aachen 27d ago
  Do I understand that first one correctly as datalist without allowing the user to submit a value not on the list?
  - CodesInChaos 27d ago
    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.
deleted 27d ago
[deleted]
bellowsgulch 27d ago
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.
- abanana 27d ago
  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.
  - deleted 27d ago
    [deleted]
  - deleted 27d ago
    [deleted]
  - bellowsgulch 26d ago
    > Pity you had to ruin it by telling us you're exceptionally thoughtful and profound, and that those who disagree, suck! It's just a comment on the Internet, you don't have to take it so seriously.
hk1337 27d ago
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.
- bigbuppo 27d ago
  It seems like the future is doing things like we did in 1998 but with HTML and CSS that isn't terrible.
stagas 27d ago
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.
mabini 27d ago
[flagged]
- Aachen 27d ago
  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?
  - mabini 25d ago
    [flagged]
- abanana 27d ago
  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).
  - mabini 25d ago
    [flagged]
hendurhance 27d ago
Most people use divs for everything now. This is a breath of fresh air.
- nobleach 27d ago
  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??"
  - xboxnolifes 27d ago
    Even worse, using buttons everywhere that you should use an a href.
teddyh 27d ago
See also: <http://youmightnotneedjs.com/ http://youmightnotneedjs.com/>
encom 27d ago
>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.
- vazark 27d ago
  It is commonly used in dashboards when you want a confirmation dialog
- stefan_lec 27d ago
  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
- Zardoz84 27d ago
  I find it very useful to create complex dropdowns. Also, to generate popover that shows previews...
yipinwong 27d ago
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.
- afavour 27d ago
  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?
  - bigbuppo 27d ago
    I suspect he's still optimizing for IE5 compatibility.
    - yipinwong 26d ago
      A snarky comment that does not contribute jack. Be gone, trollbot, if you ain't have anything better to say
  - yipinwong 26d ago
    "Better" is a subjective term, and you have no way of proving that it is better using any metrics. "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?
    - afavour 26d ago
      I think you can measure “better” if you’re specific. I’m saying better for user experience. You are fine foregoing that if your development experience is better.
werdnapk 27d ago
<details> is still not animatable?
- esprehn 27d ago
  You can animate it now. There's no default though which is a bit annoying. I wish we had made it animate open/closed smoothly. https://austingil.com/animating-details-element-with-only-css/ https://austingil.com/animating-details-element-with-only-cs... https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/Selectors/::details-content https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/S...
- adzm 27d ago
  It is! Add css animation to the ::details-content pseudo element
cush 27d ago
It's weird that the pure html dialog still doesn't handle inertness yet
- extra88 27d ago
  Sure it does. Open a modal <dialog> using <button command="show-modal">.
  - cush 26d ago
    I could still tab behind the dialog
    - extra88 26d ago
      What dialog, the examples in the article? It doesn't have any dialogs that use `command="show-modal"`, only "show-popover". Here's an example of "show-modal". It also has an opacity transition. https://codepen.io/ccwilcox/pen/vEKXeER/b705840fccd607237a4edd0525bb9bd2 https://codepen.io/ccwilcox/pen/vEKXeER/b705840fccd607237a4e...
metalliqaz 27d ago
What on Earth is hidden-until-found for?
devinhades333 27d ago
This page loads so slow it did not evenwork for me. guess html was not enough
dajonker 27d ago
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.
- sublinear 27d ago
  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.
  - dajonker 25d ago
    It's a small team of four, everyone works on the "full stack" which is Rails with HTMX and very little JS. As the lead dev, I am usually the one to make the decision that we should use the modern browser standards. 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.
- nozzlegear 27d ago
  > 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.
Theoleff 27d ago
[flagged]
zuzululu 27d ago
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
- Zardoz84 27d ago
  They are yet here. Tables are being used a lot. Also, you have <iframes>
florianherrengt 27d ago
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
220hertz 27d ago
Here we all are in 2026, talking about HTML, like madmen.
dawnerd 27d ago
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.
ChadNauseam 27d ago
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
prinny_ 27d ago
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.
underdeserver 27d ago
Loved the Zelda reference.
br0ceph 27d ago
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?
t1234s 27d ago
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.
- vips7L 27d ago
  Isn’t that because select wasn’t style-able?
- seanclayton 27d ago
  > All these great built in features, especially typeahead, wont be mainstream until they can be excessively styled. https://developer.chrome.com/blog/a-customizable-select https://developer.chrome.com/blog/a-customizable-select
waltbosz 27d ago
The color input looks different depending on your browser and OS. https://master.dev/blog/the-color-input-the-color-picker/ 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.
- extra88 27d ago
  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.
  - account42 26d ago
    Exactly. I want tings to work as defined by the OS I deliberately chose.
  - waltbosz 26d ago
    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.
fHr 27d ago
>98% of FE/Web developers: no we need hottestnewrandomslopjslibrary.js for this
pavlov 27d ago
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.
poopiokaka 27d ago
[dead]
gulugawa 27d ago
The grouped details element sounds very useful. I'm going to add it to my website.
asdfsa32 27d ago
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.
novoreorx 27d ago
IMHO datalist is a typical example of "just because you can doesn't mean you should"
dxroshan 27d ago
[dead]
LoganDark 27d ago
> 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.
bsammon 27d ago
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.
- userbinator 27d ago
  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.
cyteeditor 27d ago
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.
sehw 27d ago
Hidden content was not hidden in Android Firefox.
- bluedel 26d ago
  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?
pwdisswordfishq 27d ago
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.
knadh 27d ago
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 https://github.com/knadh/listmonk/issues/3073 [2] - https://oat.ink https://oat.ink
- lionkor 26d ago
  Oat.ink is very cool, thanks for sharing!
Zardoz84 27d ago
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.
chukar 27d ago
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.
marcomezzavilla 26d ago
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 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!
vishalgoyal88 26d ago
[dead]
TechLatestnet 26d ago
[flagged]
abustamam 26d ago
As an aside, sometimes just because we _can_ do X in Y doesn't necessarily mean it's always the best solution. One example that comes to mind is people doing really cool things like Doom in CSS (https://github.com/NielsLeenheer/cssDOOM https://github.com/NielsLeenheer/cssDOOM). Really cool? Yeah! Practical? Debatable. 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.
jitbit 24d ago
Try using dialog in safari. It causes full layout recalculation and overloads cpu even on simple pages. HTML can do everything yes. But the world is not ready
oai-test-accoun 22d ago
The native dialog and popover APIs are a good reminder that checking platform capabilities first can eliminate a surprising amount of JavaScript.

1023 points by encyclopedism 28d ago

Saw Grouped <details>, ctrl+F'd the hidden content and it opened and highlighted the text in Firefox. Was waiting for this fix ever since I learned about details.

culi 27d ago
You can also control this behavior for almost any hidden element with the `hidden="until-found"` attribute https://css-tricks.com/covering-hiddenuntil-found/ https://css-tricks.com/covering-hiddenuntil-found/ https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Global_attributes/hidden https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...

peesem 27d ago

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!

abanana 27d ago
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!
asdfsa32 27d ago
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.
- peesem 27d ago
  but then just close the elements yourself if you need that? don't force one behavior onto everyone
  - asdfsa32 27d ago
    Most people are lazy, so it is designed for most, including myself.
ptx 26d ago
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.

Dwedit 27d ago

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

yurishimo 28d ago

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.

sarchertech 27d ago
There’s still browser/OS typo mitigation.
vlucas 27d ago
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.
reaperducer 27d ago
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.
- Arch-TK 27d ago
  This is specifically about good UX not about security, validation, or sanitisation.
- yurishimo 27d ago
  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.

totallygeeky 28d ago

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.

jdlshore 27d ago

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

dofm 27d ago
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.
seki285 27d ago
One thing that comes to mind is JS-less image preview, clicking on an image thumbnail reveals the full preview.
- dspillett 27d ago
  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).
wvbdmp 27d ago
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.
dspillett 27d ago
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?

jamescun 27d ago

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.

bee_rider 27d ago
Thank goodness you exist, the fingerprinters will be confused as to which one of the two of us went to their website!
- jamescun 27d ago
  How? There are dozens of us! DOZENS!
  - Perz1val 27d ago
    How would you count?
    - steanne 27d ago
      "you don't have to, they'll tell you." (+1)
- jccalhoun 27d ago
  i'm right there with you!
gunalx 27d ago
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.

hyperhello 27d ago

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?

esprehn 27d ago
As opposed to what? Not sure what the alternative you're picturing is.
- hyperhello 27d ago
  popovertarget="example-dialog" popovertargetaction="hide" It’s all binding. This is what JavaScript is for: dynamic content.
  - Aachen 27d ago
    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?
    - hyperhello 27d ago
      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.
      - esprehn 27d ago
        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 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.

hakesson 27d ago

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

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

dematz 27d ago

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.

Gualdrapo 27d ago
I seem to recall there was a proposal to add such thing to <select>s
- bulder 27d ago
  I definitely remember seeing a post by a Chromium maintainer talking about starting development on a proof of concept implementation and surveying for semantics.
kotaKat 27d ago
(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!)
- mdemare 26d ago
  I did not know that and I’ve been here quite a while…
  - kotaKat 26d ago
    Then you get to be today's 10,000 to the rest of the undocumented Hacker News features: https://github.com/minimaxir/hacker-news-undocumented#flaggingvouching https://github.com/minimaxir/hacker-news-undocumented#flaggi...

bingemaker 27d ago

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

theandrewbailey 27d ago
I find using <picture> with <source> and <img> is more flexible, particularly with multiple image formats (AVIF and JPG in my case).
- callc 27d ago
  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
- account42 26d ago
  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.
  - theandrewbailey 26d ago
    Ah, don't edit the HTML manually. Name your images brain-dead predictably, and use a script with some regex. 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/java/gram/ArticleProcessor.java https://github.com/theandrewbailey/gram/blob/master/gram/src... https://github.com/theandrewbailey/gram/blob/master/gram/src/java/gram/PictureTag.java https://github.com/theandrewbailey/gram/blob/master/gram/src...

iamgopal 27d ago

[dead]

yoz-y 27d ago

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.

hk__2 27d ago

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.

krapp 27d ago
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.
- zephen 27d ago
  > HTML describes layout News to me.
  - krapp 27d ago
    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.
    - crab_galaxy 27d ago
      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.
      - 27d ago

karamalaskar 27d ago

[dead]

silvestrov 27d ago

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.

mdemare 26d ago
Also temperature, weights, distances…
hk1337 27d ago
I'd be okay with regional date format for the user but it always submits as ISO 8601 date format.
- crote 27d ago
  That's already how it works, is it not?
crote 27d ago
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".
jimmygrapes 27d ago
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.

hollowturtle 27d ago

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

gear54rus 27d ago
> 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.
- hollowturtle 27d ago
  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
  - doodlesdev 27d ago
    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 https://en.wikipedia.org/wiki/Game_theory
    - hollowturtle 27d ago
      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

CodesInChaos 27d ago

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.

Aachen 27d ago
Do I understand that first one correctly as datalist without allowing the user to submit a value not on the list?
- CodesInChaos 27d ago
  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.

deleted 27d ago

[deleted]

bellowsgulch 27d ago

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.

abanana 27d ago
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.
- deleted 27d ago
  [deleted]
- deleted 27d ago
  [deleted]
- bellowsgulch 26d ago
  > Pity you had to ruin it by telling us you're exceptionally thoughtful and profound, and that those who disagree, suck! It's just a comment on the Internet, you don't have to take it so seriously.

hk1337 27d ago

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.

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

stagas 27d ago

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.

mabini 27d ago

[flagged]

Aachen 27d ago
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?
- mabini 25d ago
  [flagged]
abanana 27d ago
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).
- mabini 25d ago
  [flagged]

hendurhance 27d ago

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

nobleach 27d ago
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??"
- xboxnolifes 27d ago
  Even worse, using buttons everywhere that you should use an a href.

teddyh 27d ago

See also: <http://youmightnotneedjs.com/ http://youmightnotneedjs.com/>

encom 27d ago

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

vazark 27d ago
It is commonly used in dashboards when you want a confirmation dialog
stefan_lec 27d ago
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
Zardoz84 27d ago
I find it very useful to create complex dropdowns. Also, to generate popover that shows previews...

yipinwong 27d ago

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.

afavour 27d ago
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?
- bigbuppo 27d ago
  I suspect he's still optimizing for IE5 compatibility.
  - yipinwong 26d ago
    A snarky comment that does not contribute jack. Be gone, trollbot, if you ain't have anything better to say
- yipinwong 26d ago
  "Better" is a subjective term, and you have no way of proving that it is better using any metrics. "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?
  - afavour 26d ago
    I think you can measure “better” if you’re specific. I’m saying better for user experience. You are fine foregoing that if your development experience is better.

werdnapk 27d ago

<details> is still not animatable?

esprehn 27d ago
You can animate it now. There's no default though which is a bit annoying. I wish we had made it animate open/closed smoothly. https://austingil.com/animating-details-element-with-only-css/ https://austingil.com/animating-details-element-with-only-cs... https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/Selectors/::details-content https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/S...
adzm 27d ago
It is! Add css animation to the ::details-content pseudo element

cush 27d ago

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

extra88 27d ago
Sure it does. Open a modal <dialog> using <button command="show-modal">.
- cush 26d ago
  I could still tab behind the dialog
  - extra88 26d ago
    What dialog, the examples in the article? It doesn't have any dialogs that use `command="show-modal"`, only "show-popover". Here's an example of "show-modal". It also has an opacity transition. https://codepen.io/ccwilcox/pen/vEKXeER/b705840fccd607237a4edd0525bb9bd2 https://codepen.io/ccwilcox/pen/vEKXeER/b705840fccd607237a4e...

metalliqaz 27d ago

What on Earth is hidden-until-found for?

devinhades333 27d ago

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

dajonker 27d ago

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.

sublinear 27d ago
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.
- dajonker 25d ago
  It's a small team of four, everyone works on the "full stack" which is Rails with HTMX and very little JS. As the lead dev, I am usually the one to make the decision that we should use the modern browser standards. 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.
nozzlegear 27d ago
> 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.

Theoleff 27d ago

[flagged]

zuzululu 27d ago

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

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

florianherrengt 27d ago

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

220hertz 27d ago

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

dawnerd 27d ago

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.

ChadNauseam 27d ago

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

prinny_ 27d ago

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.

underdeserver 27d ago

Loved the Zelda reference.

br0ceph 27d ago

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?

t1234s 27d ago

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.

vips7L 27d ago
Isn’t that because select wasn’t style-able?
seanclayton 27d ago
> All these great built in features, especially typeahead, wont be mainstream until they can be excessively styled. https://developer.chrome.com/blog/a-customizable-select https://developer.chrome.com/blog/a-customizable-select

waltbosz 27d ago

The color input looks different depending on your browser and OS. https://master.dev/blog/the-color-input-the-color-picker/ 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.

extra88 27d ago
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.
- account42 26d ago
  Exactly. I want tings to work as defined by the OS I deliberately chose.
- waltbosz 26d ago
  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.

fHr 27d ago

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

pavlov 27d ago

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.

poopiokaka 27d ago

[dead]

gulugawa 27d ago

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

asdfsa32 27d ago

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.

novoreorx 27d ago

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

dxroshan 27d ago

[dead]

LoganDark 27d ago

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

bsammon 27d ago

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.

userbinator 27d ago
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.

cyteeditor 27d ago

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.

sehw 27d ago

Hidden content was not hidden in Android Firefox.

bluedel 26d ago
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?

pwdisswordfishq 27d ago

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.

knadh 27d ago

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 https://github.com/knadh/listmonk/issues/3073 [2] - https://oat.ink https://oat.ink

lionkor 26d ago
Oat.ink is very cool, thanks for sharing!

Zardoz84 27d ago

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.

chukar 27d ago

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.

marcomezzavilla 26d ago

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

vishalgoyal88 26d ago

[dead]

TechLatestnet 26d ago

[flagged]

abustamam 26d ago

As an aside, sometimes just because we _can_ do X in Y doesn't necessarily mean it's always the best solution. One example that comes to mind is people doing really cool things like Doom in CSS (https://github.com/NielsLeenheer/cssDOOM https://github.com/NielsLeenheer/cssDOOM). Really cool? Yeah! Practical? Debatable. 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.

jitbit 24d ago

Try using dialog in safari. It causes full layout recalculation and overloads cpu even on simple pages. HTML can do everything yes. But the world is not ready

oai-test-accoun 22d ago

The native dialog and popover APIs are a good reminder that checking platform capabilities first can eliminate a surprising amount of JavaScript.