Oh joy. Another way for website designers to override user display preferences.
The element can now be customized with CSS
151–160 of 194 posts
Re: The <select> element can now be customized with CSS
#152Earlier 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
Mobile users are the majority of users by far. Do web designers really make their sites hostile to most of their users? (I suspect the answer is yes)
I think this totally depends on the site in question. Seriously researching something is hell on mobile browsers. As is doing productive stuff. Who wants to work on a tiny screen and no keyboard? On the desktop you can open dozens or hundreds of tabs on a single topic. Therefore I'm not surprised to see that on my site (technical articles) I can see the number of requests from mobile devices is just 17%.
Windows is 52%, Linux (without Android) is 18%, Macintosh is 13%, Android 11%, iOS 6%, Chrome OS 0.5%, others FWIW, some bots lie about what they are, which typically inflates the Windows results. I have another source of data, I can see what types of devices saw my site in Google results, and it's 69% desktops, 30% mobile, 1% tablets. (I can also see how many clicked, and it's similar numbers.)
Re: The <select> element can now be customized with CSS
#153Some 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.
managed even to remove scrollbars altogether from their website
What's worse are the custom JS ones that only appear on hover, obscuring the contents partially where they happen to be, and then when you try to drag them and accidentally move the pointer just a tiny bit off their skinny width, they disappear and you end up accidentally activating whatever element happens to be underneath.
Re: The <select> element can now be customized with CSS
#154Earlier quoted context omitted.
Huge miss in my opinion. If it doesn’t support all scenarios I’m not sure what the Chrome team is thinking here
I expect they're thinking they should ship something that works, and covers some use cases, and gradually improve it over time to support more use cases. Y'know, like how most software development works.
They've screwed this up several times by shipping too soon and then having to backpedal. The web is not something you want to screw up because they don't own every website in existence.
Re: The <select> element can now be customized with CSS
#155The challenge till this is widely supported (caniuse.com currently pegs it at 46% globally [1]) will be using this as a progressive enhancement that does not provide a worse or unusable experience for users with browsers not supporting it yet. In other words, don’t include critical information or functionality in the new styling that isn’t available in the underlying plain select element! But such is always a good pr…
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.
Over TWO decades late.
It is crazy to think what we only just have in anything non JavaScript in the past 20 years.
Re: The <select> element can now be customized with CSS
#156Earlier quoted context omitted.
The prevalence of JS and JS backed components is due to the reluctance of browser vendors to introduce new HTML elements that everyone has been lobbying for in the same time period. By and large browser vendors for the longest time, even today still in many respects, repeatedly ignore pleas for more elements that cover common use cases. Even when they do arrive, they can be half baked - like dialog or details / summa…
You can't make enough HTML elements to make everyone happy. This was the wrong idea from the start.
I would argue you can make enough HTML elements to make enough people happy. 80% for the 80%.
Re: The <select> element can now be customized with CSS
#157There should be a search box by default at the top of any dropdown if there are more than n items
Re: The <select> element can now be customized with CSS
#158What I was recently disappointed to find out is that you can't have a separate "display name" for the option items. That is, when the user clicks and the dropdown opens, I want the item labels in the dropdown to be of the form "$TITLE ($SHORT_DESCRIPTION)", but then when the dropdown is closed and something is selected, the control should just read "$TITLE". There are a few hacks to sort of make that work, but they a…
`attr()` has had terrible support which is a shame because it's been around for ages and could have let us do a lot of things without having to implement stuff manually. There's another way to try it though... I'd try putting two separate s inside each option, one for the short description and one for the long description. I'd hide one span with css if it was inside an tag. I'd hide the other span if it was inside a…
Ignoring this new feature, you can't put spans inside an option, only text. It's odd that they have this example in the post for the "old" way but they show it retaining the spans.
Re: The <select> element can now be customized with CSS
#159Earlier quoted context omitted.
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.
Right. The offset is not enough without a reference recorded time. You need the time and the time zone in order know the true time. This is a big problem is systems that don't have an intrinsic time type that deploy and have a database full of ambiguous times. Once it happens, backfilling that is a real slog.
Re: The <select> element can now be customized with CSS
#160Earlier 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
> The doesn't render outside the browser pane. ... It doesn't trigger built-in mobile operating system components. To me, this is intrinsically what makes a a . Styling is great, but without these features, this doesn't really bring anything new to the table
With these features scammers will create all sorts of "you have to log into your password manager" popups again.