181–190 of 194 posts
Earlier quoted context omitted.
There needs to be some middle ground. I'd trade off just being able to set just the background color and font and keep these native-like features
The following works for me in Chrome, and doesn't prevent the menu from going outside of the viewport: select, option { background: red; font-family: 'comic sans ms'; }
firefox issue https://bugzilla.mozilla.org/show_bug.cgi?id=1944403
Last update to the issue is a pointer to test results:
https://wpt.fyi/results/html/semantics/forms/the-select-elem...
At least Safari is failing as well, currently, so the FF team has a bit of time.
Earlier quoted context omitted.
--- 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.
The absolute vast majority of those which don't work in Safari use Chrome-only non-standards.
And there is a tiny minority of sites that run into some Safari-specific quirks
Earlier quoted context omitted.
`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.
The problem is that you can't target the span in the original parser.
But, you could use a template, since it's contents are ignored by text content parsers.
You can have your option as:
Normal Difficulty - The way it's meant to be played
With the original parser, this will be parsed as:
Normal Difficulty
And with the new parser (so long as you opt into it with the `appearance: base-select` rule):
Normal Difficulty - The way it's meant to be played
---------------------------
Then once you've opted into the new parser, you can target both the span and template to render how you want. (e.g. Give span a larger font-weight, give template a display mode of block and italicised text)
Earlier quoted context omitted.
> 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
Thanks to humanity, supporting this is a surefire ticket to someone figuring out how to phish credentials through a element.
Earlier quoted context omitted.
I have, and failed. See https://news.ycombinator.com/item?id=40265782
It may not be present in Apple’s official documentation but it has been supported since Safari 12.2. 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.
Earlier quoted context omitted.
I'm with you... would be nice to have: Open Dialog ... Close Dialog It would just make so much sense.
> I'm with you... would be nice to have: You can do this right now already: // For opening Open // For closing Close I think the problem here is that it is impossible to actually use the result from `close()`, as it can return a status, IIRC. > It would just make so much sense. That way above that I propose is about as sensible as the way you propose. If there are any problems with my proposal that are solved by your…
Earlier quoted context omitted.
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.
You can put s inside an . The 's `innerText` is used to populate the native control's label, meaning the inside of the spans are too. The problem is that you can't target the span in the original parser. But, you could use a template, since it's contents are ignored by text content parsers. You can have your option as: Normal Difficulty - The way it's meant to be played With the original parser, this will be parsed a…
I assumed your comment was trying to give the parent commenter a strategy that would work with the "classic" select but I see now that you mentioned "selectedoption" so you were talking about the new one.
Earlier quoted context omitted.
> I'm with you... would be nice to have: You can do this right now already: // For opening Open // For closing Close I think the problem here is that it is impossible to actually use the result from `close()`, as it can return a status, IIRC. > It would just make so much sense. That way above that I propose is about as sensible as the way you propose. If there are any problems with my proposal that are solved by your…
The point was to be able to do it without JS.
For all practical purposes, there is no difference between the two.
I understand that the `onclick` wouldn't fire in browsers where JS is turned off, but in that case (no JS) you're going to have an awful user experience using dialogs even with builtin open/close attributes for dialogs.