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.
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.
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.
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
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.
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.
Looks like it's basically like a one way show-hidden mechanism only 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.
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).
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.
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?
> 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.
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.
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.
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
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.
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.
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.
This is possible and, in my experience building them, the norm. SPAs have routers and update navigation state, including history for browser Back/Forward
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.
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.
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.
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.
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.
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.
> 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;
}
}
)
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.
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?
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?
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.
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.
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.
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 :)
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.
I definitely remember seeing a post by a Chromium maintainer talking about starting development on a proof of concept implementation and surveying for semantics.
(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!)
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).
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.
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).
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.
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.
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.
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.
> 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.
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.
> 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-*`.
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?
It's all fine and dandy until marketing bros decide to shove all kinds of shady modals into that JS file. The JS side is not exclusive to trivial interactivity.
It's open source software. You can see what it does, and you just put it on your server. We're talking about pre NPM technology here, 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.
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.
The overwhelming majority of web pages are 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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".
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.
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
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.
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.
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.
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.
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).
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??"
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.
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
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.
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?
229 comments
[ 0.30 ms ] story [ 10.0 ms ] threadHow you handle it is project-dependent. But if you're doing a real web site, not an SPA, you can show an error/help page, or re-load the current page with the error/help message.
FWIW I find the native date picker to also still be quite poorly performing in practice, despite quite robust browser support. I wish it worked better but for many reasons, I still see plenty of users (or bots?) who submit dates in the wrong format for whatever reason. My current hypothesis is largely focused on password managers though since they will often do whatever they want directly in the value attribute of an input element.
Hard pass, that's essentially unusable.
So you could use it for additional notes, things like "view pricing terms" or "show exclusions" on product listings — stuff people need to read only when they need to read it — without it being hidden from them if they search for it.
Though humans will accidentally find it too, so using a details tag with appropriate summary as a warning would be more friendly than just hidden content. It'll still get opened, but the user at least has a way of closing it again afterwards.
Also before using it I'd want to check what old UAs including accessibility tools tend to do when they hit a value that they don't recognise for the hidden="" attribute - would what they don't recognise as a valid value result in defaulting to the content being hidden or visible/read/other?
That it might look more like it is intended for human consumption where the others might get their content filtered out due to looking like an obvious trap? More so in the case of the detail tag. Of course they might not be filtering on that sort of thing at all, after all there are many cases of content for humans being hidden that way until activated by script and they won't want to be filtering those out, so it doesn't actually matter and the key will be not showing the otherwise pointless content to human viewers.
My guess is there was a desire to make Find-in-page automatically expand <details> elements and someone realized they could make it also work for custom disclosure widgets by giving the boolean attribute `hidden` an optional value.
Hopefully these and others modern HTML features gain adoption, along with realizing perhaps a Single Page Application isn't necessary in most instances.
I don't often have to write frontend code, but when I do, there is very little in terms of interactivity you cannot do with HTML these days, worst case a little sprinkle of something like HTMX.
(+1)
It's a small problem compared to the ease of use for development you can gain via Blazor, so I don't see any reason not to solve it.
But this can be done in any JavaScript framework and ofcourse Vanilla JavaScript. It takes some effort, but creates a much better user experience.
https://noscript.net/
Even if a site doesn’t monetize with Google Ads, there’s a decent chance it’s pulling a script from ajax.googleapis.com, and Google still knows that you visited the site from the Referer of the script download.
https://developer.mozilla.org/en-US/docs/Web/API/View_Transi...
https://view-transitions.chrome.dev
Best part about it is how gracefully it degrades.
And for some front-end form field validation in the spirit of htmx, ParsleyJS[0] is quite nice. Below is one way to enable the former to support the latter:
0 - https://parsleyjs.org/It’s all binding. This is what JavaScript is for: dynamic content.
The declarative actions API is currently only used for popover, but it's been discussed for over a decade to allow SSR of rich content that's interactive before script loading. See also https://developer.chrome.com/blog/command-and-commandfor
For a long time I also pushed back on these interactive APIs because script is a better primitive and every site seems to have quirky requirements. I've come around on it though because there's huge demand for SSR again and businesses are seeing the value in very fast TTI.
I do still think the date picker API is a disaster. Everyone actually needs something much richer than the system date picker. Travel websites want ranges. People want to put dots and day highlights. I wish they'd fix that next.
>Just a heads up but datalist is not really a great solution if you need a strong contract. The user can still type whatever they want into the field and there is no fuzzy filtering or typo mitigation. Once you add those requirements, a library that gives you a more fully featured combobox is likely going to make a lot of sense in your project.
It is true! HTML can do a lot of cool stuff, it might get you 100% of the way depending on what you're doing. But if you have a lot of forms where users pick from a value set, and want to enforce no other strings and get a good search experience, datalist does not get you there.
So, let the user type, then validate in javascript if you want instant feedback (by changing colors, say, to red / orange), but ideally don't fully block it from being seen by the server. And do the real validation on the server side. This is what I found to be fairly robust, while allowing mitigations if a bad rollout breaks something (delivering to clients is slower than updating something on the server side, most often).
I’m not advocating for willy-nilly package inclusion, just highlighting a current shortcoming of datalist that is often not mentioned in these sorts of articles.
IIRC Chromium based srcset will never “downsize” to a smaller image, whereas <source>’s media is like a real media query.
Use if you want jumpscares at specific sizes lol
My blog has some code that searches for <img> tags just after markdown conversion, then uses the src to find similarly named images (image×1.jpg, image×2.jpg, etc.) to use in <source> tags.
https://github.com/theandrewbailey/gram/blob/master/gram/src...
https://github.com/theandrewbailey/gram/blob/master/gram/src...
Now everybody needs to support it and nobody can really use it.
I’m talking about the features in work like media controls on dialog buttons.
HTML describes layout, CSS describes style, JS adds interactivity.
Want sortable tables? Get a jquery plugin and spend five minutes, done.
This was all solved a decade or more ago.
News to me.
If HTML had <inline> <block> <column> <row> or <grid> tags, sure. But CSS determines the layout via display/position properties.
<div> is block
<table>,<tr> and <td> are your grid, row and column.
CSS improves on describing layout with positioning but HTML was still doing that before CSS even came along.
> explicitly and implicitly describe the layout of an HTML document.
No, this doesn't happen.
> In fact, "HTML" itself is an acronym (HyperText Markup Language)
Duh.
> in which the "Markup" describes the function of HTML to "mark up" text in a similar way that editors once did in the print industry, describing which parts of the text should be bold, italicized, etc. or divided up and in what way.
Which has fuck-all to do with the layout.
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
I want sortable tables without having to rely on a third-party plugin to a third-party library. HTML describes content, not just layout. It would be a `sortable` attribute on the table, just like you already have attributes that have nothing to do with layout such as `autocomplete` or `aria-*`.
It's all fine and dandy until marketing bros decide to shove all kinds of shady modals into that JS file. The JS side is not exclusive to trivial interactivity.
It's open source software. You can see what it does, and you just put it on your server. We're talking about pre NPM technology here, everything is vendored and local and no one is going to change that file without your knowledge and permission. And if someone does, you have much bigger problems on your hands.
What you can't own and control is the browser vendors and how they choose to implement things, or not to. You can edit a JS file to your specific needs, but you're stuck with whatever the browser decides.
There is an incentive to use HTML for common interactivity purposes.
It's really easy to do this with server rendered HTML. Put a link with the sort param in the column headers and be done.
It does make sense in one situation, if the table is a large server-side paginated one and the sorting is really an ORDER BY clause. But for a basic table that fits entirely on the client, it doesn't make sense at all. There are tiny JS libraries that will make <table>s sortable when you add a particular class name.
It is far more resources hungry when dealing with beyond 50 rows or more.
Puts needless pressure on backend.
It is not a good idea when sending whole dataset to client is feasible/better choice.
Of course most JavaScript-based tables get this wrong, too.
But thinking about it: Is there a precedent for HTML to be able to include information that instructs the device to present the DOM out of order? Maybe it's out of scope for HTML to have information about presentation order, when the order is supposed to be implied strictly by the DOM hierarchy itself.
Of course, CSS can visually reorder stuff (e.g. `order` on flex/grid items), but MDN has accessibility warnings regarding the use of `order` and visually presenting the data in an order not reflected by the DOM. So, maybe sorting is best done by reordering the DOM after all.
Yes, it can be done with JS, but nothing is going to beat the browser engine for frequent DOM manipulation of that sort. It's also just one less dependency to have to pull in.
https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...
For some multi-country companies it makes sense to have all admin pages in English no matter the underlying OS language. Imagine sending a screenshot where the OS date format is different from what everybody else expects from an English page.
But yes, there's also a very good argument to be made in favor of having such localized elements follow the content's `lang` attribute - potentially with a `lang="initial"` to reset it to "whatever the user has configured for their OS".
And the date/time picker controls are too limited for many applications.
I guess the best way to render it would be exactly like `<select>` when closed, but when opened there should be a search box where it'd normally show the first option.
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.
I think the big issue with some of items listed is not all the browsers either implement it or they implement it differently. I'm sure your first instinct will be Safari but Chrome, while it may implement a lot, tends to do it quite different than the others. The date picker in browsers is one feature that comes to mind.
Wait, that wasn't what you meant?
If it's part of a paragraph of insightful commentary, it's meaningful. On its own it's not, it appears as though the poster chose to copy-and-paste a cliché instead of bothering to tell us what their specific disagreement even is (perfectly reasonable sarcasm from the sibling comment notwithstanding).
Because of course you should not build a website using nothing but HTML. Go ahead if you want, nobody will use it.
Lack of users never stopped HN from promoting garbage like Kagi and Blusky, so by all means - be a literal retard. I will not stop you.
Why are we cool with popups again? Anything that interrupts and blocks content is annoying, and is nearly guaranteed to make me leave immediately. It can be used responsibly, but it almost never is.
Supposed to be real handy for tooltips too, but haven’t used that myself yet.
Edit to avoid potential confusion: these are separate from modal dialogs, think more like very small popups anchored to one point on the page that still allow you to interact with everything else. Theoretically you can make them modal, but it would be silly to - you’d be better off using <dialog> and the invoker api
HTML can do that. yes. but adoption? welp, I don't really care nor will I use it unless I have to. I will use whatever was available in practice and continue to use them.
Be gone, trollbot, if you ain't have anything better to say
"Better" in my case is being able to move fast by implementing quickly, test fast, and move on with my tasks.
HTML might be "better" in terms of standards, but if nobody follows it, what good is it?