Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The element can now be customized with CSS

developer.chrome.com

Post reply on HN
Print view View original

101–110 of 194 posts

Re: The <select> element can now be customized with CSS

#101

Post by KTibow »

65 wrote: post #81
butz wrote: post #46

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.

I disagree. On my website I have a sidebar and a main content area. You are able to scroll through posts on the sidebar and through the content on the main content area. The sidebar is a dark color. Being able to use a thin sidebar and make the color of the sidebar dark to match the background makes the website look a lot better than having a clunky white sidebar on a dark background. The user can still obviously see…

Ideally web browsers would use better defaults so you wouldn't have to do this. Firefox is good with this in my opinion: scrollbars are very subtle, don't affect content width, and adapt to the `color-scheme`.

Re: The <select> element can now be customized with CSS

#104

Post by alabastervlog »

rbrownmh wrote: post #57
oliv__ wrote: post #6

Oh my god. This has got to be like 20 years in the making

I'd love to know the opportunity cost - billions?

The cost of browsers not having extremely-basic things that they either started to implement then abandoned in a nigh-useless state (login, frames) or never even tried to have but really, really should have once it was clear "web apps" were here to stay (datasource-backed lists and tables, table sorting without more custom JS than a sort function, drag-n-drop) is truly enormous. Who knows how many millions of person-hours.

Re: The <select> element can now be customized with CSS

#106

Post by nedt »

nedt wrote: post #105
cellover wrote: post #78

Love the fact that Google auto translate of the page completely breaks the page https://imgur.com/7gfXRrm

This is also very much how the page looks for me in Firefox. If it can't fail without issues it's not an option I'd select.

Oh ... it's actually their own integrated translation that breaks it. Now that's funny. They aren't escaping correctly. Now if someone wants to play around with that ...

Re: The <select> element can now be customized with CSS

#107

Post by no_wizard »

lelanthran wrote: post #92
no_wizard wrote: post #31

Earlier 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…

> Even when they do arrive, they can be half baked - like dialog or details / summary - and that doesn’t help matters How are those half-baked? No smooth transition for details/summary, maybe? Dialog seems to work well enough with little to no javascript required: Warning: ... Dismiss My personal bugbear is the date/time input - FF doesn't even show a click element for time, you have to type in the time.

There's some quirks with the API around open vs openModal if you aren't aware of the accessibility implications you may not even realize this is the case.

Forms have some special quirks inside of a dialog.

The biggest thing though, is for the life of me I don't understand why you can't open and close a dialog without JavaScript. There's no way to do it.

Re: The <select> element can now be customized with CSS

#109

Post by no_wizard »

pests wrote: post #100
no_wizard wrote: post #73

Earlier quoted context omitted.

Incremental improvement is great, but I do want to know what they're thinking here. 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 implem…

In the original dev blog from last year they mention it’s still a work in progress. https://developer.chrome.com/blog/rfc-customizable-select > Note: The multiple and size attributes on select ( and ) are not supported in appearance: base-select yet.

From last year while it was a WIP

and now this as of Chrome 135 is shipped, and they didn't think it wise to include a back reference to this post, calling out what isn't supported?

They can and should communicate this is all.

Re: The <select> element can now be customized with CSS

#110

Post by tracker1 »

no_wizard wrote: post #107
lelanthran wrote: post #92

Earlier quoted context omitted.

> Even when they do arrive, they can be half baked - like dialog or details / summary - and that doesn’t help matters How are those half-baked? No smooth transition for details/summary, maybe? Dialog seems to work well enough with little to no javascript required: Warning: ... Dismiss My personal bugbear is the date/time input - FF doesn't even show a click element for time, you have to type in the time.

There's some quirks with the API around open vs openModal if you aren't aware of the accessibility implications you may not even realize this is the case. Forms have some special quirks inside of a dialog. The biggest thing though, is for the life of me I don't understand why you can't open and close a dialog without JavaScript. There's no way to do it.

I'm with you... would be nice to have:

   Open Dialog
   ...
   
     Close Dialog
It would just make so much sense.
Post reply on HN