Look at <select multiple> for example—the browser built-in is borderline unusable. Anything that requires combining a click with the shift and ctrl/cmd keys is not going to go down well with the average user. Same goes for <select>s that need more advanced behaviour like filtering. There's <datalist>, but it's incredibly basic and pretty useless for most cases you'd want that sort of input.
The web is an app platform whether we like it or not, and I'd like to see a robust set of browser-native controls with mechanisms to customise styling and behaviour. It would improve accessibility, improve performance, reduce page sizes (because we wouldn't be re-implementing the whole world in JS), and it would at least go a little way to offsetting the slow erosion of quality desktop software that web technologies are bringing.
Now, if you wanted to say that HTML's standard widgets should be allowed to reflect the platform-native look-and-feel (for example, adding a "selected" checkbox on touch-screens, or supporting long-press to select items, or whatever) instead of being tied to Windows 95 appearance and behaviour by backwards-compatibility concerns, then yeah, I'd agree with that.
Even in the early desktop era when it was popular, many non-enthusiasts probably just didn't know how to use a UI control like that. It just didn't cause a problem because most people didn't use computers much.
I would bet that most internet users today have never even used a UI where that control is popular.
Never done tech support I take it!
It makes me think when I'm designing things. If I have problems with stuff like that, how can I make it better.
Then there's the way styles are so different, especially on the web. Horribly user-hostile. How does this site mark something as important, assuming it bothers in the first place? Who knows. And if I'm only planning to be on it for 30s, I'm not going to learn that.
It's a standard UI control and it is used pretty often.
Or you could just use a better control.
Many users don’t even know you can use a key shortcut to copy/paste.
"‡ On a phone or tablet or whatever, ignore us, we're just confusing you."
And it's also completely not discoverable. I only know how it works when I read from HTML book back in the day.
Just because it was the standard doesn't mean it's easily learned.
If you absolutely have to put words in my mouth, please make them at least a little less stupid ones. Maistuivat vähän paskalta.
This is part of the problem. Your average user at temporal point X has difficulty combining mouse clicks with keyboard modifiers. You build interface around that notion and in a later temporal point Y your average user cannot combine those at all and you have lost input mode. Your average user has problem distinguishing single click from double click. You install debounce logic, train them there is no difference between the two and lose input mode.
The web is a shitty platform for apps, because currently it is supposed to be used from at least proper PC, touchable handheld device, embedded in controlling container and in relatively near future virtual environments. Game developers have tried for literally decades to bridge the gap between PCs and consoles and mostly failed at that with both platforms being relatively static. The web being a moving target is much more difficult to fit on different device classes. Yet we try to do that and as a result are moving to the lowest common denominator.
For grand strategy / RTS, yeah, that's kind of a function of the complexity. Most other game genres are fairly well defined in the expected control schemes on both platforms now though.
This is how computers have worked since pretty much day 1, not just the web. I remember getting computing classes in school, but it seems the current generation is completely ignoring all of that and instead just plays on their phone.
More built-in widgets would be great though.
I like to imagine that if browser makers had collaborated better on standardising CSS hooks into the default widgets, we would not have seen such strong adoption of tools like bootstrap. We possibly would have had a different pathway through template+controller libraries too.
As a FED, I didn’t help. I rode the gravy train along with Backbone, Angular and React. I wish I had fought harder and spoken more eloquently on the practicality of a11y-first semantic mark-up and progressive enhancement. I caved in to the demands of the agencies who took me on to get stuff done in the trendy stacks.
Is there a reason the element has to be implemented that way? Correct me if I'm wrong, but aren't the details of how it works up to the browser? It only works that way because every OSs native select widget worked that way and once upon a time browsers actually tried to integrate well with the OS and used native widgets.
These users need to retake the computer literate 101 class.
When I'm in elementary school, we learned how to multi-select in the tutorial system that comes with Windows 3.1.
I don't know why Windows XP deleted these very important tutorials and replaced them with a webpage.
It’s been open-sourced and forked here if people would like to help keep it alive:
I do freakishly experimental webdesign at times (like for designer portfolios, where freakishly experimental webdesign is kinda part of the thing), but for everything where it is much more about the info and the content I will bend over backwards to use semantic html (and even with those freakish sites I will try).
If you never looked at your website via lynx or used a screenreader I highly encourage it. It will give you a different perspective on things.
...which the text-to-speech reader probably pronounces as "ay eleven why".
Similar to i18n and l10n for internationalisation and localisation.
Interestingly unlike w3c, so it's not standing for aaaaaaaaaaay :)
A11y is probably the easiest one to remember because it looks like ally. Which is what you're being by worrying about accessibility when you yourself don't rely on the standards.
Agree with you re: screenreaders.
Seriously, I've seen pages that create links by using a styled <span> tag with an onclick even that merely called a function that set document.location using a hard-coded value.
Did developers forget that `<a href=....>` exists?