4 ms·

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 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.
- andai 3y ago
  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.
  - Animats 3y ago
    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.
    - zelphirkalt 3y ago
      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.
      - Animats 3y ago
        Right. 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.
    - dleeftink 3y ago
      > There are important buttons hidden which, if pressed, do things favorable to the user but unfavorable to the site operator. Could you elaborate a bit? How is the flat look benefitting users over site owners? (Is this regarding lists of trackers?)
Sjeiti 3y ago
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?
- wruza 3y ago
  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.
  - Sjeiti 3y ago
    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.
  - ravenstine 3y ago
    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.
klardotsh 3y ago
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/ 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.)
- mixmastamyk 3y ago
  SKINZ all over againz!
- wil421 3y ago
  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.
- doix 3y ago
  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.
- johnnyworker 3y ago
  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.
zelphirkalt 3y ago
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".
- Gigachad 3y ago
  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.
  - zelphirkalt 3y ago
    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.
laurels-marts 3y ago
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.
- flagrant_taco 3y ago
  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

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.

andai 3y ago
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.
- Animats 3y ago
  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.
  - zelphirkalt 3y ago
    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.
    - Animats 3y ago
      Right. 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.
  - dleeftink 3y ago
    > There are important buttons hidden which, if pressed, do things favorable to the user but unfavorable to the site operator. Could you elaborate a bit? How is the flat look benefitting users over site owners? (Is this regarding lists of trackers?)

Sjeiti 3y ago

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?

wruza 3y ago
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.
- Sjeiti 3y ago
  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.
- ravenstine 3y ago
  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.

klardotsh 3y ago

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

mixmastamyk 3y ago
SKINZ all over againz!
wil421 3y ago
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.
doix 3y ago
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.
johnnyworker 3y ago
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.

zelphirkalt 3y ago

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

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

laurels-marts 3y ago

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.

flagrant_taco 3y ago
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