6 ms·

You should fix this attitude, becuase it's making your applications worse. The browser is the best at doing the things it does, and any control that you impleme

You should fix this attitude, becuase it's making your applications worse. The browser is the best at doing the things it does, and any control that you implement yourself is going to be worse. If the browser can do something for you, you ought to let it do that for you. If you insist on writing your own controls, its behavior will differ from how the browser's own UI works in subtle ways, repeated indefinitely for each combination of OS and browser and user input paradigm. People who rely on muscle memory to use these features, people who perhaps cannot percieve whatever UI hints you come up with to teach your custom control, or people whose needs you have forgotten about, will all struggle to use your UI. And for what? It looks prettier? No thanks.

corytheboyd 6y ago
I didn’t downvote because I can agree to a certain extent. Are you suggesting a completely unstyled web or something? Maybe if you fleshed out that idea you would be met with less criticism. There is a good lesson here though, native browser controls should ALWAYS be your first consideration when building UI for the web. Try everything under the sun to stick as close to these as possible before you give up. You will thank yourself for having less code in which something can break. Your users will thank you for already knowing how to use the controls. An example that drives me crazy is when dropdowns that could have been a select/option group of controls are not. Because most of the time the subtle but insanely helpful keyboard controls are completely missing. Being able to type with the menu selected to jump to items is insanely helpful when the creator insists on jamming too many options into it. Think about that, it’s not exactly trivial to implement, and by the time you have the dozens of lines of JavaScript to implement it correctly... pretty hard not to ask yourself “what the hell am I doing...”
- fiddlerwoaroof 6y ago
  Dropdowns are frustrating because the select/option is only really good for simple cases and browsers block restyling: as soon as you get a requirement like “Dropdown with multiselect”, you have to rewrite the whole thing: and, for visual consistency, this usually means rewriting all the dropdowns.
  - ddevault 6y ago
    "Dropdown with multiselect" is addressed by adding the "multiple" attribute to your select tag. Which has been possible since the 90's.
    - fiddlerwoaroof 6y ago
      Nope, per MDN: > When multiple is specified, most browsers will show a scrolling list box instead of a single line dropdown. This is not “dropdown with multiselect” because it doesn’t “drop down”
      - ddevault 6y ago
        Tough shit? It does what you want. It doesn't have to look like what you want.
        fiddlerwoaroof 6y ago
        It doesn’t do “what I want”, it’s completely unsuitable for most of the use cases I’ve run into. Additionally, this sort of response will never work with a product manager or ux designer.
        ddevault 6y ago
        It's your job as the engineer to tell the product manager or UX designer "no" when they ask you to build interfaces which lock disabled users out of the product. Take some responsibility for the code you write. And if you really cannot use <select multiple>, then have the discipline to read the AIRA guidelines and make sure that whatever you come up with works for everyone.
        fiddlerwoaroof 6y ago
        Not really, the point of having these people is for them to make product and ux decisions. It’s my job to implement the use case they come up with (or quit): I can provide technical advice and suggest easier/better ways to solve their problems but, ultimately, it’s their call.
chrismorgan 6y ago
To those disagreeing with Drew here: he’s expressing it very bluntly, but what he’s saying is absolutely correct. People keep on reimplementing what browsers already provide, and they seldom do a good job of it. In fact, often it’s impossible to do a flawless job of it—e.g. you can’t get a custom dropdown to behave (not look, behave) like a native <select> without some fairly detailed user-agent and platform matching (I mean things like whether selection is focus or not, and what Tab does when the dropdown is open and selection is not focus), quite apart from the other details that people often skip over (see https://www.w3.org/TR/wai-aria-practices/#Listbox https://www.w3.org/TR/wai-aria-practices/#Listbox for a summary); and scrolljacking is always bad because the primitives exposed are insufficient to reimplement scrollable areas. This is an attitude problem with a large fraction of web developers that causes trouble for users. You should very strongly prefer to use a native element and technique for something if you can. And buttons… well, buttons are a great example of something fundamental that the browser has a good implementation of, which is often reimplemented annoyingly incorrectly.
- fiddlerwoaroof 6y ago
  I don't disagree with this, the main issue I have is that the browser controls are stuck in the 90s/00s: browsers should implement new controls so we have less need for custom work here.
bavell 6y ago
> "fix this attitude" I agree with you, hence my first sentence, "guilty of this more often than I should be". I'm much better about using semantic and accessible markup nowadays but I wanted to give some perspective to others who may not be webdevs and are wondering how and why those damn monkeys can screw things up so badly ;)
yyyk 6y ago
>The browser is the best at doing the things it does, and any control that you implement yourself is going to be worse. There are plenty of counterexamples. For example, the date input control does not allow to enforce date format by design, and the auto-detection of user facing format is buggy and inconsistent across browsers on the same system (e.g. Edge legacy ignored Windows' region preference and used the keyboard locale). It tends to show the American-style dates even on non-American locales, making the control not just useless but sometimes actively misleading. Even apart from that it's pretty basic. Keyboard navigation is bad everywhere bad but in Chrome where it's just mediocre - there's no inline/auto-popup mode like other js pickers, and it requires nonintuitively pressing ENTER to pop-up. Some browsers like Firefox don't have a 'Today' button, and even in Chrome you can't hide it when it doesn't make sense. No browser has a 'Clear' button which makes sense in some scenarios. I can go on and on about how flawed that control is, but this is long enough.

corytheboyd 6y ago

I didn’t downvote because I can agree to a certain extent. Are you suggesting a completely unstyled web or something? Maybe if you fleshed out that idea you would be met with less criticism. There is a good lesson here though, native browser controls should ALWAYS be your first consideration when building UI for the web. Try everything under the sun to stick as close to these as possible before you give up. You will thank yourself for having less code in which something can break. Your users will thank you for already knowing how to use the controls. An example that drives me crazy is when dropdowns that could have been a select/option group of controls are not. Because most of the time the subtle but insanely helpful keyboard controls are completely missing. Being able to type with the menu selected to jump to items is insanely helpful when the creator insists on jamming too many options into it. Think about that, it’s not exactly trivial to implement, and by the time you have the dozens of lines of JavaScript to implement it correctly... pretty hard not to ask yourself “what the hell am I doing...”

fiddlerwoaroof 6y ago
Dropdowns are frustrating because the select/option is only really good for simple cases and browsers block restyling: as soon as you get a requirement like “Dropdown with multiselect”, you have to rewrite the whole thing: and, for visual consistency, this usually means rewriting all the dropdowns.
- ddevault 6y ago
  "Dropdown with multiselect" is addressed by adding the "multiple" attribute to your select tag. Which has been possible since the 90's.
  - fiddlerwoaroof 6y ago
    Nope, per MDN: > When multiple is specified, most browsers will show a scrolling list box instead of a single line dropdown. This is not “dropdown with multiselect” because it doesn’t “drop down”
    - ddevault 6y ago
      Tough shit? It does what you want. It doesn't have to look like what you want.
      - fiddlerwoaroof 6y ago
        It doesn’t do “what I want”, it’s completely unsuitable for most of the use cases I’ve run into. Additionally, this sort of response will never work with a product manager or ux designer.
        ddevault 6y ago
        It's your job as the engineer to tell the product manager or UX designer "no" when they ask you to build interfaces which lock disabled users out of the product. Take some responsibility for the code you write. And if you really cannot use <select multiple>, then have the discipline to read the AIRA guidelines and make sure that whatever you come up with works for everyone.
        fiddlerwoaroof 6y ago
        Not really, the point of having these people is for them to make product and ux decisions. It’s my job to implement the use case they come up with (or quit): I can provide technical advice and suggest easier/better ways to solve their problems but, ultimately, it’s their call.

chrismorgan 6y ago

To those disagreeing with Drew here: he’s expressing it very bluntly, but what he’s saying is absolutely correct. People keep on reimplementing what browsers already provide, and they seldom do a good job of it. In fact, often it’s impossible to do a flawless job of it—e.g. you can’t get a custom dropdown to behave (not look, behave) like a native <select> without some fairly detailed user-agent and platform matching (I mean things like whether selection is focus or not, and what Tab does when the dropdown is open and selection is not focus), quite apart from the other details that people often skip over (see https://www.w3.org/TR/wai-aria-practices/#Listbox https://www.w3.org/TR/wai-aria-practices/#Listbox for a summary); and scrolljacking is always bad because the primitives exposed are insufficient to reimplement scrollable areas. This is an attitude problem with a large fraction of web developers that causes trouble for users. You should very strongly prefer to use a native element and technique for something if you can. And buttons… well, buttons are a great example of something fundamental that the browser has a good implementation of, which is often reimplemented annoyingly incorrectly.

fiddlerwoaroof 6y ago
I don't disagree with this, the main issue I have is that the browser controls are stuck in the 90s/00s: browsers should implement new controls so we have less need for custom work here.

bavell 6y ago

> "fix this attitude" I agree with you, hence my first sentence, "guilty of this more often than I should be". I'm much better about using semantic and accessible markup nowadays but I wanted to give some perspective to others who may not be webdevs and are wondering how and why those damn monkeys can screw things up so badly ;)

yyyk 6y ago

>The browser is the best at doing the things it does, and any control that you implement yourself is going to be worse. There are plenty of counterexamples. For example, the date input control does not allow to enforce date format by design, and the auto-detection of user facing format is buggy and inconsistent across browsers on the same system (e.g. Edge legacy ignored Windows' region preference and used the keyboard locale). It tends to show the American-style dates even on non-American locales, making the control not just useless but sometimes actively misleading. Even apart from that it's pretty basic. Keyboard navigation is bad everywhere bad but in Chrome where it's just mediocre - there's no inline/auto-popup mode like other js pickers, and it requires nonintuitively pressing ENTER to pop-up. Some browsers like Firefox don't have a 'Today' button, and even in Chrome you can't hide it when it doesn't make sense. No browser has a 'Clear' button which makes sense in some scenarios. I can go on and on about how flawed that control is, but this is long enough.