trying to write automation js for material ui dropdowns has been a PITA. This is the right direction!!
The element can now be customized with CSS
111–120 of 194 posts
Re: The <select> element can now be customized with CSS
#112The 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
For the record, there's already a bunch of custom select-a-like replacement elements out there; I'm partial to select2. The main reason for this is that selects don't come with what we used to call "combobox" features; there's no type-ahead completion, and you can't lazy-load options from a larger data source because of that.
My main gripe is the loss of rendering outside the browser pane. To be clear, we already don't have that on mobile at all; if you've ever used an iPad with Stage Manager you'll note how popovers - all of them, including native apps - are neatly conformed to the bounds of the containing window. Pop-over menus are supposed to break the window pane, but they don't, for reasons I don't quite understand but can guess rhyme with the word "security".
Re: The <select> element can now be customized with CSS
#113Earlier quoted context omitted.
Safari is the "new" IE. I put "new" in quotes because it's been this way for like a decade.
--- start quote --- Back fifteen years ago IE held back the web because web developers had to cater to its outdated technology stack. “Best viewed with IE” and all that. But do you ever see a “Best viewed with Safari” notice? No, you don’t. Another browser takes that special place in web developers’ hearts and minds. --- end quote --- https://www.quirksmode.org/blog/archives/2021/08/breaking_th...
Yes, Safari is not exactly like IE because IE had a dominant user share once upon a time.
We don't see "best viewed in Safari", but we do see plenty of sites that can be viewed in Safari, despite the extra effort used to get them there. And I'm not even a regular chrome user.
Re: The <select> element can now be customized with CSS
#114Re: The <select> element can now be customized with CSS
#115Earlier quoted context omitted.
If anything chrome is the engine with odd quirks you are forced to work around.
I haven't found this to be the case in my experience.
Maybe it's just iframes that are the issue but they were a devil and a half to get working in chrome (or blink ig) without relying on third party cookies.
Re: The <select> element can now be customized with CSS
#116It's been 84 years...
Re: The <select> element can now be customized with CSS
#117The element can now be customized with CSS *in Chromium browsers*
Can't wait to use it in 2030 when my work stops supporting IE11
Re: The <select> element can now be customized with CSS
#118The 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...
with automatic ISO8601 timezone offsets would be awesome too!
ISO-8601 is not the correct format for serializing local time unless it's in the past.
In my experience, a local datetime picker is going to be used almost exclusively for a future date and time. What you want instead of a timezone offset is a zone ID. That way date and tzdata can handle it properly on the backend.
Re: The <select> element can now be customized with CSS
#119Why would this be preferred over creating a new HTML element, like ?
Backwards compatibility. Older browsers will still be able to render the and submit it as part of a form, just with its options unstyled.
Re: The <select> element can now be customized with CSS
#120> 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.
This is only if you opt in to base-select, so if you don't use that, everything should continue to work the same, as far as I can tell.
"You" in this case is the website author. From a user perspective, that doesn't solve the problem.