Custom JavaScript controls can't capture the nuance of form fields (2021)(drewdevault.com)
drewdevault.com
Custom JavaScript controls can't capture the nuance of form fields (2021)
https://drewdevault.com/2021/06/27/You-cant-capture-the-nuance.html
226 comments
The problem is not just styling, but usability, the API, and even accessibility too.
Example, a multi-select, see https://jsfiddle.net/z0Ltxh47/1/ :
Usability is bad because I can't select multiple non-consecutive items by using just my mouse. It's very narrow by default, and doesn't allow me to resize.
API: Your typical HTMLInputElement.value doesn't give me all the selected values. I need to map the .selectedValues to their values, or innerText if no value exist. Horrific.
Accesibility: At least in Firefox, using ctrl+arrows to be able to focus on elements to select them do not render any focus targets. In Chrome, the contrast is not there.
Don't even get me even started with the date/time-picker.
Example, a multi-select, see https://jsfiddle.net/z0Ltxh47/1/ :
Usability is bad because I can't select multiple non-consecutive items by using just my mouse. It's very narrow by default, and doesn't allow me to resize.
API: Your typical HTMLInputElement.value doesn't give me all the selected values. I need to map the .selectedValues to their values, or innerText if no value exist. Horrific.
Accesibility: At least in Firefox, using ctrl+arrows to be able to focus on elements to select them do not render any focus targets. In Chrome, the contrast is not there.
Don't even get me even started with the date/time-picker.
To be fair, multi selection is a disaster on any platform.
It is a hard concept that isn't completely solved by any of the standard GUI widgets.
It is a hard concept that isn't completely solved by any of the standard GUI widgets.
The most robust solution is to individually toggle selected state on each item, and don't unselect all on a new click. Like a checkbox. Click once for selected, once to unselect, don't unselect all on any click.
A multi-select drop down is just solving the problem of a checkbox list being too long, or not what the designer wants it to look like. The most clear UI for this input type is a set of checkboxes in my opinion. Same for a single item select and radio buttons.
Drop downs have a lot of caveats, and unique compositions in the wild, so many of them are inaccesible and it's essentially just because someone wanted it to look pretty. I think that is bad software.
A multi-select drop down is just solving the problem of a checkbox list being too long, or not what the designer wants it to look like. The most clear UI for this input type is a set of checkboxes in my opinion. Same for a single item select and radio buttons.
Drop downs have a lot of caveats, and unique compositions in the wild, so many of them are inaccesible and it's essentially just because someone wanted it to look pretty. I think that is bad software.
A separate multi-select control is just a bad idea from 1990s; it should be disused and forgotten. The proper way is a list of checkboxes. Checkboxes are easy to recognize, easy to style, and easy to navigate and operate.
Now make that a set of 200 checkboxes and see how practical it is compared to one combobox-style multi-select input.
200 checkboxes make about as much sense as a 200-item dropdown. Neither is manageable. The multi-select dropdown is additionally hard to check for the selections made.
An input box with pill-style auto-completion (see e.g. the tags control on Stackoverflow) would be a reasonable alternative.
Another, larger alternative is the typical two-lists control, with selected items moved from the source list to the target list; this idiom was widely used in Windows since 1990s. It's not mobile-friendly though.
An input box with pill-style auto-completion (see e.g. the tags control on Stackoverflow) would be a reasonable alternative.
Another, larger alternative is the typical two-lists control, with selected items moved from the source list to the target list; this idiom was widely used in Windows since 1990s. It's not mobile-friendly though.
> 200 checkboxes make about as much sense as a 200-item dropdown. Neither is manageable.
Multi-select is okay there, apart from the problems I mentioned above: https://jsfiddle.net/z0Ltxh47/2/ . I can navigate to i19 with a few key strokes. Only if it were then possible to easily select a1...
> An input box with pill-style auto-completion (see e.g. the tags control on Stackoverflow) would be a reasonable alternative
And we are back at implementing our custom controls again.
Multi-select is okay there, apart from the problems I mentioned above: https://jsfiddle.net/z0Ltxh47/2/ . I can navigate to i19 with a few key strokes. Only if it were then possible to easily select a1...
> An input box with pill-style auto-completion (see e.g. the tags control on Stackoverflow) would be a reasonable alternative
And we are back at implementing our custom controls again.
> And we are back at implementing our custom controls again.
Sadly, yes. Not everything was anticipated at the times of Netscape 2.
HTML5 added a number of native controls, like video players and calendars. I wish a better "native" multi-select alternative surfaced, too. OTOH I suppose that browsers are going to blur the line between "native" controls and web components and such.
Sadly, yes. Not everything was anticipated at the times of Netscape 2.
HTML5 added a number of native controls, like video players and calendars. I wish a better "native" multi-select alternative surfaced, too. OTOH I suppose that browsers are going to blur the line between "native" controls and web components and such.
I think there's an initiative to improve these... but I can't find it at the moment. Googling anything with "native" just turns up react-native crap.
> And we are back at implementing our custom controls again.
Are we? Why wouldn't we just push OS vendors to add "input box with pill-style auto-completion" as a native toolkit widget, and then have browsers expose it? The OS vendors have proven willing to add stuff like native OS date/time/number-picker widgets, so why not this one?
Are we? Why wouldn't we just push OS vendors to add "input box with pill-style auto-completion" as a native toolkit widget, and then have browsers expose it? The OS vendors have proven willing to add stuff like native OS date/time/number-picker widgets, so why not this one?
I like the pattern of drop downs where you can type to filter. But I've found there isn't great UI in that it's not super obvious you can type.
I was actually implementing exactly this today in Angular and went with a <mat-autocomplete>
https://v5.material.angular.io/components/autocomplete/overv...
https://v5.material.angular.io/components/autocomplete/overv...
An input box like SO's isn't discoverable though, it's not good for things that you "want but don't know exist yet"
Multiselect over a range of 200 arbitrary values isn't something that will ever be solved by a single control, so that's a complete straw man.
If you actually need to multi-select over 200 arbitrary values (you almost certainly don't), the best way to do it I've seen is a way to filter the displayed items, a "Select All" button for what's visible based on that filter, and maintaining the "checked" state through filter changes, allowing you to select anything matching multiple filters.
If you actually need to multi-select over 200 arbitrary values (you almost certainly don't), the best way to do it I've seen is a way to filter the displayed items, a "Select All" button for what's visible based on that filter, and maintaining the "checked" state through filter changes, allowing you to select anything matching multiple filters.
this problem was solved around 1986 by Norton Commander and one of the main reasons why two-panel file managers (FAR, mc, TotalCommander) are still in use.
When you decouple selection with cursor and make selection "permanent", so you can move around this list without fear to lose accumulated selection, you could pick needed elements one-by-one, sort list by any attributes to simplify selection, apply filters, etc.
When you decouple selection with cursor and make selection "permanent", so you can move around this list without fear to lose accumulated selection, you could pick needed elements one-by-one, sort list by any attributes to simplify selection, apply filters, etc.
Yep. When marking many files for selection the twin-pane file managers let your mind (and your stomach) rest easy. I sometimes use ranger with two or more tabs to similar effect.
There was/is a Tcl/TK twin-pane file manager I liked called FileRunner. It's showing it's age now and needs a rewrite -- not for beauty, which I'm not too concerned about, but for some glitches that have crept in with time and lack of maintenance. It seemed more mouse friendly than some other twin-pane FMs (or maybe it's just rose-tinted memory).
There was/is a Tcl/TK twin-pane file manager I liked called FileRunner. It's showing it's age now and needs a rewrite -- not for beauty, which I'm not too concerned about, but for some glitches that have crept in with time and lack of maintenance. It seemed more mouse friendly than some other twin-pane FMs (or maybe it's just rose-tinted memory).
I'm using FAR in Windows (10 now) every day. I'm using it as my command-lime shell, really, never run cmd or powershell. For everything my console needs (and I'm using a lot of coretools/filetools in the form of mingw64).
I don't know how to live on Windows without it, it is first program I install, even earlier than alternative browser.
I don't know how to live on Windows without it, it is first program I install, even earlier than alternative browser.
Usually with 200 or so values there is some categorization of values that exists - maybe it's counties in a state that can be divided into regions or songs by an artist that can be divided into album or period. Large multi-selects seem to necessitate a multi-step selection process where the user can drill down (All of this category, none of this one and some of this other one - specifically this, this, not this and that). I think it's feasible for such a tag proposal to make its way through various working groups but it'd be pretty opinionated and we'd likely end up dividing multi-select inputs into several different classes (which would probably be a good thing).
If your UI has 200 checkboxes displayed at once, in an ideal world you’re rethinking your requirements and redesigning the UI.
The only way to make a 200 item select box usable is to make it not a 200 item select box somehow.
The only way to make a 200 item select box usable is to make it not a 200 item select box somehow.
By filtering to search, which is also a UI fraught with inaccesiblity if not very carefully designed. I think custom elements aren't the issue here really, it's the lazy implementations.
Think bigger even. In an ideal world, if you have that many options you might want to rethink the entire workflow. I understand in the real world that may not be an option, but it’s still probably the ideal state.
You just need a fuzzy text filter at the top to hide the checkboxes you don't care about.
I think this thread just about proved how insufficient the available controls are.
Hilariously, lots of good implementations on mobile. Long tap to start, checkbox next to each item that is then selected. Confirm button when done selecting.
I actually really dislike this.
I find that I often have half second hangups due to not remembering if in select mode or not.
Much prefer the "Hold shift/ctrl" model used often in file managers.
I find that I often have half second hangups due to not remembering if in select mode or not.
Much prefer the "Hold shift/ctrl" model used often in file managers.
Parent is talking about mobile. And on Android it's working rather well I'd say. The only downside I see is that selecting longer spans (shift click) is not possible.
There are Android apps where you can select two items in a list and then there's a button that selects all of the items between them, which is equivalent to a shift-click.
In the context of the parents comment I thought they were comparing that model to others where multi selct exists.
I don't think there is a much better model on mobile, except possibly adding a button to each item to select a longer span.
I don't think there is a much better model on mobile, except possibly adding a button to each item to select a longer span.
Browser requires very fine degree of dexterity, and has 0 discoverability.
Mobile ones often have a "start multi-select" button in the UI.
Neither is an amazing experience, but IMHO the mobile one is somewhat better.
Mobile ones often have a "start multi-select" button in the UI.
Neither is an amazing experience, but IMHO the mobile one is somewhat better.
Multi-select is what you have in File Explorer. You can select multiple files and folders for copying or deletion or moving. It is not a disaster
There are problems even with the single selection (searching for an option in mobile, consistent contrast, copying selected value etc.).
Depending on the application, sometimes to fix such problems, you need to reimplement the component in js or you start won't fix'ing tickets.
So articles like this really underestimate the problems with the existing controls and the lack of some.
Depending on the application, sometimes to fix such problems, you need to reimplement the component in js or you start won't fix'ing tickets.
So articles like this really underestimate the problems with the existing controls and the lack of some.
I would probably use a series of checkboxes for the same effect.
The js fiddle example works great on iOS. I didn’t realize mobile safari supported a multi-select sheet!
Even in desktop Firefox (on linux) I immediately tried to:
- Multi-select by Ctrl+clicking on other items I want selected. (works)
- Shift-click to expands the selection linearly from the focus (works)
- Select one item, then Shift+Up/Down arrows to expand the selection. (Works)
I bet a custom control would be missing most of that behaviour as well.
Mind you, those affordances are completely unknown to most users. I bet if you asked most users (even developers) how to select multiple items in that control, 9/10 would struggle. The input control doesn't make its affordances obvious at all.
So in all, I'm confused what the browser vendors expect people to do here. I'd love to use the built in controls. But as others have said, they're often ugly, they confuse people, their APIs are a mess and they're difficult to style.
- Multi-select by Ctrl+clicking on other items I want selected. (works)
- Shift-click to expands the selection linearly from the focus (works)
- Select one item, then Shift+Up/Down arrows to expand the selection. (Works)
I bet a custom control would be missing most of that behaviour as well.
Mind you, those affordances are completely unknown to most users. I bet if you asked most users (even developers) how to select multiple items in that control, 9/10 would struggle. The input control doesn't make its affordances obvious at all.
So in all, I'm confused what the browser vendors expect people to do here. I'd love to use the built in controls. But as others have said, they're often ugly, they confuse people, their APIs are a mess and they're difficult to style.
Yes it really is. And now imagine someone would instead use a custom multi-select, because their browser has a bad implementation. Actually the best example why custom form elements shouldn‘t be used.
You can still write one as an add-on for your browser and help others or use it as poc for a ticket to the browser vendor.
You can still write one as an add-on for your browser and help others or use it as poc for a ticket to the browser vendor.
How about some checkboxes and labels with the for attribute then?
Aren't we then back at the problem? Creating a drop down selectable list using checkboxes and labels?
...And then to make that drop down pretty, and the checkboxes look neat, we'll set their opacity to 0 and remove pointer events, use CSS to style the label and set a nice looking tick using the 'before' content, which changes when the checkbox is selected... And oh, there again!
...And then to make that drop down pretty, and the checkboxes look neat, we'll set their opacity to 0 and remove pointer events, use CSS to style the label and set a nice looking tick using the 'before' content, which changes when the checkbox is selected... And oh, there again!
Which becomes a nightmare to look at with no styling: https://jsfiddle.net/wdqjyvsu/
and then it gets complicated very quickly: https://jsfiddle.net/wdqjyvsu/1/
You also have still undiscovered problems: How to let people filter the options if you have lots of them (and don't say ctrl+f because it doesn't restrict the search within the element)? What about lazy-loading if you have lots and lots and lots of them?
Usability is not improved, it takes too much space now. API is even worse. Accessibility is improved contrast-wise but all the tabbing is not very friendly, and try using that with a screen-reader. It takes ages to make a selection.
and then it gets complicated very quickly: https://jsfiddle.net/wdqjyvsu/1/
You also have still undiscovered problems: How to let people filter the options if you have lots of them (and don't say ctrl+f because it doesn't restrict the search within the element)? What about lazy-loading if you have lots and lots and lots of them?
Usability is not improved, it takes too much space now. API is even worse. Accessibility is improved contrast-wise but all the tabbing is not very friendly, and try using that with a screen-reader. It takes ages to make a selection.
No offense, but this feels like trying too hard to make the argument that a perfectly normal pattern is somehow too obtuse to be considered.
I'm guessing you're trying to argue that something like a pill autocompleter is more appropriate for specific use cases (e.g. the `to:` field in email clients). And sure, sometimes some controls are better suited than others depending on the use case, but that doesn't necessarily mean that it's impossible to implement similarly complex controls by leveraging standard controls as opposed to reinventing headless behaviors on top of div soup[0]
[0] https://codepen.io/lhorie/pen/xxPJpeB
I'm guessing you're trying to argue that something like a pill autocompleter is more appropriate for specific use cases (e.g. the `to:` field in email clients). And sure, sometimes some controls are better suited than others depending on the use case, but that doesn't necessarily mean that it's impossible to implement similarly complex controls by leveraging standard controls as opposed to reinventing headless behaviors on top of div soup[0]
[0] https://codepen.io/lhorie/pen/xxPJpeB
Your implementation has a lot of accessibility problems AND requires javascript AND doesn't work on firefox mobile.
Also: Congratulations, we collectively proved the article wrong. It says, "The browser’s built-in controls are quite sufficient". Here we see that you usually can't "just use standard controls", and even when you do, you need a lot of JS on top to make them accessible, usable, nice to look at with an acceptable API.
Also: Congratulations, we collectively proved the article wrong. It says, "The browser’s built-in controls are quite sufficient". Here we see that you usually can't "just use standard controls", and even when you do, you need a lot of JS on top to make them accessible, usable, nice to look at with an acceptable API.
> has a lot of accessibility problems AND requires javascript
I'm not sure what you're arguing for then, it feels like you're just hating for its own sake. Because obviously not using standard controls and auto-including aria attributes will require JS too. Turn off javascript and CSS as you're arguing for, and then come back with a proper working implementation and then let's talk :)
I'm not sure what you're arguing for then, it feels like you're just hating for its own sake. Because obviously not using standard controls and auto-including aria attributes will require JS too. Turn off javascript and CSS as you're arguing for, and then come back with a proper working implementation and then let's talk :)
I'm arguing that you DO need custom controls. Did you read the thread?
Of course I did. You're the one going on about unstyled elements and whatnot?
The article is about subtle behaviors that come built into standard UI elements. My point is you can get those behaviors from leveraging these elements instead of literally writing custom code to handle a series of keypresses in a div-soup-based <select>-lookalike.
As far as I can tell, nobody here is arguing for things like no-JS no-CSS solutions. The point is that custom controls implemented on top of div soup are usually much heavier and worse in terms of subtle behavior support than custom controls implemented on top of standard form elements, in the same way that using a sledgehammer as a nail gun is likely to yields sub-optimal results, because details.
The article is about subtle behaviors that come built into standard UI elements. My point is you can get those behaviors from leveraging these elements instead of literally writing custom code to handle a series of keypresses in a div-soup-based <select>-lookalike.
As far as I can tell, nobody here is arguing for things like no-JS no-CSS solutions. The point is that custom controls implemented on top of div soup are usually much heavier and worse in terms of subtle behavior support than custom controls implemented on top of standard form elements, in the same way that using a sledgehammer as a nail gun is likely to yields sub-optimal results, because details.
Ah, okay now I get the subtlety, I stand corrected.
I'd still argue that there are times that you do have to use completely custom controls, like the case with the date-pickers. Not only because you cannot style them, but they also have a lot of API constraints, and accessibility problems. Even the example in the article, the beloved text area, has a lot of constraints like it's quite cumbersome to get the selection coordinates and it's impossible to offer any highlighting, so welcome to the world of contenteditable!
I completely agree that we should try to compose the native UI controls instead of reinventing the wheel when possible (like the text-input for that date-picker modal).
I'd still argue that there are times that you do have to use completely custom controls, like the case with the date-pickers. Not only because you cannot style them, but they also have a lot of API constraints, and accessibility problems. Even the example in the article, the beloved text area, has a lot of constraints like it's quite cumbersome to get the selection coordinates and it's impossible to offer any highlighting, so welcome to the world of contenteditable!
I completely agree that we should try to compose the native UI controls instead of reinventing the wheel when possible (like the text-input for that date-picker modal).
Yeah I can see why people get torn on date pickers. This was especially egregious back when they weren't as well supported/implemented across different browsers. The problem with them, as some people alluded in some comments, is that often times when people reinvent that wheel, they do an objectively worse job at it.
Because of my bad experience with these poorly implemented controls in the wild, these days I quite appreciate the way the <input type="date"> inputs appear on mobile (i.e. it's a completely different UI than desktop that optimizes against fat fingering/tiny hit areas/etc). Certainly beats implementations that rely on trapping input events and rewriting `input.value` on a plain text input...
Because of my bad experience with these poorly implemented controls in the wild, these days I quite appreciate the way the <input type="date"> inputs appear on mobile (i.e. it's a completely different UI than desktop that optimizes against fat fingering/tiny hit areas/etc). Certainly beats implementations that rely on trapping input events and rewriting `input.value` on a plain text input...
You can hide multiple checkboxes in a <details> if it gets to messy: https://jsfiddle.net/3mohuw7e/
<details> is pretty easy to style and shouldn’t be to complicated to add extra features like filter fields by search etc.
<details> is pretty easy to style and shouldn’t be to complicated to add extra features like filter fields by search etc.
>I can't select multiple non-consecutive items by using just my mouse
Well you can with ctrl-click. A well hidden feature though.
Well you can with ctrl-click. A well hidden feature though.
> using just my mouse
Say what you will about ActiveX, but it allowed a much more native feel for web pages.
Native feel is not wanted (anymore). Branded appearance is.
(and I think this is unfortunate. I wish developers didn't attempt to replace my browser's perfectly fine-looking, accessible checkboxes by their own often ugly custom implementations for instance. And I'm not hating on web devs, I'm one of them)
XUL [1] seemed like a good idea as a basis for building native-looking web applications. It's too bad it has been abandoned.
[1] https://en.wikipedia.org/wiki/XUL
(and I think this is unfortunate. I wish developers didn't attempt to replace my browser's perfectly fine-looking, accessible checkboxes by their own often ugly custom implementations for instance. And I'm not hating on web devs, I'm one of them)
XUL [1] seemed like a good idea as a basis for building native-looking web applications. It's too bad it has been abandoned.
[1] https://en.wikipedia.org/wiki/XUL
I think both are wanted. People like it when they have the usability and familiarity of native widgets, but it’s nice when they also have theming and personality. A good example is TweetBot, which is a normal iOS app except it’s not, or OmniFocus which does things in a native way except everything is purple.
> XUL seemed like a good idea as a basis for building native-looking web applications. It's too bad it has been abandoned.
Didn't XUL do roughly what React Native, and other similar frameworks, do today?
edit I see that XUL did its own rendering rather than using native widgets, but the overall goal seems about the same.
Didn't XUL do roughly what React Native, and other similar frameworks, do today?
edit I see that XUL did its own rendering rather than using native widgets, but the overall goal seems about the same.
What is the problem exactly seems to work fine on Firefox mobile
I have good news for you! https://open-ui.org/
> The purpose of Open UI to the web platform is to allow web developers to style and extend built-in web UI controls, such as <select> dropdowns, checkboxes, radio buttons, and date/color pickers.
Their current thinking is to cook a new element, <selectmenu>. Here's a demo of styling it in an experimental version of Chrome. https://www.youtube.com/watch?v=IjHnmaquifM
(They went with a new element <selectmenu> instead of <select styleable=true>, but there's still an ongoing debate about that, and/or how to polyfill it.)
> The purpose of Open UI to the web platform is to allow web developers to style and extend built-in web UI controls, such as <select> dropdowns, checkboxes, radio buttons, and date/color pickers.
Their current thinking is to cook a new element, <selectmenu>. Here's a demo of styling it in an experimental version of Chrome. https://www.youtube.com/watch?v=IjHnmaquifM
(They went with a new element <selectmenu> instead of <select styleable=true>, but there's still an ongoing debate about that, and/or how to polyfill it.)
I'd put the blame on designers, since the "modern design" that you are referring to is terrible. We'd all be better off if the web still looked like 2004, and the users would be fine with it too - they only care about "modern design" as a proxy for "this is an actively maintained product".
> We'd all be better off if the web still looked like 2004, and the users would be fine with it too - they only care about "modern design" as a proxy for "this is an actively maintained product".
You're declaring this based on what, exactly?
You're declaring this based on what, exactly?
I agree 100%. and the fact that there are still only a handful of form controls is just jarring. The people who champion using JS frameworks to make up for the lack of form elements are contributing to the problem, especially on mobile. No library, not even well tested JS ones can make up for the native controls. This is why users do prefer mobile native apps.
Imagine a custom implemented drop down that just goes out of the screen and make you unselectable. Let alone the item height are just narrow that make you accidentally click something next to it. And yea, that happens all the time.
And as a developer I often need to argue with the designer that please just don't use dropdown on mobile ui when there are many items. That is just a torture for a phone user.
And sometimes I even need to add hidden area to the ui. Because the controls are way too tiny to click.
Usability are not really in their mind., Or probably it is just a bad designer.
And as a developer I often need to argue with the designer that please just don't use dropdown on mobile ui when there are many items. That is just a torture for a phone user.
And sometimes I even need to add hidden area to the ui. Because the controls are way too tiny to click.
Usability are not really in their mind., Or probably it is just a bad designer.
Most websites that use custom components look and feel broken, no matter what the year.
I'd be perfectly happy if your website looks like the OS platform it's running on. That way, I already know how to recognize and use the controls before I arrive. Granted, I'd blame the browsers if those controls weren't accessed by default.
What you want is mostly already here - just use native HTML elements.
I got in trouble for this before. App was using some third party super bloated select-react-component-replacement-made-of-divs, and it wasn't behaving properly. I just replaced it with a select, so then people complained it was ugly.
And I get where they're coming from.
At the same time... native browser controls work, they don't require maintenance, they don't add to the bundle size, or have complex version inter-dependencies.
Maybe it's time to rethink frontend. Maybe what we write should be designed to work with the standard HTML controls.
(Or maybe it's time for me to go back to the backend and play with database, because I feel increasingly out of touch).
And I get where they're coming from.
At the same time... native browser controls work, they don't require maintenance, they don't add to the bundle size, or have complex version inter-dependencies.
Maybe it's time to rethink frontend. Maybe what we write should be designed to work with the standard HTML controls.
(Or maybe it's time for me to go back to the backend and play with database, because I feel increasingly out of touch).
the web is really a horrible platform to build any kind of high fidelity app. you can say it works despite of itself.
and this is by design, web as a platform is pretty much owned by tech giants like google and apple who have a financial interest in keeping the web from becoming a rich platform which would cut into their app store hegemony.
ironic when you consider iphone and the html 5 back story. in some respects microsoft with IE back in the days was more interested in developing the web as a platform but also saw the web as something they could monopolise whereas now apple takes a more nuanced but just as much devious approach.
and this is by design, web as a platform is pretty much owned by tech giants like google and apple who have a financial interest in keeping the web from becoming a rich platform which would cut into their app store hegemony.
ironic when you consider iphone and the html 5 back story. in some respects microsoft with IE back in the days was more interested in developing the web as a platform but also saw the web as something they could monopolise whereas now apple takes a more nuanced but just as much devious approach.
> and this is by design, web as a platform is pretty much owned by tech giants like google and apple who have a financial interest in keeping the web from becoming a rich platform which would cut into their app store hegemony.
Google is guilty of plenty of things, but holding back the web as a first rate development platform is not one of them, and I think the blame falls squarely on Apple's shoulders here.
Just look at what you can do with a PWA on Android. Most importantly, unlike on iOS, you can receive push notifications. But you can also do things like ship a PWA directly to the Play Store, access all sorts of native browser libraries like Bluetooth support and Add to Home Screen.
If you look at non-gaming apps, I'd estimate about 90% of them could be straightforwardly implemented as PWAs. The reason they're not is due to deliberate decisions by Apple not to support the tech that would make that possible, like push notifications.
Google is guilty of plenty of things, but holding back the web as a first rate development platform is not one of them, and I think the blame falls squarely on Apple's shoulders here.
Just look at what you can do with a PWA on Android. Most importantly, unlike on iOS, you can receive push notifications. But you can also do things like ship a PWA directly to the Play Store, access all sorts of native browser libraries like Bluetooth support and Add to Home Screen.
If you look at non-gaming apps, I'd estimate about 90% of them could be straightforwardly implemented as PWAs. The reason they're not is due to deliberate decisions by Apple not to support the tech that would make that possible, like push notifications.
iOS is adding the ability for web apps to send push notifications.
I mean, we don’t need custom browser components. We need certain functionalities that just cannot be given by default components without a ton of ugly hacks.
> but anyone that has ever needed to style a <select> to make it look in line with any modern design
Then don't make it look "in line with any modern design". Make it look like an HTML select tag, because that's what it is.
Functionality should (nearly always) trump prettification. (Especially when the results are pretty anyway).
Then don't make it look "in line with any modern design". Make it look like an HTML select tag, because that's what it is.
Functionality should (nearly always) trump prettification. (Especially when the results are pretty anyway).
I feel like it's important to establish that "controls should look like the browser intended and not be customizable" is an ideological stance, not an obvious and self-evident truth. And it's one that I strongly disagree with, because it's needlessly controlling: why shouldn't developers me able to make something look however they want? The web is a platform for _all kinds of creations_, not just "website that look and feel like websites", and people should have the freedom to do whatever they want and not be constrained by arbitrary limitations of bad APIs.
I feel like it's important to establish that "controls should look like the Web designer intended and be customizable" is an ideological stance, not an obvious and self-evident truth. And it's one that I strongly disagree with, because it's needlessly controlling: why should Web designers be able to make something look however they want? The web is a platform for _all kinds of users_, not just "websites that look and feel like a Web designer wants to", and people should have the freedom to use a site in whatever way they want and not be constrained by arbitrary limitations of bad custom form controls.
Gross.
You don’t have to style the select. If you are being forced to, your designers are either incompetent or ignorant. Aesthetics shouldn’t trump usability
By this logic, almost every designer is incompetent or ignorant. Styling form elements is not an extreme position, even if you might want it to be.
It's not that it isn't an extreme position, but I think you are right that many(most?) designers don't appreciate the usability tradeoffs they are requesting in doing so. Most designer I've had this discussion with have come around to not doing styling like this after having the tradeoffs explained to them.
Speaking of design trade-offs, I've found it's really hard to get stakeholders to appreciate the cost of implementing designs. Design cost should be part of the trade-off give-and-take of figuring out what can fit in a release or sprint or whatever, but often all those decisions happen too early in the process to do that. It's easy for one design decision to affect several "stories" and add tens of "points" (in typical agile terminology) to a project, and entirely possible that the stakeholders would rather have five more features than have that widget look and behave just so. Most designers don't seem to consider this much.
That was my initial point actually: a lot of these tradeoffs happen accidentally since for instance you have to write a custom component to do something basic as changing the background color of a select options.
If more powerful browser components would be available then designers would be happy to just style those, and functionality and accessibility would still be fine.
If more powerful browser components would be available then designers would be happy to just style those, and functionality and accessibility would still be fine.
Many designers I have worked with got into UI design from a graphic design/art/print background[1]. Many I have worked with had never read so much as a word from any OS platform's human interface guidelines and were, indeed, ignorant of HCI fundamentals.
[1] graphic design is a completely legitimate field and a good way to get into UI design, but if that's all you've got, you still have quite a way to go
[1] graphic design is a completely legitimate field and a good way to get into UI design, but if that's all you've got, you still have quite a way to go
Have you ever seen a designer define all the different states with all the different input methods for a select element?
That's an unpleasant thing to say about the people running Hacker News.
Take a look at the search page.
Take a look at the search page.
I think my statement is truthful, albeit harsh.
I don't believe there are many designers who are interested in creating experiences with poor usability, thus my point about ignorance and not understanding the tradeoff they are making. On "incompetence", if a designer understands fully that they are creating something that will be less useable and accessible for the sake of aesthetics they have earned the label. To take the HN search page as an example, the filters can't be interacted with via keybord or screen reader. When it's your job to help users solve problems and you have made it knowingly harder to do that, I don't see how that's competent.
Luckily, it has been my experience that in most cases(including my own) the former, rather than the latter, is at play.
I don't believe there are many designers who are interested in creating experiences with poor usability, thus my point about ignorance and not understanding the tradeoff they are making. On "incompetence", if a designer understands fully that they are creating something that will be less useable and accessible for the sake of aesthetics they have earned the label. To take the HN search page as an example, the filters can't be interacted with via keybord or screen reader. When it's your job to help users solve problems and you have made it knowingly harder to do that, I don't see how that's competent.
Luckily, it has been my experience that in most cases(including my own) the former, rather than the latter, is at play.
> Aesthetics shouldn’t trump usability
It's true, and it really shouldn't be as controversial an opinion as it apparently is.
It's true, and it really shouldn't be as controversial an opinion as it apparently is.
What kind of CSS do you need to add to <select>? Do you have an example of this modern design?
The dropdown listbox, optgroup labels, and options should all be part of the CSS box model and have all the styling options available. That would allow full styling (including border, margin, padding, text and background colour) and make the listbox match the other element styling.
That would go a long way, but doesn't support more complex UI like checkboxes in the dropdown (for a compact multiselect component), a treeview instead of a listbox (including checkbox support), and highlighting parts of option text for things like autocomplete (with the ability to filter based on what's being typed).
It would also be useful to know if the listbox is being displayed above or below the select, so with a rounded border, you can style both the select input and listbox to have a flat edge on the top or bottom accordingly.
For checkboxes, it should be possible to theme them more easily, including: 1. border width, colour, and radius for the box; 2. a graphic or unicode character for the checked and mixed states; 3. optionally an image for the entire checkbox.
That would go a long way, but doesn't support more complex UI like checkboxes in the dropdown (for a compact multiselect component), a treeview instead of a listbox (including checkbox support), and highlighting parts of option text for things like autocomplete (with the ability to filter based on what's being typed).
It would also be useful to know if the listbox is being displayed above or below the select, so with a rounded border, you can style both the select input and listbox to have a flat edge on the top or bottom accordingly.
For checkboxes, it should be possible to theme them more easily, including: 1. border width, colour, and radius for the box; 2. a graphic or unicode character for the checked and mixed states; 3. optionally an image for the entire checkbox.
What I think the web really needs is headless behavior via attributes.
Like onclick, onsubmit, etc? We already have those.
Also how inconsistent the look and behavior is from browser to browser. If you want to achieve uniformity across chrome/safari/ff, you basically have to go custom.
Date inputs are particularly terrible here once you try and do any constraints
Agree completely. I'm practically one new-tab-opened-without-me-asking away from forking a browser just to remove this behavior.
> anyone that has ever needed to style a <select>
No one has ever, in the history of software, NEEDED to style a <select>. You want to style a select. Your users don't give a toss.
No one has ever, in the history of software, NEEDED to style a <select>. You want to style a select. Your users don't give a toss.
Worst of those I encounter regularly is US sites trying to constrain your input to numbers only on certain fields.
Not "letting you input anything and marking it invalid if you put something other than a number", but listening to which key is pressed to allow the typing or not.
On French keyboards, typing a number requires the use of the SHIFT key. So I regularly need to change my keyboard layout just to type a couple numbers in a form field because someone thought they'd be smart...
Oh yeah I had that recently in a project (IE support required, so no type=number). When you try this, you will eventually find that you use so many keys during normal operation that a whitelist just isn't feasible. Left, right, tab, Home, End, Ctrl+C/V, Shift+Ins, …
Throwing away keys is never the right thing to do anyway. If the user typed 5y8 you don't know if they meant 58 or if the y was meant to be a 6 or 7 so the best thing to do is to have the field contain the full user input and higlight the input as invalid rather than silently guessing what the user meant.
Validate, don't parse ;p
I agree with the author that custom components don’t capture all the interaction details. Many times they are not accessible or cannot implement cross-platform input well.
However, I disagree with:
> The browser’s built-in controls are quite sufficient.
The problem is that browser components are good for simple forms but insufficient for other types of interaction.
A good example is select. Using the select tag is the best way to have a dropdown list that’s accessible and supports mobile. But, select doesn’t cover most of the cases that you need for a complex app.
Many of the WAI ARIA authoring examples (including the combobox patterns) are not covered by built in components. Interaction patterns like pop ups, dialogs, or lookup lists are quite common for an app… but hard to do in an accessible/cross-platform way.
Web browsers need to do something different to support accessible/usable apps. The idea of leaving all those things to WebComponents makes sense, but the result is reinventing the broken wheel on each app.
However, I disagree with:
> The browser’s built-in controls are quite sufficient.
The problem is that browser components are good for simple forms but insufficient for other types of interaction.
A good example is select. Using the select tag is the best way to have a dropdown list that’s accessible and supports mobile. But, select doesn’t cover most of the cases that you need for a complex app.
Many of the WAI ARIA authoring examples (including the combobox patterns) are not covered by built in components. Interaction patterns like pop ups, dialogs, or lookup lists are quite common for an app… but hard to do in an accessible/cross-platform way.
Web browsers need to do something different to support accessible/usable apps. The idea of leaving all those things to WebComponents makes sense, but the result is reinventing the broken wheel on each app.
Yep I totally agree with this.
There are however a bunch of ARIA tags & best practices etc (https://w3c.github.io/aria-practices/) that exist to make popups and dialogs (and other things e.g. tree views or "email-inbox-style" "treegrids" etc) accessible (if implemented correctly).
I am conflicted about these - it is nice that there are ARIA tags for this, but it would also be nice if browsers "understood" aria tags and added some default behaviors (e.g. keyboard navigation). As it is, ARIA tags are essentially "pointless" to anyone who doesn't use an assistive technology, and so non-assitive-technology users nor developers benefit from using ARIA tags so they are often forgotten. If the browsers saw that there was an A11y-tree that matched a treeview or a treegrid, it would be really really nice if they applied some default common keyboard navigation implementation, rather than do nothing and leave it up to the developer to decide what keys do what on each and every site. .... Or on the other hand, is that too prescriptive and should we give developers and UX designers more leeway to design something better, rather than rely on browser-enforced defaults? I guess we are happy with browser defaults for basic inputs, but would we be for a treegrid?
There are however a bunch of ARIA tags & best practices etc (https://w3c.github.io/aria-practices/) that exist to make popups and dialogs (and other things e.g. tree views or "email-inbox-style" "treegrids" etc) accessible (if implemented correctly).
I am conflicted about these - it is nice that there are ARIA tags for this, but it would also be nice if browsers "understood" aria tags and added some default behaviors (e.g. keyboard navigation). As it is, ARIA tags are essentially "pointless" to anyone who doesn't use an assistive technology, and so non-assitive-technology users nor developers benefit from using ARIA tags so they are often forgotten. If the browsers saw that there was an A11y-tree that matched a treeview or a treegrid, it would be really really nice if they applied some default common keyboard navigation implementation, rather than do nothing and leave it up to the developer to decide what keys do what on each and every site. .... Or on the other hand, is that too prescriptive and should we give developers and UX designers more leeway to design something better, rather than rely on browser-enforced defaults? I guess we are happy with browser defaults for basic inputs, but would we be for a treegrid?
The WAI-ARIA Authoring Practices are not best practices, they are not carefully researched to ensure they can be successfully used in a variety of browsers or with a variety of assistive technologies. They include examples that don't work properly with common browser/screen reader combinations (like Safari + VoiceOver). They'll use ARIA approaches even when they're not the only or best way to achieve a goal. They're best thought of as patterns designed to "exercise" a browser's support for ARIA attributes, browser developers can use them to test whether their implementation of ARIA support matches expectations.
Nevertheless, some of them are perfectly good solutions as-is and can serve as a good starting point.
I would also like browsers to have more capabilities "baked in;" browsers should offer keyboard navigation of ARIA landmarks (both implicit ones created by <header>, <main>, <footer>, etc. and explicit `role` attributes). I don't like the idea of browsers automatically creating interactive controls based on the presence of ARIA attributes, I'd rather there be new HTML elements, ones that document stylability much better than old ones did.
I'm interested in Open UI's [0] work, attempting to develop common web components, ones that can be useful in the short term and may serve as the basis for new HTML elements in the future. They're sort of documenting cow paths that HTML in the future can pave, similar to HTML5 elements being named based on common class names or useful additions to JavaScript having been based on features in libraries like jQuery (obviously without adopting jQuery's syntax).
[0] https://open-ui.org/
Nevertheless, some of them are perfectly good solutions as-is and can serve as a good starting point.
I would also like browsers to have more capabilities "baked in;" browsers should offer keyboard navigation of ARIA landmarks (both implicit ones created by <header>, <main>, <footer>, etc. and explicit `role` attributes). I don't like the idea of browsers automatically creating interactive controls based on the presence of ARIA attributes, I'd rather there be new HTML elements, ones that document stylability much better than old ones did.
I'm interested in Open UI's [0] work, attempting to develop common web components, ones that can be useful in the short term and may serve as the basis for new HTML elements in the future. They're sort of documenting cow paths that HTML in the future can pave, similar to HTML5 elements being named based on common class names or useful additions to JavaScript having been based on features in libraries like jQuery (obviously without adopting jQuery's syntax).
[0] https://open-ui.org/
The open-ui is only potentially good when you need something that resembles the standard controls and interactions. At the moment it only has a few controls specified and if you need anything not covered by those you are going to end up creating your own UI -- e.g. using a treeview dropdown instead of a listbox, or if you have a form with multiple checkboxes and need that group of checkboxes to be a role=select from an ARIA perspective in order to place form error messages on that group so that screen readers read the error set on the ARIA description, but still display as a list of checkboxes to the user.
When you have custom UI, then you need to mark that up in a way that is accessible and implement things like keyboard navigation properly. No matter how many standardized UI elements you create there will always be cases where you need to use ARIA markup and not just for styling/theming, but for accessibility as well like in my form error example above.
The ARIA authoring practices is the best thing I know of that does that, along with other resources like www.a11ymatters.com for patterns like pagination.
If you are saying that the authoring practices isn't good enough, then what we need is a battle tested guide on how to implement all of the UI patterns (disclosure, dialog, select, etc.) that works on all screen reader/browser combinations and documents all current features (ARIA, keyboard, dark mode, reduced motion, styling/theming, etc.). It should also include notes on what issues and resolutions to look out for, and details on what users of assistive technologies are looking for (e.g. when and what content should be read out).
You can (and should) have a set of common components that implement these patterns in a way that can easily be styled to handle 80% of the use cases. But there should also be a way to support the other 20% of use cases -- which is what ARIA was designed for.
When you have custom UI, then you need to mark that up in a way that is accessible and implement things like keyboard navigation properly. No matter how many standardized UI elements you create there will always be cases where you need to use ARIA markup and not just for styling/theming, but for accessibility as well like in my form error example above.
The ARIA authoring practices is the best thing I know of that does that, along with other resources like www.a11ymatters.com for patterns like pagination.
If you are saying that the authoring practices isn't good enough, then what we need is a battle tested guide on how to implement all of the UI patterns (disclosure, dialog, select, etc.) that works on all screen reader/browser combinations and documents all current features (ARIA, keyboard, dark mode, reduced motion, styling/theming, etc.). It should also include notes on what issues and resolutions to look out for, and details on what users of assistive technologies are looking for (e.g. when and what content should be read out).
You can (and should) have a set of common components that implement these patterns in a way that can easily be styled to handle 80% of the use cases. But there should also be a way to support the other 20% of use cases -- which is what ARIA was designed for.
>a form with multiple checkboxes and need that group of checkboxes to be a role=select from an ARIA perspective in order to place form error messages on that group so that screen readers read the error set on the ARIA description, but still display as a list of checkboxes to the user.
ARIA 'select' is an abstract role, it's not meant to be used in code [0]. Form inputs should be grouped by HTML, <fieldset>, and error messages should go where they make sense; the fieldset's <legend> is the name of the group but since it is repeated like a description after the name of each child input, it could be useful to add an error message to it.
> If you are saying that the authoring practices isn't good enough, then what we need is a battle tested guide on how to implement all of the UI patterns
I am saying that, the Authoring Practices examples aren't battle-tested, that's not what they're for. For example, their disclosure widget examples look okay (though in real life at least some of them should be just <details> <summary> elements) but their modal dialog example won't reliably keep screen readers from navigating to other parts of the page while it's open.
No one with the resources is willing to create and maintain a library of components, in part because it seems like there's not an 80/20 divide, that it's much more common that people need some variation from whatever is standard (or think they do).
There's https://a11ysupport.io for sharing user-submitted tests but that's simply a record of what individual ARIA attributes and HTML elements work with various assistive technology and browser combinations (without specifying their version numbers).
[0] https://www.w3.org/TR/wai-aria-1.2/#select
ARIA 'select' is an abstract role, it's not meant to be used in code [0]. Form inputs should be grouped by HTML, <fieldset>, and error messages should go where they make sense; the fieldset's <legend> is the name of the group but since it is repeated like a description after the name of each child input, it could be useful to add an error message to it.
> If you are saying that the authoring practices isn't good enough, then what we need is a battle tested guide on how to implement all of the UI patterns
I am saying that, the Authoring Practices examples aren't battle-tested, that's not what they're for. For example, their disclosure widget examples look okay (though in real life at least some of them should be just <details> <summary> elements) but their modal dialog example won't reliably keep screen readers from navigating to other parts of the page while it's open.
No one with the resources is willing to create and maintain a library of components, in part because it seems like there's not an 80/20 divide, that it's much more common that people need some variation from whatever is standard (or think they do).
There's https://a11ysupport.io for sharing user-submitted tests but that's simply a record of what individual ARIA attributes and HTML elements work with various assistive technology and browser combinations (without specifying their version numbers).
[0] https://www.w3.org/TR/wai-aria-1.2/#select
> ARIA 'select' is an abstract role, it's not meant to be used in code [0]. Form inputs should be grouped by HTML, <fieldset>, and error messages should go where they make sense; the fieldset's <legend> is the name of the group but since it is repeated like a description after the name of each child input, it could be useful to add an error message to it.
Thanks for the fieldset tip.
> > If you are saying that the authoring practices isn't good enough, then what we need is a battle tested guide on how to implement all of the UI patterns
> I am saying that, the Authoring Practices examples aren't battle-tested, that's not what they're for.
Oh right. That makes sense. I use those as a reference point, not as something to use as-is. I mainly refer to the keyboard, role, and attribute specification in the main document, as they are clearly specified.
Thanks for the fieldset tip.
> > If you are saying that the authoring practices isn't good enough, then what we need is a battle tested guide on how to implement all of the UI patterns
> I am saying that, the Authoring Practices examples aren't battle-tested, that's not what they're for.
Oh right. That makes sense. I use those as a reference point, not as something to use as-is. I mainly refer to the keyboard, role, and attribute specification in the main document, as they are clearly specified.
> I would also like browsers to have more capabilities "baked in;" browsers should offer keyboard navigation of ARIA landmarks (both implicit ones created by <header>, <main>, <footer>, etc. and explicit `role` attributes).
Opera 12 does that. It predates ARIA, so it navigates based on the elements available at that time. Default keys (Tools → Preferences → Advanced → Shortcuts → Keyboard setup → Edit… → Input context and shortcuts → Document Window):
• a : Highlight next URL
• q : Highlight previous URL
• s : Highlight next heading
• w : Highlight previous heading
• d : Highlight next element
• e : Highlight previous element
I can mash the keys like crazy to get where I want. The browser is super responsive, keyboard navigation is a joy to use.
The browser also offers spatial navigation (Shift + arrow keys), this navigates interactables not by their functionality, but by their apparent position to each other.
Opera 12 does that. It predates ARIA, so it navigates based on the elements available at that time. Default keys (Tools → Preferences → Advanced → Shortcuts → Keyboard setup → Edit… → Input context and shortcuts → Document Window):
• a : Highlight next URL
• q : Highlight previous URL
• s : Highlight next heading
• w : Highlight previous heading
• d : Highlight next element
• e : Highlight previous element
I can mash the keys like crazy to get where I want. The browser is super responsive, keyboard navigation is a joy to use.
The browser also offers spatial navigation (Shift + arrow keys), this navigates interactables not by their functionality, but by their apparent position to each other.
Oh the combobox element in the WAI ARIA is interesting. On mobile the dropdown can‘t be scrolled without scrolling the page (and the user losing where they were in the form). Also the tap targets are smaller.
And there even is a combobox in HTML5. It‘s an input with a list attribute.
And there even is a combobox in HTML5. It‘s an input with a list attribute.
Do you mean <datalist>? It doesn't meet all use cases (especially if what needs to be listed requires dynamic updating) but browser support slowly has gotten better.
Unfortunately, I recently heard that all the major browsers fail to resize the datalist text on zoom (my guess is it's rendered outside the DOM, like the browser's UI).
Bug report for Firefox: https://bugzilla.mozilla.org/show_bug.cgi?id=1756203
Unfortunately, I recently heard that all the major browsers fail to resize the datalist text on zoom (my guess is it's rendered outside the DOM, like the browser's UI).
Bug report for Firefox: https://bugzilla.mozilla.org/show_bug.cgi?id=1756203
Datalist has some unfortunate UX quirks in my experience. Trying to view the list of available items after you have already selected one is not possible on the browsers I used this week. A select will allow you to view the list regardless of the current value.
It's suuuper annoying when the type-to-pick-dropdown doesn't work. Mildly annoying for US states, I live in Illinois, so when it flashes "Idaho", "Louisiana", oh boy. These are usually the forms that then have a 'fake' dropdown for credit card expiration dates, so I can't type-to-pick the month/year either.
As a chinese user, I don't know this function until now.
Character in chinese requires multi keystroke. And the IME won't be even triggered when you are not focusing a text field, render the whole function useless.
So, a common pattern here is "use combobox instead". Because combobox has a working input field build-in, make it usable with chinese.
But.... the HTML don't have combobox build-in, so you end up get one in literally any ui framework or a handwritten one if you really don't want to use framework.
Character in chinese requires multi keystroke. And the IME won't be even triggered when you are not focusing a text field, render the whole function useless.
So, a common pattern here is "use combobox instead". Because combobox has a working input field build-in, make it usable with chinese.
But.... the HTML don't have combobox build-in, so you end up get one in literally any ui framework or a handwritten one if you really don't want to use framework.
> HTML don't have combobox build-in
Yes, it does. Supported in browsers since 2010, specified earlier. You have not taken the time to research this topic.
Yes, it does. Supported in browsers since 2010, specified earlier. You have not taken the time to research this topic.
<input list="administrative_areas" name="PRC_AA" />
<datalist id="administrative_areas">
<option value="华北">
<option value="东北">
<option value="华东">
<option value="中南">
<option value="西北">
<option value="西南">
</datalist>
I think this don't really work as a combo box on firefox, more like auto complete.
It is some what a replacement on chrome, because chrome decide to show it with arrow point to bottom.
And in both firefox and chrome. It don't even have a indicator display by default to tell you "you are supposed to select it, not type it" or "Type yourself is invalid, you need to use predefined options".
It is some what a replacement on chrome, because chrome decide to show it with arrow point to bottom.
And in both firefox and chrome. It don't even have a indicator display by default to tell you "you are supposed to select it, not type it" or "Type yourself is invalid, you need to use predefined options".
It's not very good tho. It offers some autocomplete suggestions once you type the first character, but there's no indicator that there's a hidden list there. It seems if you double click on the input you can pull up the full list, but no one would know that.
Spotify custom implemented this for their desktop client. You could right click on a song, open the submenu "add to playlist", and type a few characters. Idk why they bothered custom implementing that when a select list is a standard element no matter what framework they use, but I was happy. Then cometh the update and the feature be regressed. I now need to use the mouse for literally everything, including looking through this list with no discernable sorting (it's not alphabetical). Only spacebar for play/pause survived, all other keyboard controls seem gone or I can't guess them.
Just use normal components. Save the effort, help the screen reader, please the power user. Please.
Just use normal components. Save the effort, help the screen reader, please the power user. Please.
Ugh, Slack too. For ages they didn't have right-click menus anywhere. Then a while ago, they added right-click menus to channels, but of course they couldn't just use the native menus that every OS already has, so it's some HTML abomination that had to rewrite the wheel for handling things like lenient mouse movement (e.g. https://css-tricks.com/dropdown-menus-with-more-forgiving-mo...). Still doesn't support type-to-select, or god knows how many other accessibility and power user niceties.
I don't know if Electron has an API for menus, but the HTML elements that let you add items to the native contextmenu were scrapped, and every browser I know of renders their own menus on Windows/Linux anyway. There is not a way to add a native contextmenu unless you do something cursed like positioning an invisible <select> where the mouse is and opening it on right click.
Edit: Never mind, there is no way to open a <select> with JS.
Edit: Never mind, there is no way to open a <select> with JS.
I know, but other Electron apps manage to do it (VS Code, Postman), so there must be a way.
edit: some quick googling reveals there is an API for this https://www.electronjs.org/docs/latest/api/menu#class-menu
edit: some quick googling reveals there is an API for this https://www.electronjs.org/docs/latest/api/menu#class-menu
You could organize your playlist in folders. Not a solution but that might make it bearable :P
what does this have to do with form fields? edit: I see you think that context menus are form fields. Thats incorrect.
It's not about form fields, it's about type-to-select. No one said anything about context menus being the same as form fields.
did you read the article? the context of this entire thread is about form fields.
As long as it's not one of the sites that truncates passwords differently at signup and at login, I can probably manage.
Bonus points for when the month is the name of the month.
I just figured out one thing: when delay between keystrokes is < 100ms or less the search through options works and it will highlight Illinois. (Chrome)
For text inputs and select dropdowns, yes, we take them for granted because the simple case is simple -- but there really is so much complexity in keyboard navigation and interaction. Reaching parity in a JS implementation would be a serious undertaking and would usually not be the right thing to do.
However, there are some controls, like date and color inputs, whose browser implementations are both inconsistent and severely UX-challenged such that no professional web site/app would really be able to use them in production. For these, in 2022, we still have no choice but to build custom implementations in order to meet usually expectations.
However, there are some controls, like date and color inputs, whose browser implementations are both inconsistent and severely UX-challenged such that no professional web site/app would really be able to use them in production. For these, in 2022, we still have no choice but to build custom implementations in order to meet usually expectations.
A native date input might be inconsistent between different browsers, or different OSs, but it will be consistent with the native date input on every single other website the user goes to. If they're lucky, it will be consistent with the date input field on every other application on their OS.
The only intuitive interface is the nipple. Everything else is learned. If the user has leaned how to use the native date picker on their browser, they know how to use the date picker on your website.
If you make them learn how to use a new date picker for your website, it's very unlikely they'll thank you for being able to transfer this unique knowledge to that one website of yours on the very unlikely chance they choose to switch browsers. I mean, who does that regularly?
And if the native date picker in their browser doesn't work for them - maybe because aesthetics, maybe because accessibility - they can either pick a different theme for their browser, or pick a different browser. (Or a different OS!) That has the advantage of fixing the native date picker on every single website they go to. Except for the annoying websites which implement their own, where if the custom date picker doesn't work for them, they're fucked.
If someone's using a browser with an date picker you happen to dislike, that's their choice. Let them have it.
The only intuitive interface is the nipple. Everything else is learned. If the user has leaned how to use the native date picker on their browser, they know how to use the date picker on your website.
If you make them learn how to use a new date picker for your website, it's very unlikely they'll thank you for being able to transfer this unique knowledge to that one website of yours on the very unlikely chance they choose to switch browsers. I mean, who does that regularly?
And if the native date picker in their browser doesn't work for them - maybe because aesthetics, maybe because accessibility - they can either pick a different theme for their browser, or pick a different browser. (Or a different OS!) That has the advantage of fixing the native date picker on every single website they go to. Except for the annoying websites which implement their own, where if the custom date picker doesn't work for them, they're fucked.
If someone's using a browser with an date picker you happen to dislike, that's their choice. Let them have it.
This is a strange take: Native date pickers are broken in every mainstream browser, which is what the majority of our users use. People don't consciously "choose" browsers. They use whatever was preinstalled or someone recommended them ten years ago.
Our customers don't care about other browsers, Open Source software, or the nuance of native input fields. "Look, on AirBnb I can enter dates in a humane way, why is it so hard on your website?" - I just don't get away with recommending them to switch browsers.
Having accepted that premise, we can talk about the custom implementations: I would never recommend rolling your own, either. There are several widely used library for date pickers that users are accustomed to, are accessible, and miles ahead of the native controls. There is absolutely nothing wrong with sticking to those libraries until the vendors finally fix their mess.
Our customers don't care about other browsers, Open Source software, or the nuance of native input fields. "Look, on AirBnb I can enter dates in a humane way, why is it so hard on your website?" - I just don't get away with recommending them to switch browsers.
Having accepted that premise, we can talk about the custom implementations: I would never recommend rolling your own, either. There are several widely used library for date pickers that users are accustomed to, are accessible, and miles ahead of the native controls. There is absolutely nothing wrong with sticking to those libraries until the vendors finally fix their mess.
The funny thing is that, at least on Windows[0], there actually isn't a standard color picker. Or, well, there is, but it's one of those common-controls dialogs that hasn't gotten a UI refresh since Windows 3. People writing native apps that need to pick colors wind up writing their own color pickers[1]. Even Microsoft does this: Paint gives you the same obsolete system color picker I mentioned before, but Paint 3D ships with it's own[2].
If you ask a browser on Windows for a color picker, you get the old-and-busted one. Given the odd bifurcation in Windows UI since 8, I suspect date pickers are the same way, and the one the browser gives you won't actually match what other native apps are doing. So what happens if you decide to do the "right thing", is that you get a demonstrably worse user experience for your forms for the vast majority of people who do not know how to retheme native UI and have zero familiarity with the old Windows controls that browsers continue to throw at people.
[0] macOS has a native color picker that is apparently so good that someone reimplemented it for iPadOS.
[1] Adobe isn't even consistent among their own suite. The Photoshop color picker is entirely different from the Premiere or Animate ones, for example.
[2] I suspect the Paint 3D color picker may be a XAML default, but up until very recently the prospects of actually using XAML in most apps was very dim. More specifically, XAML used to be either exclusive to .NET/C#, or exclusive to Microsoft Store apps, neither of which were conducive to native software that need to live outside of an app container sandbox and be distributed through Steam.
If you ask a browser on Windows for a color picker, you get the old-and-busted one. Given the odd bifurcation in Windows UI since 8, I suspect date pickers are the same way, and the one the browser gives you won't actually match what other native apps are doing. So what happens if you decide to do the "right thing", is that you get a demonstrably worse user experience for your forms for the vast majority of people who do not know how to retheme native UI and have zero familiarity with the old Windows controls that browsers continue to throw at people.
[0] macOS has a native color picker that is apparently so good that someone reimplemented it for iPadOS.
[1] Adobe isn't even consistent among their own suite. The Photoshop color picker is entirely different from the Premiere or Animate ones, for example.
[2] I suspect the Paint 3D color picker may be a XAML default, but up until very recently the prospects of actually using XAML in most apps was very dim. More specifically, XAML used to be either exclusive to .NET/C#, or exclusive to Microsoft Store apps, neither of which were conducive to native software that need to live outside of an app container sandbox and be distributed through Steam.
> macOS has a native color picker that is apparently so good that someone reimplemented it for iPadOS.
I recall the colour picker being one of the first features that blew my mind upon getting my first Mac running 10.3. I could save swatches OS-wide, I could switch between different selection modes (and install custom modes of my own), and I could even use an eyedropper-like tool to sample any pixel on the screen.
There's probably some LinkedIn allegory about attention to detail in there.
I recall the colour picker being one of the first features that blew my mind upon getting my first Mac running 10.3. I could save swatches OS-wide, I could switch between different selection modes (and install custom modes of my own), and I could even use an eyedropper-like tool to sample any pixel on the screen.
There's probably some LinkedIn allegory about attention to detail in there.
> And if the native date picker in their browser doesn't work for them - maybe because aesthetics, maybe because accessibility - they can either pick a different theme for their browser, or pick a different browser.
Or, you know, if aesthetics or accessibility doesn't work with a native picker I might just use a third-party one instead of requiring my users to switch browsers and OSes.
Native date input have horrendously/hillariously bad implementations in all desktop browsers. I can't even begin to imagine thinking about using them for anything.
Or, you know, if aesthetics or accessibility doesn't work with a native picker I might just use a third-party one instead of requiring my users to switch browsers and OSes.
Native date input have horrendously/hillariously bad implementations in all desktop browsers. I can't even begin to imagine thinking about using them for anything.
Someone with particular accessibility needs might not be using a popular desktop browser - they'll already be using a user-agent which is adapted to their own needs.
If you use native input elements, then whatever accessibility needs a user might have can be accommodated by a user-agent which caters to those needs. And you get that to take advantage of that for free.
If you roll your own, you can't cater to people with disabilities that you haven't considered.
If you use native input elements, then whatever accessibility needs a user might have can be accommodated by a user-agent which caters to those needs. And you get that to take advantage of that for free.
If you roll your own, you can't cater to people with disabilities that you haven't considered.
> Someone with particular accessibility needs
Accessibility is not black and white. I have good vision, and native date pickers as implemented in all desktop browsers, are so tiny, I have to zoom the page every time I encounetr them.
> If you roll your own, you can't cater to people with disabilities that you haven't considered.
True, but you out of hand dismissed huge swaths of people who are not using "adapted user-aganets" but still suffer because browsers have a shitty native implementation.
Accessibility is not black and white. I have good vision, and native date pickers as implemented in all desktop browsers, are so tiny, I have to zoom the page every time I encounetr them.
> If you roll your own, you can't cater to people with disabilities that you haven't considered.
True, but you out of hand dismissed huge swaths of people who are not using "adapted user-aganets" but still suffer because browsers have a shitty native implementation.
I don't understand this sentiment. Why would it matter whether the UX is different between browsers for a date or colour input?
In the end, if it inserts a date, or a hex colour representation, then I am happy.
Although now that I think about it, there's a chance a date input would return `mm-dd-yyyy` or `dd-mm-yyyy` depending on locale. To have it return a unix datetime would probably be easier for everybody.
In the end, if it inserts a date, or a hex colour representation, then I am happy.
Although now that I think about it, there's a chance a date input would return `mm-dd-yyyy` or `dd-mm-yyyy` depending on locale. To have it return a unix datetime would probably be easier for everybody.
> I don't understand this sentiment. Why would it matter whether the UX is different between browsers for a date or colour input?
It’s not just a question of consistency: some of HTML UI elements are still in pre-alpha stage in modern browsers, almost completely broken, despite being part of the standard for many years. It’s a joke.
For an example, check out the RANGE element; you will find no shortage of articles complaining about how ridiculously broken and unusable it is.
It’s not just a question of consistency: some of HTML UI elements are still in pre-alpha stage in modern browsers, almost completely broken, despite being part of the standard for many years. It’s a joke.
For an example, check out the RANGE element; you will find no shortage of articles complaining about how ridiculously broken and unusable it is.
> For an example, check out the RANGE element; you will find no shortage of articles complaining about how ridiculously broken and unusable it is.
Could you shed some more light on this? I couldn't find anything from a cursory search. Looking at the W3Schools demo[0], it doesn't look too bad (other inputs set the bar really low). Is it not very friendly with styling? I hear that a lot when people talk about native browser controls.
[0]: https://www.w3schools.com/tags/tryit.asp?filename=tryhtml5_i...
Could you shed some more light on this? I couldn't find anything from a cursory search. Looking at the W3Schools demo[0], it doesn't look too bad (other inputs set the bar really low). Is it not very friendly with styling? I hear that a lot when people talk about native browser controls.
[0]: https://www.w3schools.com/tags/tryit.asp?filename=tryhtml5_i...
The browser date pickers will always return YYYY-MM-DD to your server when they send a request. What's exposed to the user is usually localised. This is the behaviour you want.
Tangent: I wonder why, after having standards like ISO 8601 for decades, stuff like this is something we even have to think about. On a technical level, there's a need for exactly two date time formats: Monotonically increasing integer timestamps, and ISO 8601 style date time with timezones.
A big part of the reason that JavaScript controls can't capture the nuance is because it takes a lot of work to capture the nuance. So teams justifiably implement the 90% use case and move on.
There are projects that dedicate an unreasonable amount of resources to making these controls in JavaScript and show just how far you can get in JS. For example, https://headlessui.dev.
EDIT:
To directly address the "invisible buffer" thing, look at this control from Headless UI: https://headlessui.dev/react/listbox.
Open it, start typing, and notice the invisible buffer actually does work here.
There are projects that dedicate an unreasonable amount of resources to making these controls in JavaScript and show just how far you can get in JS. For example, https://headlessui.dev.
EDIT:
To directly address the "invisible buffer" thing, look at this control from Headless UI: https://headlessui.dev/react/listbox.
Open it, start typing, and notice the invisible buffer actually does work here.
The "invisible buffer" doesn't match OS X functionality (with Firefox if it matters).
In the state dropdown of the article I can type "New J" to highlight "New Jersey" and then press backspace + "Y" and it will highlight "New York". In the headless UI version if I try similar "To" to get "Tom…" but if I press backspace and "a" I don't get "Tanya…" I get "Arlene…"
In the state dropdown of the article I can type "New J" to highlight "New Jersey" and then press backspace + "Y" and it will highlight "New York". In the headless UI version if I try similar "To" to get "Tom…" but if I press backspace and "a" I don't get "Tanya…" I get "Arlene…"
On Firefox on Linux, I get a different incorrect behavior. "To" + backspace + "a" (fast enough that it doesn't trigger the timeout for starting a new search) remains on "Tom...".
I just tried this with a native <select> in Safari, Chrome, and Firefox and they all worked like the Headless UI version, where a single backspace clears your entire buffer.
Also, it doesn't let you type-to-select when the box is focused but the dropdown is not expanded.
But... why not style the built-in controls?
I mean in addition to this keyboard UX, there's accessibility to consider; screen/braille readers, alternative input methods, etc.
I mean in addition to this keyboard UX, there's accessibility to consider; screen/braille readers, alternative input methods, etc.
Because in a lot of cases, browsers don't expose the necessary APIs to do so. That being said, most component libraries I've seen that implement custom controls (which do expose APIs to allow styling) will make a point of adding all the necessary ARIA attributes to make controls properly accessible.
>But... why not style the built-in controls?
As devs we don't decide, we get soem designs, like make a numeric input that looks like in this picture, make a select that can show a different icon for each option()like a language select with flag icons)), or make a font select that each item has it;s own font family.
Then you have stuff that are clasic things in normal GUI toolkits like accordions, tree views, very efficient grid/list views(I mean a widget where you can load 10K items and not have to implement your own smart loading or the lazy pagination way).
I did not done too much mobile but I remember there are some "tabbed/stacked views" , you can put your components in this views and would be efficiently loaded and unloaded when you moved from one view to other making things start faster and use less memory.
Not sure why the browser makers ignore this stuff, did they give up and we just have to use third party libraries for simple things like a good select and a working GridView?
As devs we don't decide, we get soem designs, like make a numeric input that looks like in this picture, make a select that can show a different icon for each option()like a language select with flag icons)), or make a font select that each item has it;s own font family.
Then you have stuff that are clasic things in normal GUI toolkits like accordions, tree views, very efficient grid/list views(I mean a widget where you can load 10K items and not have to implement your own smart loading or the lazy pagination way).
I did not done too much mobile but I remember there are some "tabbed/stacked views" , you can put your components in this views and would be efficiently loaded and unloaded when you moved from one view to other making things start faster and use less memory.
Not sure why the browser makers ignore this stuff, did they give up and we just have to use third party libraries for simple things like a good select and a working GridView?
I mean... you have to know that styling the default controls usually falls vastly short of what you're trying to do.
I have implemented many custom form controls. The reason is almost always because the design requires it. But other reasons can be to "improve" the control; for the select box to make the invisible edit buffer visible. I appreciate this is not the way but it is also pretty annoying how limited the styling, and customization, of form controls is.
We use Angular so it's pretty easy to hide the custom control and have a plain control for accessibility. At least for checkbox and radio inputs, am I the only one that uses a hidden input to control the style of some div to make it look fancy like the design required?
We use Angular so it's pretty easy to hide the custom control and have a plain control for accessibility. At least for checkbox and radio inputs, am I the only one that uses a hidden input to control the style of some div to make it look fancy like the design required?
The UI designers I had worked with do not have much experience working with the web platform as a user or developer, are not aware of capabilities default controls provide and almost never use the products they've designed. Additional exposure of UI compared to under-the-hood stuff begs for additional bikeshedding and micromanagement by people who understand this even less, like management. Maybe I never met good a designer or worked in a company with sane process.
In my (very limited) experience, the "hidden input" approach seems to be a reasonable approach. All the w3schools guides I've followed seem to do it that way.
disclaimer: 95% of my "modern" web frontend experience consists of non-professional goofing off in Svelte.
disclaimer: 95% of my "modern" web frontend experience consists of non-professional goofing off in Svelte.
Sadly this is the "right" way, and as many other commenters in this thread have pointed out, the sad state of default browser components is to blame.
If a designer wants me to do a custom control, I usually explain them why it's a bad idea and instead style the standard one.
It's such a blanket statement to say "you can't". Those controls themselves are coded up mostly using JavaScript so it is defiantly possible. It just requires a lot of work.
The most accessible component library that I've seen is Adobe Spectrum React[1] which supports all of those nuances mentioned here for all of their controls and allow for styling and customization.
[1] https://react-spectrum.adobe.com/react-spectrum/index.html
The most accessible component library that I've seen is Adobe Spectrum React[1] which supports all of those nuances mentioned here for all of their controls and allow for styling and customization.
[1] https://react-spectrum.adobe.com/react-spectrum/index.html
> supports all of those nuances mentioned here for all of their controls and allow for styling and customization
I don't believe it.
Just tried the picker https://react-spectrum.adobe.com/react-spectrum/Picker.html and within 30 seconds you can find divergences from the browser's behaviour.
The invisible input field behaviour Drew mentions in the article doesn't work. If I hit backspace, my browser doesn't know I'm in an input field and (correctly) navigates me to the previous page.
In Firefox, if I use tab I can select my native <select> and it gets focus styling - not so with Adobe Spectrum React's equivalent control. Once I have focus, I can start typing to select items without opening the dropdown list. Typing whilst I've tabbed on to the React control does nothing. With the native control I can hit space to open up the menu and view the items once I have focus. With the React control, hitting space does nothing.
I also looked at elements like the switch and checkboxes. With native components I can click in the empty space before a form control and be confident that the next <Tab> press I perform will focus the control for me. This behaviour doesn't work with Adobe Spectrum React's equivalent control's - I end up tabbing straight over the components altogether.
> It's such a blanket statement to say "you can't".
It's a blanket statement, sure, but in my experience it's absolutely true and I don't know why it's always frontend JS developers who are arrogant enough to think they can reinvent decades of work on e.g. Gtk in their crappy UI controls library but it's quite tiresome. Spoiler alert: you can't and won't, stop trying.
I don't believe it.
Just tried the picker https://react-spectrum.adobe.com/react-spectrum/Picker.html and within 30 seconds you can find divergences from the browser's behaviour.
The invisible input field behaviour Drew mentions in the article doesn't work. If I hit backspace, my browser doesn't know I'm in an input field and (correctly) navigates me to the previous page.
In Firefox, if I use tab I can select my native <select> and it gets focus styling - not so with Adobe Spectrum React's equivalent control. Once I have focus, I can start typing to select items without opening the dropdown list. Typing whilst I've tabbed on to the React control does nothing. With the native control I can hit space to open up the menu and view the items once I have focus. With the React control, hitting space does nothing.
I also looked at elements like the switch and checkboxes. With native components I can click in the empty space before a form control and be confident that the next <Tab> press I perform will focus the control for me. This behaviour doesn't work with Adobe Spectrum React's equivalent control's - I end up tabbing straight over the components altogether.
> It's such a blanket statement to say "you can't".
It's a blanket statement, sure, but in my experience it's absolutely true and I don't know why it's always frontend JS developers who are arrogant enough to think they can reinvent decades of work on e.g. Gtk in their crappy UI controls library but it's quite tiresome. Spoiler alert: you can't and won't, stop trying.
> Just tried the picker https://react-spectrum.adobe.com/react-spectrum/Picker.html and within 30 seconds you can find divergences from the browser's behaviour.
Took me exactly three key presses. I navigate using vimium. I just don't know how to pick anything on vimium without my mouse on this, while standard select work just fine.
Took me exactly three key presses. I navigate using vimium. I just don't know how to pick anything on vimium without my mouse on this, while standard select work just fine.
> In Firefox, if I use tab I can select my native <select> and it gets focus styling - not so with Adobe Spectrum React's equivalent control. Once I have focus, I can start typing to select items without opening the dropdown list. Typing whilst I've tabbed on to the React control does nothing. With the native control I can hit space to open up the menu and view the items once I have focus. With the React control, hitting space does nothing.
I just tried the link (in Firefox) and all of these work correctly.
> I also looked at elements like the switch and checkboxes. With native components I can click in the empty space before a form control and be confident that the next <Tab> press I perform will focus the control for me. This behaviour doesn't work with Adobe Spectrum React's equivalent control's - I end up tabbing straight over the components altogether.
What do you mean, "click in the empty space before a form control"?
I just tried the link (in Firefox) and all of these work correctly.
> I also looked at elements like the switch and checkboxes. With native components I can click in the empty space before a form control and be confident that the next <Tab> press I perform will focus the control for me. This behaviour doesn't work with Adobe Spectrum React's equivalent control's - I end up tabbing straight over the components altogether.
What do you mean, "click in the empty space before a form control"?
Also the picker is broken on iOS. If the bottom navigation bar is hidden the backdrop doesn‘t cover the whole page, which is ugly. More ugly then just a standard select element. Selecting by swiping over the elements doesn‘t work. And sometimes an accidental swipe and tap jumps to the top of the page. If Adobe can‘t support iPhone for everyone with less people power is better off using the existing form elements.
Nor should we want to! I have spent a week trying just to make my forms screen-reader-friendly and it is very hard, especially if you're using a library already to build the components. But the reason I know it won't work is that all my changes look like weird hacks and are bound to be immediately broken by the next person to work on them that's not using a screenreader.
in both examples where you claim this doesn't work it worked for me. clicking on an empty space next to the form element and hitting tab focused correctly for me. Also tabbing then starting to type worked as well. I tested in FF and Chrome. Are you sure the options exist in the select box when you type? That would make it seem like type completion doesn't work. I Tried the checkbox and radio buttons example in FF and Chrome both auto select the field and using arrow keys to make options selected worked just like native. I think the error is somewhere between keyboard and chair.
Try Tom Select: https://tom-select.js.org/examples/
Any initial impressions on that one?
Any initial impressions on that one?
I think the real issue here isn't if JS control can or cannot (they certainly can) but that even if they can, they still wont behave like the native controls because the native controls depend on the native platform.
E.g. imagine if someone is using a modified Gtk library that uses vi-like shortcuts/modes for multiline text areas. This wont work on custom JS controls. Or something more likely, someone using macOS which, AFAIK, has text edit controls that understand some Emacs-like shortcuts. Even if you sniff their OS from the user-agent or whatever and use macOS-like keys, the user still wont get the text functionality exposes via, e.g. the Services menu.
Of course at the end of the day you may not care about such details - or care but you consider other things more important or have other concerns/limitations for the entire underlying system.
E.g. imagine if someone is using a modified Gtk library that uses vi-like shortcuts/modes for multiline text areas. This wont work on custom JS controls. Or something more likely, someone using macOS which, AFAIK, has text edit controls that understand some Emacs-like shortcuts. Even if you sniff their OS from the user-agent or whatever and use macOS-like keys, the user still wont get the text functionality exposes via, e.g. the Services menu.
Of course at the end of the day you may not care about such details - or care but you consider other things more important or have other concerns/limitations for the entire underlying system.
This is such a fantastic library. Gave me a far better shot at making my work accessible than I'd otherwise have.
> ... defiantly possible
In a lot of cases, yes.
In a lot of cases, yes.
Double clicking selects a word, and triple-clicking selects the whole line. If I double- or triple-click-and-hold, I can drag the mouse to expand the selection word-wise or line-wise, not just character-wise. This works with the paragraphs of text in the body of this blog post, too.
I had no idea that you could end with a drag to expand your selection by word or by line like that. That's really cool. (The author's using Linux, but it works on macOS too.)
I had no idea that you could end with a drag to expand your selection by word or by line like that. That's really cool. (The author's using Linux, but it works on macOS too.)
Works on my Win10 machine too.
This thread just makes me think of the thankless job of native frontend developers working on Linux/macOS/Windows OSes that made these nuances and behaviors work exactly to a specific standard. Ok, maybe not thankless in the case of Mac and Windows since they probably got paid. :) But yeah, I imagine all the edge cases aren't easy to handle.
Lots of people have been saying this for years, and accessibility voices are now being heard as well. It's extremely difficult to create a proper form control and remember all the usage patterns and all the edge cases.
However, people want more than just the 6 or so controls defined in the 1990s. Even w3c in their design system relies on a third-party autocomplete: https://design-system.w3.org/third-party-plugins/
The reason? Browser implementors rarely solve actual issues that are truly desired by most people. Because browser implementors are low-level C/C++ developers who rarely touch actual web development. So we get 41 distance units, and horrendously bad APIs like Service Workers and Custom Elements, and piles of things like Ambient light sensors [1]. But for all the hype and advertisement around web applications we don't really get things that actually make it easy to, you know, develop these applications. Google Docs is transitioning to canvas and Figma reimplemented half of the browser in WebGL not because web platform is so great.
There's now the https://open-ui.org project that collects common UI patterns that have been endlessly re-implemented across countless frameworks and libs. It will be another 40 years before any of them become a reality.
[1] Yes, it's a thing: https://chromestatus.com/feature/5298357018820608
However, people want more than just the 6 or so controls defined in the 1990s. Even w3c in their design system relies on a third-party autocomplete: https://design-system.w3.org/third-party-plugins/
The reason? Browser implementors rarely solve actual issues that are truly desired by most people. Because browser implementors are low-level C/C++ developers who rarely touch actual web development. So we get 41 distance units, and horrendously bad APIs like Service Workers and Custom Elements, and piles of things like Ambient light sensors [1]. But for all the hype and advertisement around web applications we don't really get things that actually make it easy to, you know, develop these applications. Google Docs is transitioning to canvas and Figma reimplemented half of the browser in WebGL not because web platform is so great.
There's now the https://open-ui.org project that collects common UI patterns that have been endlessly re-implemented across countless frameworks and libs. It will be another 40 years before any of them become a reality.
[1] Yes, it's a thing: https://chromestatus.com/feature/5298357018820608
The nuances should be exposed in a stylable, implementable and a documented API, with examples and guidelines.
I don't understand why accessibility promoters endlessly bash developers, while the problem is that the edge between visual requirements and proper accessibility is extremely hard to dance, whereas it's mostly a non issue on proper platforms (eg. Cocoa/SwiftUI)
I don't understand why accessibility promoters endlessly bash developers, while the problem is that the edge between visual requirements and proper accessibility is extremely hard to dance, whereas it's mostly a non issue on proper platforms (eg. Cocoa/SwiftUI)
But… that’s when as a developer you push back. Visual requirements don’t take the place of accessible components in countries where there’s a legal requirement for accessibility, which includes most of north america.
In some cases the visual requirements are also accessibility-related.
For example, <select> will give you a drop-down that lets you type to pick, but only the first letter, and only letters that directly correspond with a keycode. So you can't type "Uni" to get "United States of America"; you can't type "とうきょう" plus enter to get "東京", and so on. If you need to support IMEs or picking through large option sets, dropdowns are a bad option.
Of course, native UI developers know that you can use a combobox instead of a dropdown picker; but there's no <combobox> tag. You have to implement your own by attaching a bunch of div/event soup to an <input type=text>[0]. In this particular case, doing so will actually make the input more accessible, because keyboard users can just type the answer instead of having to press the first letter and hit down 200 times to get to the thing they want. It's also more internationalized, because you can use your IME to compose the characters you need to search through the list with.
[0] The select2 library will do this for you and it's my go-to if I need a combobox.
For example, <select> will give you a drop-down that lets you type to pick, but only the first letter, and only letters that directly correspond with a keycode. So you can't type "Uni" to get "United States of America"; you can't type "とうきょう" plus enter to get "東京", and so on. If you need to support IMEs or picking through large option sets, dropdowns are a bad option.
Of course, native UI developers know that you can use a combobox instead of a dropdown picker; but there's no <combobox> tag. You have to implement your own by attaching a bunch of div/event soup to an <input type=text>[0]. In this particular case, doing so will actually make the input more accessible, because keyboard users can just type the answer instead of having to press the first letter and hit down 200 times to get to the thing they want. It's also more internationalized, because you can use your IME to compose the characters you need to search through the list with.
[0] The select2 library will do this for you and it's my go-to if I need a combobox.
Oh, 100%, if your designer is extending components with a mind for greater usability and accessibility then that’s perfect. There’s a reason ARIA exists after all.
> there’s a legal requirement for accessibility
In the US I'm fairly sure there's only a requirement for accessibility if you're building something for the government. I'm certainly allowed to build a website that isn't accessible and not have it taken down.
Edit: Guess there's precedent to require some businesses to do it as well. Looks like I'm mostly wrong here.
In the US I'm fairly sure there's only a requirement for accessibility if you're building something for the government. I'm certainly allowed to build a website that isn't accessible and not have it taken down.
Edit: Guess there's precedent to require some businesses to do it as well. Looks like I'm mostly wrong here.
You’re required under the ADA to make “reasonable accommodations” for people with disabilities. This has been tested numerous times in court, most recently against Dominos: https://blog.ericgoldman.org/archives/2021/06/domino-pizzas-...
Judges have found that retail websites are subject to the ADA[1], and sites for things like utilities definitely are. Your personal website does not need to comply though, since it’s not considered a public space.
[1]: https://myblindspot.org/2017/09/retail-websites-are-public-a...
[1]: https://myblindspot.org/2017/09/retail-websites-are-public-a...
I was wondering about this, too.
> Making a custom form control with JavaScript is going to make life worse for a lot of people. Just don’t do it. The browser’s built-in controls are quite sufficient.
For my self-hosted minimal CRM (not really ready for anybody except me yet) [Aktenkoffer](https://github.com/svkurowski/aktenkoffer), I created a custom select that allows for filtering/searching of contacts when choosing sender/recipient for a given document. I don't use browser's select because:
1. There's a lot of contacts one has, and the list will become very long, a usecase for which select seems not to be the best fit, i.e. I don't want to load all the options always. 2. I cannot always remember how I formatted a contact name - e.g did I include the "Dr." at the beginning or not. Select quick-selection only works when I know exactly the sequence of characters I'm looking for (like the US state selection the author mentioned).
Obviously it has tons of feature gaps, I.e. pressing Esc does not close it (yet), up-and-down arrows don't work (yet), one cannot just type to go to one option.
Any suggestions, what to do in such a case? And how I can learn more about such approaches?
I love sourcehut, and its design and I would like to follow a closer to the browser, minimal UI but in practice it seems quite hard for me - harder than getting a custom select "half-right".
> Making a custom form control with JavaScript is going to make life worse for a lot of people. Just don’t do it. The browser’s built-in controls are quite sufficient.
For my self-hosted minimal CRM (not really ready for anybody except me yet) [Aktenkoffer](https://github.com/svkurowski/aktenkoffer), I created a custom select that allows for filtering/searching of contacts when choosing sender/recipient for a given document. I don't use browser's select because:
1. There's a lot of contacts one has, and the list will become very long, a usecase for which select seems not to be the best fit, i.e. I don't want to load all the options always. 2. I cannot always remember how I formatted a contact name - e.g did I include the "Dr." at the beginning or not. Select quick-selection only works when I know exactly the sequence of characters I'm looking for (like the US state selection the author mentioned).
Obviously it has tons of feature gaps, I.e. pressing Esc does not close it (yet), up-and-down arrows don't work (yet), one cannot just type to go to one option.
Any suggestions, what to do in such a case? And how I can learn more about such approaches?
I love sourcehut, and its design and I would like to follow a closer to the browser, minimal UI but in practice it seems quite hard for me - harder than getting a custom select "half-right".
Recent discovery: there's a native <datalist> element, well supported except for Firefox@Android. It's a combo of <select> and filtering (a combo box, to use the Windows parlance).
https://developer.mozilla.org/fr/docs/Web/HTML/Element/datal...
https://developer.mozilla.org/fr/docs/Web/HTML/Element/datal...
The big downside is that datalist will only show exact matches of what you've put in. If you're doing a fuzzy search somewhere (or the user has a typo) and want to offer search suggestions, a native datalist doesn't work. I wish there was an attribute that forced all options to appear when filtering happens elsewhere and options are dynamic.
There's not a great built-in combobox control, which is a shame. An input type=list element with a datalist comes close: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/da...
Emphatic agreement.
Today, even apparently trivial widgets require ridiculous amounts of effort to attain a "natural" UX. To become so good you don't notice. That holy grail of being "invisible".
--
Epochs ago, I created custom controls for Win32. The one I was most proud of was a direct manipulation sundial picker for a raytracer. I obsessed over the details. Like being pixel perfect, both mouse and arrow keys (for fine grained increments), live updates between dial widget and text fields. Damn, I was proud of that control. I flushed and preened whenever a user complimented the effort.
Ages ago, I started using bootstrap-select. It's a nifty dropdown w/ type ahead (search). Modest, no big deal, right? Nope! That project received so many PRs, tweaks, fit & finish, finesse, and all around TLC. I was transfixed, fascinated. I haven't done UI for years, but remained subscribed to their project announcements, mostly out of awe and respect.
https://github.com/snapappointments/bootstrap-select
Observing the bootstrap-select project over time humbled me. I used to think I had some UX juice. Now I know that I'm just banging the rocks together.
Today, even apparently trivial widgets require ridiculous amounts of effort to attain a "natural" UX. To become so good you don't notice. That holy grail of being "invisible".
--
Epochs ago, I created custom controls for Win32. The one I was most proud of was a direct manipulation sundial picker for a raytracer. I obsessed over the details. Like being pixel perfect, both mouse and arrow keys (for fine grained increments), live updates between dial widget and text fields. Damn, I was proud of that control. I flushed and preened whenever a user complimented the effort.
Ages ago, I started using bootstrap-select. It's a nifty dropdown w/ type ahead (search). Modest, no big deal, right? Nope! That project received so many PRs, tweaks, fit & finish, finesse, and all around TLC. I was transfixed, fascinated. I haven't done UI for years, but remained subscribed to their project announcements, mostly out of awe and respect.
https://github.com/snapappointments/bootstrap-select
Observing the bootstrap-select project over time humbled me. I used to think I had some UX juice. Now I know that I'm just banging the rocks together.
I prefer to use built-in controls as much as possible, but they have their flaws and missing features. One of my pet peeves / gripes is the half or broken implementation of new HTML5 input fields, like number or calendar inputs. I haven't found working them at all delightful.
> The browser’s built-in controls are quite sufficient.
Until you work on global webshop forms, where business/management wants hundreds of exceptions to the rules. Few examples: form input pre-fills, custom validation, auto-complete fields, fancy dropdowns, email/postcode checks that need to happen while filling in the form. I could go on. And it all should be manageable from some ancient CMS, of course.
Until you work on global webshop forms, where business/management wants hundreds of exceptions to the rules. Few examples: form input pre-fills, custom validation, auto-complete fields, fancy dropdowns, email/postcode checks that need to happen while filling in the form. I could go on. And it all should be manageable from some ancient CMS, of course.
Yes. Very much this.
Another example: default macOS dropdowns allow you to click and drag while holding the button to select something in one single gesture. Default <select> implementation in Chrome/Vivaldi also supports it. None of the custom JS ones support it.
The menu that opens from a <select> extends outside of the browser viewport which makes it easier to choose from long lists.
Anything that opens a custom popup menu, including a dropdown, can only close it when you click within the browser viewport, for obvious reasons. System popup menus (NSMenu I think?) are kinda system-modal in that you can close them by clicking anywhere on screen, which is more convenient.
Another example: default macOS dropdowns allow you to click and drag while holding the button to select something in one single gesture. Default <select> implementation in Chrome/Vivaldi also supports it. None of the custom JS ones support it.
The menu that opens from a <select> extends outside of the browser viewport which makes it easier to choose from long lists.
Anything that opens a custom popup menu, including a dropdown, can only close it when you click within the browser viewport, for obvious reasons. System popup menus (NSMenu I think?) are kinda system-modal in that you can close them by clicking anywhere on screen, which is more convenient.
[deleted]
Your last point is not true. You can set custom dropdowns to close on loss of focus, which will happen when clicking outside of the browser window. It makes debugging with the browaer tools a right pain in the neck, but it's totally possible.
Yes but then that click would still go through to wherever you clicked and activate some other window. System menus consume that click.
Not on Windows, with the exception of the Ribbon control in the File Explorer and Microsoft Office.
This is true, but the set of custom controls is quite small. Controls that were built-in to, say, Visual Basic 4.0 in 1995 are not present in today's web browsers.
Re-implementing built-in controls (the example of a <select> box is given in the OP) is obviously a very bad idea in almost all circumstances. Implementing a missing control is a much more difficult decision, and there are times when it can be a defensible choice to do so.
Re-implementing built-in controls (the example of a <select> box is given in the OP) is obviously a very bad idea in almost all circumstances. Implementing a missing control is a much more difficult decision, and there are times when it can be a defensible choice to do so.
This is not helpful imo. Although it correctly identifies a problem of badly implemented controls. The explanation and solution show a lack of knowledge and understanding about the topic and current situation.
It's easy to say "use just the browser provided controls" until you actually have to build something that people need to use. What is expected today from even a simple form involves a lot of custom behavior that browsers do not provide, at what point is it "custom"? Advising against that will not help things become more usable nor accessible.
Instead of "just don't do it", I suggest to promote caring about usability and accessibility, and make people realize it should be evaluated for each individual situation and give practical information on how to do that.
Very basic practical advice; Use native elements where possible, if you run into their limitations preferably use an existing well build and maintained alternative that does implement all of the intricate details. Building something completely custom should be a last resort, if you do end up in that situation it's often beneficial to build it on top of something else.
It's easy to say "use just the browser provided controls" until you actually have to build something that people need to use. What is expected today from even a simple form involves a lot of custom behavior that browsers do not provide, at what point is it "custom"? Advising against that will not help things become more usable nor accessible.
Instead of "just don't do it", I suggest to promote caring about usability and accessibility, and make people realize it should be evaluated for each individual situation and give practical information on how to do that.
Very basic practical advice; Use native elements where possible, if you run into their limitations preferably use an existing well build and maintained alternative that does implement all of the intricate details. Building something completely custom should be a last resort, if you do end up in that situation it's often beneficial to build it on top of something else.
Agreed. I think about custom controls like I think about cryptography libraries: most hackers aren't specialized enough to have thought through all the corner cases and unless you want that to be your specialty, you're taking on a lot of risk of blowing your own leg off (metaphorically speaking) trying to hack out a solution instead of using something (ideally) well-maintained and with some history behind it.
(Having had some experience working on custom controls in a browser: it's the kind of project that will occupy a three-person team at a Fortune-500 full-time over multiple quarters to get right. Set your expectations accordingly.)
(Having had some experience working on custom controls in a browser: it's the kind of project that will occupy a three-person team at a Fortune-500 full-time over multiple quarters to get right. Set your expectations accordingly.)
I’ve used browser controls for the last 20 years on any form I’ve ever implemented. These days you get validation errors, accessibility, and so much more for free — even if JavaScript is turned off. I can’t think of a reason you’d ever want to use a custom control on a form.
How about a date range, search fields with dynamic autocomplete, rich content dropdown selects, combined multi selects, etc etc?
As I said in my original comment; I agree that where possible normal input elements are preferred, but they do not cover all cases. I guess it depends on what you consider custom, most of those use html form elements underneath, but they definitely require implementing the intricate details as described in the article.
I also don't think it's correct to say accessibility and usability come for free as long as you use plain html elements. You can build really horrible unusable forms with plain html elements, I've seen plenty (and I've probably build a few myself in the past haha).
My point is; "don't use X" and "don't do Y" posts are not helpful as they do not convey the point that both usability and accessibility require effort and consideration, and give a false sense of "if you don't do this all will be great" which is not the case.
As I said in my original comment; I agree that where possible normal input elements are preferred, but they do not cover all cases. I guess it depends on what you consider custom, most of those use html form elements underneath, but they definitely require implementing the intricate details as described in the article.
I also don't think it's correct to say accessibility and usability come for free as long as you use plain html elements. You can build really horrible unusable forms with plain html elements, I've seen plenty (and I've probably build a few myself in the past haha).
My point is; "don't use X" and "don't do Y" posts are not helpful as they do not convey the point that both usability and accessibility require effort and consideration, and give a false sense of "if you don't do this all will be great" which is not the case.
> How about a date range
Two separate date fields?
> search fields with dynamic autocomplete
a select control with some js to inject the option tags?
> rich content dropdown selects
I don't even know what this means. Are you just writing code for visual users?
> combined multi selects
I've never run into an average user who knows how to use multi-selects or how to use the shift/ctrl key to do it. I think checkboxes/radio buttons is probably a better and more useable control.
Two separate date fields?
> search fields with dynamic autocomplete
a select control with some js to inject the option tags?
> rich content dropdown selects
I don't even know what this means. Are you just writing code for visual users?
> combined multi selects
I've never run into an average user who knows how to use multi-selects or how to use the shift/ctrl key to do it. I think checkboxes/radio buttons is probably a better and more useable control.
These are all pretty poor solutions to the problem. I also prefer native controls but when they don't fit your use case I think it is better to make your own than use non-fitting input types.
I do agree that most users don't know how to use multi-selects though. For that a list with checkboxes works well and allows rich content.
I do agree that most users don't know how to use multi-selects though. For that a list with checkboxes works well and allows rich content.
By far the most annoying thing to me (as a user who does not rely on accessibility features) is how few JS-built forms support TABing through the fields, in the correct order. It's infuriating.
I think a real problem here is that people (especially English only) do not understand the actual complexity of most standard input controls. They really think it’s just “type letters”. The number of times I’ve seen people showing their “fully functional” editors that flat out do not work with IM[E]s, do not handle basic keyboard controls, do not handle pasting or search propErly never ceases to amaze me.
That’s before consider breaking all the password or address auto fills, screen readers, non-keyboard text entry.
Even if all you’re doing is “restyling” controls, how do you interact with people who have vision difficulties like colour blindness? You’re restyling overrides accessibility features that make controls visible.
Seriously, you don’t get to say “web apps should be just as capable as normal apps”, and also say “I should break basic app functionality”
That’s before consider breaking all the password or address auto fills, screen readers, non-keyboard text entry.
Even if all you’re doing is “restyling” controls, how do you interact with people who have vision difficulties like colour blindness? You’re restyling overrides accessibility features that make controls visible.
Seriously, you don’t get to say “web apps should be just as capable as normal apps”, and also say “I should break basic app functionality”
Number inputs have given me the most pain. The trick is that you need to manage two states: the current string state of the input and the most recent valid number state or null or NaN or whatever you want.
The issue being that there’s many valid numbers that aren’t always parsable numbers as a human types them in (because of decimal or negative, etc.)
The issue being that there’s many valid numbers that aren’t always parsable numbers as a human types them in (because of decimal or negative, etc.)
[deleted]
Same with links, for example when someone makes a JavaScript link and breaks the middle click to open in new tab
many +1 and add target=_blank to the list.
In Firefox there is an option to override this in about:config so that all links open in the same tab.
However the downsides including breaking some OAuth authentication flows and sometimes you can't open fake links in new tabs when you want to.
However for me the consistency is still worth the minor breakagaes.
However the downsides including breaking some OAuth authentication flows and sometimes you can't open fake links in new tabs when you want to.
However for me the consistency is still worth the minor breakagaes.
Yes, definitely
The sooner we stop attempting to fool each other that DOM + CSS is a suitable model for composing user interfaces which were previously implemented as native apps, the sooner we will get past the web era and on to something better.
(25 years later... still trying.)
(25 years later... still trying.)
The main issue here is that the listbox on a select control is not part of the DOM+CSS model. If it was then there wouldn't be as big a problem, as they could be styled and customized while still taking advantage of native functionality.
LOL
As I type into a regular textarea on this site I'm wondering where these textarea replacements on websites are? I'd love for a few examples of this happening. "Many" JS programmers recreate the textarea? Show me.
It depends exactly what you mean by textarea. If you need rich text you need something custom. (Although you can use contenteditable as a base)
There are sites like GitHub that slightly enhance a regular textarea (IIRC it is a textarea, haven't thought about it too much)
There are sites like GitHub that slightly enhance a regular textarea (IIRC it is a textarea, haven't thought about it too much)
Facebook, Twitter, Gmail, Discord
This is an interesting comment but also an edge case. I build custom components all the time, such as a combo box that allows a user to select a list of options but also allows the user to type in a fragment and the options will be displayed filtered based on the text fragment typed. I would imagine your use case is a nightmare, but the average dev team and product manager is probably myopic and anglo-centric so they are more worried about the average latin language based user as opposed to your use case.
I'm glad you are sharing this, its good to be aware of and I might share this with my own product team in the future.
I'm glad you are sharing this, its good to be aware of and I might share this with my own product team in the future.
> Making a custom form control with JavaScript is going to make life worse for a lot of people. Just don’t do it. The browser’s built-in controls are quite sufficient.
An extremely common use case at the last two companies I've worked at is a multi-select dropdown with autosuggest. Optionally, new items can be added to the list. Sometimes we needed to use ajax to populate the list, because you were searching 25,000+ items. We used this control in 10-15 different places, usually inside a spreadsheet cell. Which built-in controls should I use for this? I agree with the author that it is difficult to implement.
An extremely common use case at the last two companies I've worked at is a multi-select dropdown with autosuggest. Optionally, new items can be added to the list. Sometimes we needed to use ajax to populate the list, because you were searching 25,000+ items. We used this control in 10-15 different places, usually inside a spreadsheet cell. Which built-in controls should I use for this? I agree with the author that it is difficult to implement.
[deleted]
> You cannot capture all of this nuance in a home-grown form control, or even anything close to it, but many JavaScript programmers do it anyway.
In practical terms for most developers, this holds true. Theoretically, you could replicate nearly the entire experience if you were patient and determined enough. Depending on the kind of product you are going for, it could make sense to invest in this capability.
Even accessibility can be addressed by doing things like dynamically inserting DOM nodes that screen readers can see. This is something I have played around with in my canvas/mjpeg/x264 rendering systems.
In practical terms for most developers, this holds true. Theoretically, you could replicate nearly the entire experience if you were patient and determined enough. Depending on the kind of product you are going for, it could make sense to invest in this capability.
Even accessibility can be addressed by doing things like dynamically inserting DOM nodes that screen readers can see. This is something I have played around with in my canvas/mjpeg/x264 rendering systems.
> Theoretically, you could replicate nearly the entire experience if you were patient and determined enough.
Practically, impossible, because browsers do not expose information about keyboard shortcuts respectively the associated semantic actions to the JS runtime environment, so a programmer looking to replicate has to make assumptions and hardcode keys.
Practically, impossible, because browsers do not expose information about keyboard shortcuts respectively the associated semantic actions to the JS runtime environment, so a programmer looking to replicate has to make assumptions and hardcode keys.
Digikey changed their website last year and the specific nuance the article mentioned is not being implemented. Made my life a bit more miserable when purchasing electronics components.
google docs reimplemented their whole UX in canvas, and this is a giant company that controls browser standards as much as anyone does. can't think of a louder way to admit defeat re advanced text entry on the web
I wonder about unbundling the different pieces of the browser. Sandboxing + safe-ish remotely-managed code is really cool. Zero-install apps is cool-ish, but comes with slow loading (try opening a new tab in gmail on my poor linux firefox).
But for UX things are tricky. The DOM is somehow simultaneously the best widgets library and a horrible widgets library. CSS isn't quite powerful enough, hence all the scroll jank tricks many sites are still doing, hence the difficulty of mixing classes and getting sane results.
I'd want a browser-like execution context, but with something more like JSX than the DOM, pluggable layout engines with the default one more like modern constraints languages than CSS, SPA-aware RPC primitives, and more attention paid to the customizability of text entry and scroll.
Electron IDEs are simultaneously great (so powerful and customizable) and really bad (built on the worst text entry tech you could pick).
the author is 99% right about the difficult of interacting with custom controls, possible exception of companies like shopify and stripe that have put massive investment into getting this stuff to work cross-platform.
I wonder about unbundling the different pieces of the browser. Sandboxing + safe-ish remotely-managed code is really cool. Zero-install apps is cool-ish, but comes with slow loading (try opening a new tab in gmail on my poor linux firefox).
But for UX things are tricky. The DOM is somehow simultaneously the best widgets library and a horrible widgets library. CSS isn't quite powerful enough, hence all the scroll jank tricks many sites are still doing, hence the difficulty of mixing classes and getting sane results.
I'd want a browser-like execution context, but with something more like JSX than the DOM, pluggable layout engines with the default one more like modern constraints languages than CSS, SPA-aware RPC primitives, and more attention paid to the customizability of text entry and scroll.
Electron IDEs are simultaneously great (so powerful and customizable) and really bad (built on the worst text entry tech you could pick).
the author is 99% right about the difficult of interacting with custom controls, possible exception of companies like shopify and stripe that have put massive investment into getting this stuff to work cross-platform.
To be fair Google Docs is a bit different here. To a large extent their goal is to display what is going to be printed (this is changing a bit with the new pageless mode and things like checkboxes but still is the core). So doing all of the rendering themselves actually makes sense.
That being said I would love to see a rich-text input with some default controls available.
That being said I would love to see a rich-text input with some default controls available.
The best unit of isolation for web functionality is behaviors, not controls. Think of them as traits enabled and configured via attributes. I've used such things on many different projects with very good results. The main advantage is that if you design them properly it is trivial to extend built-in functionality without reinventing the flat tire.
Interesting, care to expand on behaviors vs controls?
Selects are the absolute worst when it comes to customization. I totally understand it from a design perspective, but I will always push back on it aside from customizing the box itself. The actual dropdown options? Sorry, they're going to look how they look.
Me wishing every UI/UX person understood this.
In fact, the more bells and whistles I find on the requirements for individual form inputs, the more annoying it is the work on.
Simplicity is god for most of front-end.
In fact, the more bells and whistles I find on the requirements for individual form inputs, the more annoying it is the work on.
Simplicity is god for most of front-end.
> The browser’s built-in controls are quite sufficient.
What do you recommend for a typeahead/autocomplete? In my case I’m using a third party API for results (geocoding), but even with a static list, the closest option is datalist, which is very limited
What do you recommend for a typeahead/autocomplete? In my case I’m using a third party API for results (geocoding), but even with a static list, the closest option is datalist, which is very limited
Calendar date selectors and phone number fields that try to automagically format my phone number into some predefined format (usually (xxx)-xxx-xxxx) and insert characters are the bane of my existence.
It is why I hate Electron apps which disguise themselves as native ones.
I wish more development went into form widgets. A big thing is also that they're accessible and responsive by default.
One that I would love would be some sort of drag and drop reorderable list, for example.
One that I would love would be some sort of drag and drop reorderable list, for example.
Can't or don't?
Besides, I usually build controls out of input primitives, not pure JS.
Besides, I usually build controls out of input primitives, not pure JS.
"no, but we want our customers to have an immersive brand experience"
- egos
- egos
"The most efficient system is no system" -Elon Musk
There are too many needlessly reimplemented components, but anyone that has ever needed to style a <select> to make it look in line with any modern design quickly reached desperation.
I'd love to be able to use standard components everywhere, but most of my users care if my website looks like it's from 2004.