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

131–140 of 194 posts

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

#131

Post by progmetaldev »

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.

If you need to worry about ADA compliance (I always do, but not always paid to), this can be difficult to address.

I remember Opera, before it was bought, had the best support for html5 elements and date/time inputs were the best (along with almost all others). Sad to think that a leader in this area was sold off, and not to a buyer that cared about usability and the web the way Opera did.

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

#132

Post by JimDabell »

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.

> 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.

You can use popovers like this without JavaScript:

    Open
    
    
        Close
You can mark a element as open by default with the `open` attribute, and you can close it with a button using the `dialog` form method. No JavaScript required for that either.

I don’t think there’s any way at present to open a `` element specifically without JavaScript, but command/commandfor handles this and was recently added to the HTML specification:

https://github.com/whatwg/html/pull/9841

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

#134

Post by tredre3 »

codedokode wrote: post #122
gjsman-1000 wrote: post #35

Earlier quoted context omitted.

> and firefox will become even less relevant No; Firefox can easily afford financially to add this feature. Firefox is already irrelevant; no developer will shed a tear about just blocking Firefox if they refuse to implement. Boycotting won't work either, because boycotts almost never work.

Firefox doesn't have ad measurement and interests sharing built in yet (or am I wrong?) so it is very relevant for me. I would rather use black-and-white selects everywhere rather than having an advertising engine built into the browser.

You are indeed wrong.

https://support.mozilla.org/en-US/kb/privacy-preserving-attr...

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

#135

Post by cosmic_cheese »

majora2007 wrote: post #37
wolframhempel wrote: post #36

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...

It's actually crazy that we don't have a basic typeahead component or tag selector in this day and age with HTML. Every web page I've ever built has needed these components and while there are libraries out there, they all have an annoying bug here or there. But considering we are just now getting Select tags with styling, signals how long it might take for a typeahead which is vastly more complex.

Why implement broadly useful HTML widgets when you can instead put those engineering resources to work on a new WebBeer API that fetches the number of beers in the user’s fridge or something else similarly niche?

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

#136

Post by phpnode »

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.

it's coming: https://developer.mozilla.org/en-US/docs/Web/API/Invoker_Com...

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

#137

Post by immibis »

asddubs wrote: post #40
wolframhempel wrote: post #36

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

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)

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

#138

Post by immibis »

caesil wrote: post #49
wolframhempel wrote: post #45

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.

I don't think browsers will ever let web code affect things outside the viewport because scammers would cook up some truly zany things with that power.

Even rendering arbitrary pixels inside the viewport is bad enough. Something that went out of fashion but is apparently now back in fashion is detecting the user's operating system and browser, then displaying a pixel-perfect replica of a second browser window open to Paypal and asking you to log in... displayed within the bounds of the first browser window.

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

#139

Post by immibis »

facile3232 wrote: post #94
recursive wrote: post #66

Earlier quoted context omitted.

Safari is the "new" IE. I put "new" in quotes because it's been this way for like a decade.

If anything chrome is the engine with odd quirks you are forced to work around.

Chrome's quirks become the standard and other browsers have to implement them.

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

#140

Post by immibis »

SoftTalker wrote: post #85
crazygringo wrote: post #82

Earlier quoted context omitted.

No, things need to communicate the required information for the task at hand. Limiting information can be harmful in many cases, and make things more difficult rather than simpler. And consistency can similarly limit usability. What if I want to select one of 10 colors, with limited screen space? Isn't a select with color swatches perfect? Or even better, color swatches with color names beside? Why do you think that…

Good example. There are dozens, maybe hundreds of different ways people have invented color pickers. Every app does it a little differently, meaning you have to stop and think about it every time. I'll take a simple select with the color name. If you want a swatch, put that off to the side and update it with an event handler on the select.

Windows had a standard color picker dialog that you may remember from Windows 98-Viata mspaint.

Jack of all trades, master of none. The mspaint-specific palette toolbar was much more intuitive.

Post reply on HN