10 ms·

I'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 ha

• danielvaughn 5y ago
  What I think the web really needs is headless behavior via attributes.
  • easrng 5y ago
    Like onclick, onsubmit, etc? We already have those.
• egeozcan 5y ago
  The problem is not just styling, but usability, the API, and even accessibility too. Example, a multi-select, see https://jsfiddle.net/z0Ltxh47/1/ 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.
  • marcosdumay 5y ago
    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.
    • egeozcan 5y ago
      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.
    • cabalamat 5y ago
      I would probably use a series of checkboxes for the same effect.
    • com2kid 5y ago
      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.
      • Shared404 5y ago
        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.
        • kreetx 5y ago
          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.
          • Shared404 5y ago
            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.
  • cookiengineer 5y ago
    How about some checkboxes and labels with the for attribute then?
    • iamben 5y ago
      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!
    • egeozcan 5y ago
      Which becomes a nightmare to look at with no styling: https://jsfiddle.net/wdqjyvsu/ https://jsfiddle.net/wdqjyvsu/ and then it gets complicated very quickly: https://jsfiddle.net/wdqjyvsu/1/ 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.
      • lhorie 5y ago
        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 https://codepen.io/lhorie/pen/xxPJpeB
        • 5y ago
  • ironmagma 5y ago
    Say what you will about ActiveX, but it allowed a much more native feel for web pages.
    • jraph 5y ago
      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 https://en.wikipedia.org/wiki/XUL
      • ironmagma 5y ago
        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.
      • MaxBarraclough 5y ago
        > 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.
  • tomger 5y ago
    The js fiddle example works great on iOS. I didn’t realize mobile safari supported a multi-select sheet!
    • nedt 5y ago
      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.
    • josephg 5y ago
      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.
  • cycomanic 5y ago
    What is the problem exactly seems to work fine on Firefox mobile
  • worldsayshi 5y ago
    >I can't select multiple non-consecutive items by using just my mouse Well you can with ctrl-click. A well hidden feature though.
    • egeozcan 5y ago
      > using just my mouse
• dfabulich 5y ago
  I have good news for you! https://open-ui.org/ 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 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.)
• K0nserv 5y ago
  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
  • closetohome 5y ago
    > Aesthetics shouldn’t trump usability It's true, and it really shouldn't be as controversial an opinion as it apparently is.
  • Uehreka 5y ago
    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.
    • K0nserv 5y ago
      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.
      • brimble 5y ago
        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.
      • mihaic 5y ago
        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.
• throw_m239339 5y ago
  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.
  • mmis1000 5y ago
    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.
• cosmotic 5y ago
  Most websites that use custom components look and feel broken, no matter what the year.
• Aeolun 5y ago
  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.
• cabalamat 5y ago
  > 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).
  • ajkjk 5y ago
    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.
    • bmn__ 5y ago
      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.
      • NoSorryCannot 5y ago
        Gross.
      • ajkjk 5y ago
        That's just petty, and not effective at making whatever point you're making anyway (which, well, I'm not sure what it is).
• mdoms 5y ago
  > 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.
  • yoz-y 5y ago
    That’s untrue. As long as the UI works, people will prefer a nicely looking one.
    • mdoms 5y ago
      > As long as the UI works,
• SPBS 5y ago
  What kind of CSS do you need to add to <select>? Do you have an example of this modern design?
  • rhdunn 5y ago
    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.
• 5350-uiop-1130 5y ago
  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.
  • hn_throwaway_99 5y ago
    > 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.
    • saagarjha 5y ago
      iOS is adding the ability for web apps to send push notifications.
• s17n 5y ago
  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".
  • folkrav 5y ago
    > 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?
• analog31 5y ago
  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.
  • scim-knox-twox 5y ago
    What you want is mostly already here - just use native HTML elements.
• shrimpx 5y ago
  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.
  • NegativeLatency 5y ago
    Date inputs are particularly terrible here once you try and do any constraints
• LAC-Tech 5y ago
  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).
• martindale 5y ago
  Agree completely. I'm practically one new-tab-opened-without-me-asking away from forking a browser just to remove this behavior.