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...
Custom JavaScript controls can't capture the nuance of form fields (2021)
91–100 of 227 posts
Re: Custom JavaScript controls can't capture the nuance of form fields (2021)
#92Earlier quoted context omitted.
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…
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.
Re: Custom JavaScript controls can't capture the nuance of form fields (2021)
#93I'd actually put the blame here on browsers, and how limited the default inputs are. There are too many needlessly reimplemented components, but anyone that has ever needed to style a 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.
> but anyone that has ever needed to style a 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).
Re: Custom JavaScript controls can't capture the nuance of form fields (2021)
#94Earlier quoted context omitted.
> 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 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 -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.
Re: Custom JavaScript controls can't capture the nuance of form fields (2021)
#95Earlier quoted context omitted.
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 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.
I would probably use a series of checkboxes for the same effect.
Re: Custom JavaScript controls can't capture the nuance of form fields (2021)
#96Earlier quoted context omitted.
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 pic…
> 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 horrendo…
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.
Re: Custom JavaScript controls can't capture the nuance of form fields (2021)
#97It'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-spect…
> 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 i…
> In Firefox, if I use tab I can select my native 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 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"?
Re: Custom JavaScript controls can't capture the nuance of form fields (2021)
#98This 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 tha…
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.
Re: Custom JavaScript controls can't capture the nuance of form fields (2021)
#99It'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.
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 t…
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.
Re: Custom JavaScript controls can't capture the nuance of form fields (2021)
#100I'd actually put the blame here on browsers, and how limited the default inputs are. There are too many needlessly reimplemented components, but anyone that has ever needed to style a 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.
> but anyone that has ever needed to style a 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).
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.