I had heard of almost none of these HTML elements, and that's such a shame, because they could seriously help put the "we need JavaScript for every gosh darn thing" ecosystem to an end (or at least return JS to what it was originally meant to be: a way to add some flair, some interactivity, some whatever, but not necessarily a replacement for all of your markup and a full-DOM manager).
I'm starting to think my dream browser might be something like visurf https://sr.ht/~sircmpwn/visurf/ but with the underlying Netsurf engine updated to support various modern HTML+CSS, such as these elements. I bet you could have a nearly JS-free smolweb through that browser that:
1. is more accessible (in the "doesn't break screenreaders, system theming, keybinds, etc" way)
2. could be made to use way fewer resources than these heavy JS contraptions these elements can replace
3. would still be able to do most things we expect the median web app of today to do (sure, fire up Firefox for WebGL or whatever still, but I could see, say, a Matrix client potentially needing only a smidge of JS (largely for WebSockets and E2EE stuff) over top of very-modern HTML)
In general the issue with these built in components is that you can't theme them. And they stick out like a sore thumb when you get a windows 7 style component in the middle of a modern looking app.
They also have basically no extensibility so when you inevitably need to do something half complex, you have to scrap it and start again with JS. So you may as well have just started with JS which just works, gives you full power, works identical on all systems, etc.
In the end all these extra components just end up as bloat all browsers have to implement but no one uses.
Unfortunately this is a case where we'll have to agree to disagree. Half the time with Electron apps I wish I could disable CSS completely and just use my system theme because it sucks less than whatever the designer came up with for that app (the definition of "sucks less" falls into many axes that vary per application and context; no point in digressing far into that), so what you described would be a feature, not a bug, to me.
(Further, I basically never, ever want an app to theme itself. Ever. If I set a system theme it's because I want the system to look like that. I've gone on tirades here and on other forums for years about finding https://stopthemingmy.app/ and even just the freedom of every electron app to pick its own HIG and UX as absolute heresy, so if nothing else, my opinions are consistent here.)
I couldn't agree more, unfortunately we are a minority :(. Before react was mainstream, you could "fix" websites pretty easily with things like greasemonkey, but even that is super painful now. CSS modules mangle classnames, so every new version (which are pushed multiple times per week/day) will break your naive css modifications. You can't naively modify DOM elements because React will overwrite them almost instantly.
I know you can write regex in your CSS selectors and use MutationObserver's to update the DOM after react and co are done with it, but it's just so much more painful. Something that used to take maybe 1-2 hours to get some site working/looking how you like it, is now a part time job.
This is what really bugged my about “portable” Java apps way back. Java Spring was especially noticeable. It stuck out like a shore thumb compared to the regular system UIs.
Some like Magic User Interface for the Amiga, but across Operating Systems, and which provides the resulting stylesheet to the browser (with no ability for sites to override it unless I allow it) would be my dream and a marketers nightmare. Just information and media, displayed how each person prefers them to be displayed (and obviously with a lot of user made themes for people to browse and try out). With sub-configs like super-compact, whimsical etc. that users can apply to individual apps and sites.
JS does not 'just work'. This is why a lot of these custom components have bad touch interaction and no accessibility.
Take the datepicker; the native mobile version works great, why annoy users with a custom component?
Because a system you’re developing may have specialized modes. There’s no “today”, “yesterday” or “last week” or “q3” and other suitable shortcuts in standard date/period peekers. Another method is to use a text field which parses itself into a date or a period. E.g. “2-5” means (and/or expands into) 2023-08-02..2023-08-05. “May” means 2023-05-{01..31}. And so on.
My users always appreciated these buttons and modes because they were working in accounting and picking dates from that stupid standard picker was an ordeal. “ / / “ pattern is also annoying because you have to be precise with your cursor.
That said, ios picker is great, and it’s unnecessary to replace it. But (1) it’s not the only useful mode of operation, (2) it wasn’t always great on all platforms, and (3) html attributes usually suck at describing what patterns and use cases you want and compatibility among browsers is a minefield. I mean not only dates here, also numbers and ~numeric fields.
That's totally on point, but I think the core issue is less about "why the native date picker isn't always appropriate" and more "why do we keep half-assing non-native alternatives?"
The way I see it, so much of the web is a clunky mess precisely because software development today pretends to be engineering while simultaneously being about the bottom-line and little else. No doubt, a great date picker could be developed in JavaScript that would serve everyone's needs, be totally accessible, and not a bowl if <div> soup. So why don't we do it? Why are what should be basic HTML forms on corporate websites difficult to navigate or in some cases fundamentally broken, requiring workarounds? Nobody is interested because solving real problems doesn't carry any of the prestige of building another framework. Who wants to build a date picker that is standards compliant when you could write another web framework, bro? Even if a developer is not trying to build the next React, they're probably spending more time on their toolchain than actually coding. It's gotten so bad that seemingly every company I've joined in the last 6 years needs a bunch of people dedicated to maintaining toolchain and CI crap for the rest of the team.
I love programming, but the web needs to get its head out of its own ass. We're acting like our jobs are more important than the value the software delivers, and more effort is being put into making sites impractical for machines to parse (because muh intellectual properteh!) than in making web components that aren't riddled with bugs.
There’s a little more harshness than needed in your comment, but I generally agree with it. Having brought this up before, I’ve usually seen either no or strange reactions to it. It feels like web dev consists of people who only have done their job for an unknown faceless client sitting behind layers of teams and toolchains. Driving to a specific person, listening to their brutal feedback on your system and being asked to maybe fix it right now would be a sobering experience to some of them.
You're absolutely right on the 'why' part, but sadly a lot of custom implementations are annoying in terms of UX and accessibility. My only point here is that building proper custom components is far from easy, it takes a lot of time and effort.
* Can and often does accidentally place the user in American-style MM/DD format where it should be European-style DD/MM (I have a replicable case now on that page example).
* No ability to force date style by design. So there's no way to fix the above from the server, or to use ISO-style dates. Only way to reliably prevent MM/DD by default is to fix every client configuration - not very likely even in small companies.
* No way to have the datetime dialog open by default.
* Poorish but getting better keyboard support (the pagedown-up keys finally work in most browsers, but once you've opened the dialog you can't enter a new date with the keyboard).
* Timezones must be handled separately, which is just poor design.
> ...place the user in American-style MM/DD...
> No ability to force date style by design.
There is datetime-local, date, and time. And there's a lot of control over what is allowed with min-max ranges, steps, etc.
The only thing I can imagine to go wrong here, is when a user has their browser set in US-en but when they are not aware of that. Which seems... weird; or at least not a problem a web-dev should solve.
> Lets you enter nonexistent dates like 31/2
This may be an issue in specific browsers/versions/os. But enabling the "validation" by setting required and/or some other attributes, gives an error for these dates AFAICS. But, in any and all cases: server-side validation is needed anyway. You just cannot trust a value sent by a user, whether that's "validated" with sixty npm-packages and their dependencies, or by the browser.
>The only thing I can imagine to go wrong here, is when a user has their browser set in US-en but when they are not aware of that. Which seems... weird;
Legacy Edge used to look at keyboard locale and ignore the actual region settings. I have no idea why chromium uses MM/DD on my machine when Firefox does DD/MM. Back when $COMPANY used HTML date widgets we got a small but constant stream of complaints which we tried to triangulate (that's how I know about the Legacy Edge behaviour), but we never understood most cases.
Autodetection has been broken on a tail edge of cases for a long long time, and nobody in browser space seems to have any interest in fixing this - or worse, allowing the server to set the correct date style. The only practical fix is JS datetime widgets.
>or at least not a problem a web-dev should solve.
I think 'a not-insignificant amount of people constantly enters the wrong dates and eventually bothers support and writes bad reviews, plz fix this' is a good business cases and is something web-dev should try to handle.
>> Lets you enter nonexistent dates like 31/2
>server-side validation is needed anyway.
True, but it's a better user experience to disallow this also on client. If we only let the server do validation, why do we even bother with the SPA and the sixty-thousand one-line npm packages?
I normally use en_US but I want dates formatted as DD-MM-YYYY (or using dots, slashes etc ) and I want a 24-hour clock.
LC_TIME does not work very well with most apps.
And there is a big difference between just throwing an error if a date-time cannot be parsed because of a nonextent date, and communicating it to the user in a nice way, especially without using JS.
But the webdev has to solve this problem. Users with wrong locales and not aware of that are not very uncommon. I would also love the US to fix their stupid date format and even fully adopt the metric standard but sometimes you have to compromise and write code instead.
WRT dates, there's no "metric" standard. Not really. E.g. Belgium commonly uses DD/MM/YYYY whereas the Netherlands uses DD-MM-YYYY. Both use "metric standard" for lengths, weights etc. Same with currencies: "13,37 €" vs "€ 13,37" vs
"€13,37", all depending on where in Belgium you are from, vs Dutch in the Netherlands. It's an utter mess.
Which is another reason to let browsers - the user agents - deal with this. There's absolutely no way a lonely JS dev, or even a community around something like MUI to get all this right. And they don't. There's always something broken for me with these custom elements. If it's not some US-centric web-app enforcing their MM/DD/YYYY format, then it's some "ignorant" dev being unaware that in Europe in many countries decimal separators are a comma, or that in Thailand the current year is 2566 and that this is not "too far in the future".
> the native mobile version [of datepicker] works great
Strong disagree. It does work for simple forms, but definitely has a variety of quirks on different browsers/devices. Blank dates are especially quirky. Try “tabbing” through a date on iPhone or iPad and have some poor UI. datepicker really doesn’t work well for some less common situations (cut n paste, copy, from/to date, restricted date min/max past/future, year pick, month pick, etcetera).
This is my biggest criticism of all these modern HTML pseudo components. It’s a wonderful idea, truly, but if you don’t provide style hooks to customize and theme them they are useless.
A month ago I wanted to use the input + datalist to have a searchable drop-down but there was no way to control where the dropdown will appear when popped open and what width will it have. Eventually I just gave up. Such a shame.
100% agree. One big challenge is that we've made browsers and the full list of web specs so complicated that we're likely not going to see any new browser rendering engines competing any time soon.
Ideally we would all take a bit of a step back and throw out old specs that aren't needed and improve the ones that need it, like styling support for built-ins. Unfortunately we're at the whims of Google and Appe though, and I can't imagine they would ever be interested in such a potentially large rewrite to their browsers when it functions as-is
<progress> requires some vendor-specific prefixes last time I tried theming it using CSS (unless you're using "theme" to mean host system/window mananger/browser - wide theme). There is no common subset (that I am aware of) of CSS properties shared amongst browsers that can be leveraged to even decently change the <progress> element's appearance. So I'm not sure that it is the best example.
I agree that many of the list _are_ themable enough to warrant investing the effort to wrangle their particular interfaces over reinventing them entirely with <div>s.
I think the idea is rather, that you "extend" by composing primitive elements, and not that you change the primitive elements. Kind of like "composition over inheritance".
Take the html select component, you can't extend or compose this in any way. A request so common that it goes without saying is that you should be able to search for items. This is impossible to implement with the default component.
If you want to do another common thing like allow selecting multiple items, this is also impossible. It's not worth starting with the HTML one and then extending later because there is no path to do this. You have to totally scrap the HTML version so you may as well start with a JS library that does everything you need today and everything you will need tomorrow. Which you can theme to fit in with the rest of the app rather than looking like a pimple on a pumpkin that UX and end users spot and complain about instantly.
I think you misunderstand what I mean by "compose".
You can compose most HTML elements including <select> easily:
<label>
What do you like?
<select name="choice">
<option value="first">First Value</option>
<option value="second" selected>Second Value</option>
<option value="third">Third Value</option>
</select>
</label>
There you go, you did composition. The logic between those elements, how doing something with one element affects the other element, that is a different matter.
For some elements it might be invalid HTML if one is inside the other. Like a <div> inside a <span> or so.
>And they stick out like a sore thumb when you get a windows 7 style component in the middle of a modern looking app.
Wouldn't that be a feature?
"Modern looking" as far as I'm concerned means "Can't figure out WTF this bloody thing is." and that assumes I even know there is a thing in the first place.
I noticed this helping an elderly neighbor with her banking. "No, you don't click there, but there... you can tell because..." then realized there's literally no way to tell. It's all flat.
then realized there's literally no way to tell. It's all flat.
I hate that. I'm waiting for that fad to be over. I kind of liked material design, but it's too much of a pain to put into everything. Flat, borderless, and unidentified is so easy to do.
The all flat approach encourages dark patterns. Lists of trackers you can opt out of, scrollable, with no scroll bar and no window border. There are important buttons hidden which, if pressed, do things favorable to the user but unfavorable to the site operator.
Also, the pop-up box with no visible dismiss button, just an "x" which appears if you mouse over it.
A non-web example - someone made the console window in Ubuntu borderless. If you have two console windows overlapping, you can't see the boundary.
There is something nice about plain old <button> default look and feel. It probably is the kind of feedback they give, that does not require me to always roll my eyeballs elsewhere for confirmation, that my click did actually cause some action to start.
The flat look is borrowed from phones, from UIs where buttons were few and large, and the concept of "mouse-over" is not meaningful. Now it's everywhere, even for complex interfaces where it's not appropriate.
The process pretty much started with Windows 8, which was released in 2012. I don't think the flat style will go away anytime soon. At most, skeuomorphic elements will be slowly phased in. Material design at least adds shadows, and "neumorphism" adds back some 3d popping out, although I haven't seen it much.
Windows 95 was probably the optimal UI—in the Windows world, at least. Meaningful buttons, a reasonably-contained set of components, proper scrollbars. I'm not sure what the next major revision was after that (98 didn't change that much, IIRC) but I bet it was probably a regression.
I think the idea was that when dealing with UI elements where it can be unclear what even is a UI element, it's easier to shape user behavior. e.g. making it harder for the user to "opt out of all tracking".
Those cookie consent boxes are definitely full of dark patterns. My "favorite" one was one that would take 45+ seconds to save your changes. I sent a complaint to the company that makes the consent box, and they responded "website owner configured it incorrectly, nothing we can do" LOL
I just ran into "datalist" and my first impression was "wow, game changer". The behavior is the same across browsers but the appearance is strictly browser-specific. You can't style it with CSS.
Sometimes the list displays the text of the data, sometimes, the text and the "value" attribute. So you are not selecting "Atlanta" - you are selecting "234290780 Atlanta" (the ID and the value).
And with the on-click action, you can't just get the ID - you have to get the whole thing and parse the ID out.
That's am incentive alignment problem, browser vendors' job is ultimately to make money not improve the specs.
Anyone that's interested can get involved in the specs process though. If anything it's web developers who haven't done our job there, it feels to me good specs are more our concern and responsibility than anyone else's.
This is also why I think frameworks like Flutter that render everything to canvas are going to become more and more popular over time - as more and more WASM standards are implemented in browsers.
HTML will be used only for docs and not for web-apps.
Unfortunately, I suspect that this is 100% intentional. datalists can draw outside of the browser window, which is fantastic, but also probably means that there are security considerations for letting it be styled by users. Imagine malicious ads/websites being able to draw outside the browser window.
Hahaha wow I have to say that was the least convincing demo I’ve seen.
- Fills history with massive amounts of entries, and back button doesn’t do anything
- Slider UI look like crap (ok fine, can be fixed) but use not just css but SCSS (requires a precompiler) but wait, not enough, it also needs hardcoded number of images. It’s not reusable in the most basic sense.
- Input validation has phone number on xxxx-xxx-… format and doesn’t fill dashes automatically. It’s also type=number which opens a numpad on iOS which does not have dashes available at all. I can’t proceed unless copy pasting a dash from somewhere else?
- Gave up after that but I’m sure there’s plenty more
Yeah, I’m leaning towards that JS isn’t the nemesis of accessibility. It’s simply not knowing what works and testing properly. It’s funny that frontend folks are seen as lesser beings and then counter-claims like this is passed as enlightened. Yeah on first glance maybe, but it’s proof that these regurgitated claims are made with very little insight. Like all tech, you have to know how to hold it right which takes a little time and humility to get right.
And yes, we still use too much JS. But it’s not the fault of JS or dev practices that we have newsletter popovers, cookie banners and 100 ad delivery and click tracking requests per page load. Indeed JS became extremely bloated for a while but nowadays everything is equally bloated, just look at all the backend snake oil with 1000 cloud microservices and leftpad-like APIs.
I disagree. I've built entire sites that rival the most popular SPA's today with HTML / CSS and a tiny bit of JS, and I've had less issues with those than other sites at my agency built with a JS framework. User reports often come in telling me "Wow, this site is so good! I'm really glad you took on this project".
It tells you, by looking at a thin bar, how far down the page you are! What a novel idea!
I wish browsers had this builtin so that we didn't need to implement a bar for showing the user how much of the document is left to scroll.
(Seriously though, wtf did firefox make the scrollbar autohide? In order to see it the user has to interact with the page. It's worse in the debugger, where horizontal scrollbar just won't show until you interact with the keyboard in some way).
FF devs have to justify their jobs like any other. Someone was promoted for shipping a fancy-looking feature that some other browser, somewhere, probably has as default.
Still better than the Borg, at least you can fix it.
Yeah, seriously bugs me too. Scrollbars were one of the most powerful, useful UI components out there, and we had to sacrifice them because of mobile, for some reason.
Beware: some of these are effectively hacks possibly messing up the browser history or introducing accessibility issues for screen readers, keyboard users, or otherwise.
Level 0 developer: don't know how to do this in JS
Level 1 developer: knows how to do things in JS, even when sometimes it should not
Level 2 developer: knows how to do things without JS
Level 3 developer: knows when to use JS and when to use CSS or something else to achieve the goal
I was more the opposite. I avoid learning JS for as long as possible since it seemed so complicated following the resources I tried to learn.
Ideally we’d have just a few more semantic elements that are obvious common patterns introduced to the HTML spec (like details & dialog were). We’re pretty close now, but I would like to see better accessible no-JS options for building menus.
Seems like aot of people misunderstand what these examples are best for. Sure you wouldn't want to ship these as-is on most sites, but it shows how much can be done without JS. That can/should make it more clear that you can likely get by with much less JS when you do need to reach for it.
It's not about throwing out JS, it's about avoiding 30kb of JS if all you need is a few summary/detail elements where only one can be opened at a time. Use the example code here then write a small I line script that closes all siblings. Done.
> I had heard of almost none of these HTML elements
I'm not disagreeing with the gist of your post, but come on, these elements have been around for ages. It's definitely on you to become acquainted with the basics before your HTML critic can be taken seriously ;)
The post links to MDN (arguably the most useful short reference) but there is of course also WHATWG's HTML spec or, if that's too voluminous, SGML DTD formal grammars for WHATWG HTML 2021 and 2023 snapshots [1], as well as for the older HTML 5.x series.
When I use the datalist element with a text input, Chrome shows an arrow on the right and the list drops down when you focus the input. Firefox, however, shows neither until you start typing, at which point it suggests just those items that match your input. So there's no way to see the full list of options.
I think Chrome's behavior is correct here, but the larger point is that precisely because these are native elements, when they don't work there's nothing you can do. So your only option is to reimplement them from scratch.
Datepicker was fundamentally broken in many ways in safari for a long time. And it still doesn't have the functionality that most apps need, so it's pretty pointless.
<abbr> has always been interesting to me. I've been aware of it for as long as I can remember, since it's been in all the tutorials I remember reading as a teen, and other docs as I got older. Unlike some other forgotten elements, it's one that's clearly very useful, and yet I can count on one hand the amount of times I've seen it used in the real world (yet plenty of times where someone has reinvented it with JS)
Likewise, image maps. Remember messing about with those when I was young, but Wikipedia is the only place I've seen them used. To be fair, the UX isn't great, and I've often ended up navigating to an article when I was expecting to view the image page instead
Everybody was using imagemaps in the 90s because it was the only way to have multiple links over an image, something we wanted to do because without CSS we could not have a row or a column of buttons with fancy colors and fonts and placed where we wanted them to be. So nav bars were a large image with imagemap anchors placed over the buttons.
Then we got CSS, tables (used for layout!), divs with positioning and eventually the features that web developers are using today.
I've used qutebrowser off and on for many, many years. At the end of the day, it's a skin over QtWebEngine, which uses Blink under the hood, and thus contributes to Google's overdominance of the web and the standards that define it, so I try to avoid it, despite it being a better implementation of a Vim layer than, say, Tridactyl for Firefox is (in my opinion).
Beyond that, QtWebEngine is about the polar opposite of the type of engine I described in one key area: resource usage.
Extensibility is the problem here. Either you force everyone to use the a limited set of UI controls (won't happen) or you need to allow some way to create custom UI controls, which leads to JS (or some other programmable system).
I'm starting to think my dream browser might be something like visurf https://sr.ht/~sircmpwn/visurf/ but with the underlying Netsurf engine updated to support various modern HTML+CSS, such as these elements. I bet you could have a nearly JS-free smolweb through that browser that:
1. is more accessible (in the "doesn't break screenreaders, system theming, keybinds, etc" way)
2. could be made to use way fewer resources than these heavy JS contraptions these elements can replace
3. would still be able to do most things we expect the median web app of today to do (sure, fire up Firefox for WebGL or whatever still, but I could see, say, a Matrix client potentially needing only a smidge of JS (largely for WebSockets and E2EE stuff) over top of very-modern HTML)