71–80 of 194 posts
I have said it before, everyone (Developers that use Chrome almost exclusively) says Safari is the new IE but Chrome has been slowing becoming the thing they fought against since they defeated IE.
Some 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.
Earlier 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
Incremental improvement? Why release anything right?
They didn't mention it in the blog post that multiple isn't supported. Its perfectly fine if it is not supported right now. It would be great if they acknowledged that up front to set expectations accordingly.
For instance, if its explicitly not supported, then I won't be left wondering if its a bug or a misunderstanding of the implementation etc.
Communication would be really good here. I'm all for incremental improvement, I think we need more of it.
Doesn't mean there shouldn't be better communication about it.
The 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
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
Earlier quoted context omitted.
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.
Earlier quoted context omitted.
> basic typeahead It isn’t perfect, but have you tried ? Totally agree about tag pickers, I was bummed to see that Bootstrap didn’t have a tag selector component either.
I have, and failed. See https://news.ycombinator.com/item?id=40265782
See https://developer.mozilla.org/en-US/docs/Web/HTML/Element/da... compatibility. The demo on that page works for me in current Safari on both iOS and Mac.
Some 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.
This is more about rich HTML for the select options. Being able to select images, rows with two columns of information, extra information in a contrasting font weight, etc. This will be extremely helpful.
Earlier 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
"It doesn't trigger built-in mobile operating system components." Is that part of the spec? I can see Apple deviating from that implementation.
That would require rendering arbitrary HTML in the native widget, outside the browser. And I think that would require putting WebKit in the native widget. Or, to maintain a "copy" of the widget that looks like the native one but uses WebKit to render things. Seems annoying to maintain.
(And there are the security concerns mentioned by the other comments)