8 ms·

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 th

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

jamamp 3y ago
You might like this: http://youmightnotneedjs.com/ http://youmightnotneedjs.com/
- klabb3 3y ago
  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.
  - Freedom2 3y ago
    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".
- lelanthran 3y ago
  There's a scroll indicator! 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).
  - b112 3y ago
    Because firefox devs are... weird. I don't even mean that detrimentally, just observationally. You can un-hide that bar permanently, but when you do, it always covers the edge of the webpage. # scrollbar fixes user_pref("widget.non-native-theme.scrollbar.style", 1); user_pref("layout.testing.overlay-scrollbars.always-visible", true); I literally cannot see the benefit in hiding the scrollbar. It sounds like an edge case made primary.
    - toyg 3y ago
      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.
  - o1y32 3y ago
    I guess you never used MacOS, where the default system scroll bar behavior is even more interesting.
  - oneeyedpigeon 3y ago
    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.
- teaearlgraycold 3y ago
  A good resource for developers targeting the tor browser set to secure mode.
- liam_ja 3y ago
  You might not need JS, but you will need a SCSS transpiler.
- toastal 3y ago
  Beware: some of these are effectively hacks possibly messing up the browser history or introducing accessibility issues for screen readers, keyboard users, or otherwise.
  - o1y32 3y ago
    Exactly. 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
    - toastal 3y ago
      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.
- flagrant_taco 3y ago
  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.
vanarok 3y ago
https://qutebrowser.org https://qutebrowser.org
- klardotsh 3y ago
  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.
Gigachad 3y ago
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.
- rado 3y ago
  <progress>, <dialog>, <details> etc can be themed
  - jayjader 3y ago
    <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.
    - pmontra 3y ago
      Yes, it's still a pain compared to more established elements https://css-tricks.com/html5-progress-element/ https://css-tricks.com/html5-progress-element/
- Dalewyn 3y ago
  >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.
renegade-otter 3y ago
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. It just seems... abandoned.
- iamflimflam1 3y ago
  That's the problem with most of these things, half assed implementations that just tick the box of "compliant with a standard". There's a reason why we have all these frameworks built on top of HTML - it's because the browser manufacturers have not done their jobs.
  - flagrant_taco 3y ago
    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.
  - lenkite 3y ago
    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.
- datagram 3y ago
  > You can't style it with CSS. 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.
tannhaeuser 3y ago
> 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. [1]: https://sgmljs.net/docs/html200129.html https://sgmljs.net/docs/html200129.html
- mattmanser 3y ago
  Most of them don't work properly and/or look terrible by default in all browsers. So no-one uses them, so lots of people don't know about them.
  - geysersam 3y ago
    What do you mean with "they don't work properly"? Could you give an example?
    - iamflimflam1 3y ago
      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.
    - TheFlyingFish 3y ago
      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.
- 3y ago
noelwelsh 3y ago
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).
EspressoGPT 3y ago
> I had heard of almost none of these HTML elements, and that's such a shame I guess, that's on you – if you're a web developer, you definitely 100% need to know these elements. They're not new.

jamamp 3y ago

You might like this: http://youmightnotneedjs.com/ http://youmightnotneedjs.com/

klabb3 3y ago
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.
- Freedom2 3y ago
  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".
lelanthran 3y ago
There's a scroll indicator! 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).
- b112 3y ago
  Because firefox devs are... weird. I don't even mean that detrimentally, just observationally. You can un-hide that bar permanently, but when you do, it always covers the edge of the webpage. # scrollbar fixes user_pref("widget.non-native-theme.scrollbar.style", 1); user_pref("layout.testing.overlay-scrollbars.always-visible", true); I literally cannot see the benefit in hiding the scrollbar. It sounds like an edge case made primary.
  - toyg 3y ago
    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.
- o1y32 3y ago
  I guess you never used MacOS, where the default system scroll bar behavior is even more interesting.
- oneeyedpigeon 3y ago
  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.
teaearlgraycold 3y ago
A good resource for developers targeting the tor browser set to secure mode.
liam_ja 3y ago
You might not need JS, but you will need a SCSS transpiler.
toastal 3y ago
Beware: some of these are effectively hacks possibly messing up the browser history or introducing accessibility issues for screen readers, keyboard users, or otherwise.
- o1y32 3y ago
  Exactly. 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
  - toastal 3y ago
    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.
flagrant_taco 3y ago
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.

vanarok 3y ago

https://qutebrowser.org https://qutebrowser.org

klardotsh 3y ago
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.

Gigachad 3y ago

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.

rado 3y ago
<progress>, <dialog>, <details> etc can be themed
- jayjader 3y ago
  <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.
  - pmontra 3y ago
    Yes, it's still a pain compared to more established elements https://css-tricks.com/html5-progress-element/ https://css-tricks.com/html5-progress-element/
Dalewyn 3y ago
>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.

renegade-otter 3y ago

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. It just seems... abandoned.

iamflimflam1 3y ago
That's the problem with most of these things, half assed implementations that just tick the box of "compliant with a standard". There's a reason why we have all these frameworks built on top of HTML - it's because the browser manufacturers have not done their jobs.
- flagrant_taco 3y ago
  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.
- lenkite 3y ago
  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.
datagram 3y ago
> You can't style it with CSS. 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.

tannhaeuser 3y ago

> 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. [1]: https://sgmljs.net/docs/html200129.html https://sgmljs.net/docs/html200129.html

mattmanser 3y ago
Most of them don't work properly and/or look terrible by default in all browsers. So no-one uses them, so lots of people don't know about them.
- geysersam 3y ago
  What do you mean with "they don't work properly"? Could you give an example?
  - iamflimflam1 3y ago
    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.
  - TheFlyingFish 3y ago
    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.
3y ago

noelwelsh 3y ago

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

EspressoGPT 3y ago

> I had heard of almost none of these HTML elements, and that's such a shame I guess, that's on you – if you're a web developer, you definitely 100% need to know these elements. They're not new.