Now how do I add an text input filter? Is that another 20 year wait? :-)
The element can now be customized with CSS
51–60 of 194 posts
Re: The <select> element can now be customized with CSS
#52Earlier quoted context omitted.
I doubt it'll still be able to do those things. From the article: >Using base-select loses a number of features and behaviors: > The doesn't render outside the browser pane. > It doesn't trigger built-in mobile operating system components. I have mixed feelings about it. Mobile users, get ready for poorly optimized select elements. On the other hand it reduces the need for javascript for styling forms, which is good
That's fair, but I assume that is the initial implementation. Surely, over time, browser vendors will want to make the full spectrum of select functionality available consistently.
Definitely not. Why would they let web devs render outside of the browser window? That's a recipe for disaster.
Re: The <select> element can now be customized with CSS
#53Looks pretty broken in FF 136.0.2 (missing backgrounds/boxes, the popoup menus are visible).
Re: The <select> element can now be customized with CSS
#54Oh the irony of the Chrome dev blog failing Google's own Core Web Vitals test
Re: The <select> element can now be customized with CSS
#55Some controls are better left unstyled. Look what happened to scrollbars: either they are too thin to grab, have bad color contrast, so it is hard to see what part to actually grab, and, finally, some smartypants have managed even to remove scrollbars altogether from their website. Sure, default select is not the prettiest control, but it gets it job done.
Unfortunately those unusably small or invisible scrollbars are the default in many browsers. Such as Firefox on Linux, which I'm using right now.
Re: The <select> element can now be customized with CSS
#56> It doesn't trigger built-in mobile operating system components. I worry about this. The built-in mobile operating system components are reliable, accessible, and responsive. I really like it when an input element opens the Android UI because I know how it works and that it is reliable. This applies to , but also date/time inputs for example.
Chrome already uses plenty of non-native components. Firefox is similar. Moreover while I can understand the concern about poorly implemented components from random web developers, Google is probably the best positioned to implement a widget that faithfully replicates the native equivalent, at least on Android.
> Chrome already uses plenty of non-native components. Firefox is similar.
This is then won't be consistent with native OS apps, but still be consistent across websites. Better than everybody doing different div+JavaScript magic which behaves slightly different across different websites.
Re: The <select> element can now be customized with CSS
#57Oh my god. This has got to be like 20 years in the making
I'd love to know the opportunity cost - billions?
Re: The <select> element can now be customized with CSS
#58Earlier quoted context omitted.
I agree that this is a huge improvement, but it's also over a decade late IMO. This should've been accomplished well before now, especially given that the issue has been there since the beginning.
Because frontend is frontend, Javascript frameworks dominated the conversation even for silly things like basic web forms for the past 15 years. Basic HTML/CSS is now catching up to the fact that not everyone wants to run a Javascript monstrosity for custom styling on very basic tasks.
Forms are hard because they are the most stateful and most ubiquitous UI component that everyone comes in contact with. HTML has a few barebones tools to help you out, but they aren't good enough for the best user experience if you really wanted to polish a form like show errors exactly when you want to show them and only allow submission exactly when you want to allow it and represent error states in much better ways.
It's especially obvious once you're making forms outside of HTML and you realize that it's not any simpler with any less UX consideration. The only thing that changed was the language you're writing that polish in.
Re: The <select> element can now be customized with CSS
#59The fact that I'm disproportionally excited about this probably dates me as an early 2000s web developer. But since selects can do things that you simply cannot recreate in HTML, e.g. have options drop downs that extend outside the viewport boundaries, makes this a really helpful feature. Now, do autocompletes and tag selectors next...
I doubt it'll still be able to do those things. From the article: >Using base-select loses a number of features and behaviors: > The doesn't render outside the browser pane. > It doesn't trigger built-in mobile operating system components. I have mixed feelings about it. Mobile users, get ready for poorly optimized select elements. On the other hand it reduces the need for javascript for styling forms, which is good
"It doesn't trigger built-in mobile operating system components." Is that part of the spec? I can see Apple deviating from that implementation.
Re: The <select> element can now be customized with CSS
#60Can we have a fully native combobox now?
This is badly needed. Until we have combobox, the is best implemented as a readonly combobox, because you need to implement combobox in any case.