- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Fri, 16 Sep 2022 16:35:34 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `Pseudo-classes for drop-down vs list box for <select>`.
<details><summary>The full IRC log of that discussion</summary>
<fantasai> Topic: Pseudo-classes for drop-down vs list box for <select><br>
<fantasai> github: https://github.com/w3c/csswg-drafts/issues/7422<br>
<fantasai> zcorpan: Proposed pseudo-class for <select> elements<br>
<fantasai> zcorpan: it's implemented in both Gecko and Chromium for their UA styles, under a vendor prefix<br>
<fantasai> zcorpan: WebKit doesn't implement the pseudo-class, instead uses attribute selectors<br>
<fantasai> zcorpan: and they have some bugs because of that, because hard to get the details right<br>
<fantasai> zcorpan: so I think there's agreement in the issue that we should have this pseudo-class<br>
<fantasai> zcorpan: and just need to settle thenaming<br>
<emilio> q+<br>
<zcorpan> :select-with-dropdown and :select-no-dropdown<br>
<fantasai> zcorpan: :select-with-drop-down and :select-no-dropdown<br>
<heycam> the WebKit UA style rules: https://searchfox.org/wubkat/rev/0c40ba62b482511fe03646f1d4982efd727475dd/Source/WebCore/css/html.css#1078-1092<br>
<astearns> ack fantasai<br>
<emilio> fantasai: haven't read the issue, was the bug in webkit about parsing the size attribute as int?<br>
<fantasai> zcorpan: It's parsing the size attribute correctly, the UA style sheet has an approximation of what the HTML results are<br>
<fantasai> zcorpan: so some edge cases will get wrong UA styles<br>
<fantasai> zcorpan: get a drop-down widget, but UA style thinks it should be a list box<br>
<fantasai> zcorpan: so a bit of a mismatch<br>
<emilio> fantasai: asking because it's the way the ua parses integers not being replicatable in css<br>
<emilio> ... maybe we want to introduce a way of selecting based on whether the attr is parsed correctly as an integer<br>
<emilio> ... that's been requested and more generally useful<br>
<heycam> q+<br>
<fantasai> zcorpan: I guess it would be possible<br>
<emilio> zcorpan: guess it would be possible<br>
<fantasai> zcorpan: complication because HTML has multiple number attributes<br>
<fantasai> zcorpan: It has integers and signed integers and floats<br>
<fantasai> zcorpan: I guess CSS could have those as well<br>
<fantasai> zcorpan: but CSS numbers are normally parsed differently from HTML numbers<br>
<emilio> fantasai: we could make it the same or have a flag<br>
<dbaron> "The display size of a select element is the result of applying the rules for parsing non-negative integers to the value of element's size attribute, if it has one and parsing it is successful. If applying those rules to the attribute's value is not successful, or if the size attribute is absent, then the element's display size is 4 if the element's multiple content attribute is present, and 1 otherwise." is the relevant quote from<br>
<dbaron> https://html.spec.whatwg.org/multipage/#concept-select-size<br>
<fantasai> zcorpan: Still seems more difficult to use as Web developer compared to pseudo-class<br>
<fantasai> zcorpan: there's also the multiple attribute<br>
<astearns> ack emilio<br>
<fantasai> emilio: I don't think it's a bad idea, but do we really need 2 pseudo-classes instead of one?<br>
<fantasai> emilio: would rather have single one, they're mutual exclusive<br>
<fantasai> emilio: assuming it's <select>-specific<br>
<fantasai> emilio: using select:listbox and select:not(listbox) would be nicer<br>
<fantasai> zcorpan: I think that's an okay outcome, biggest difference is you need to include a type selector to match the :not() state, whereas with pseudo-classes can only use the pseudo-classes<br>
<emilio> fantasai: we need to consider that we keep adding pseudo-classes<br>
<emilio> ... if we don't really need a pseudo-class<br>
<emilio> ... it's better not to have it<br>
<emilio> ... so that there's less for people to memorize<br>
<emilio> q+<br>
<emilio> zcorpan: agreed<br>
<astearns> ack heycam<br>
<emilio> fantasai: if we can do this with integer parsing and it's not too tricky maybe that's a better way around it<br>
<TabAtkins> In particular, if this is <select>-specific, then its name should be pretty <select>-specific, not generic. Probably means it needs a "select" in the name. But then it's just awkward to have to specify select again, like `select:not(:select-with-dropdown)`<br>
<fantasai> heycam: I'm not strongly against adding pseudo-classes, but wondering if really that useful to expose to authors<br>
<fantasai> heycam: if WebKit wants to fix compat issues, they can have an internal pseudo-class like other engines<br>
<fantasai> heycam: but for authors, thinking whether they are using listbox or dropdown, is something they know ahead of time<br>
<fantasai> heycam: I think it's rare for pages to switch between the two, so don't know how useful it is for authors to have different styles depending on this<br>
<fantasai> heycam: or need to rely on the flexibility of how HTML parses these attributes, vs knowing through the DOM already<br>
<fantasai> <fantasai> +1<br>
<fantasai> zcorpan: for cases where dev controls both markup and CSS, but that's not always the case<br>
<fantasai> zcorpan: maybe you're writing a stylesheet for a design system, want to apply to all WordPress pages<br>
<fantasai> zcorpan: you don't know what HTML they will use<br>
<astearns> ack emilio<br>
<fantasai> zcorpan: so that's why pseudo-class makes sense<br>
<fantasai> emilio: Was going to make similar comment to heycame<br>
<fantasai> emilio: we should encourage use of multiple attribute, it's easy to write selectors for that<br>
<fantasai> emilio: rather than relying on parsing of size attribute<br>
<fantasai> emilio: if you're making design system, ask them to use that<br>
<fantasai> emilio: but I'm on the edge on whether it's worth having a pseudo-class for this or not<br>
<fantasai> zcorpan: multiple is a semantic difference<br>
<fantasai> emilio: sorry, yes, you're riht<br>
<fantasai> s/riht/right/<br>
<fantasai> zcorpan: you can have a listbox that's not multiple<br>
<emilio> fantasai: doesn't seem to me like the selector for this would be that difficult if we had number parsing<br>
<emilio> ... is [multiple] plus size parsing as an integer >1<br>
<emilio> ... the details of how to parse invalid size attributes is a concern for implementors but not authors<br>
<fantasai> zcorpan: type out the two selectors?<br>
<TabAtkins> `select[size > 1], select[multiple]`<br>
<emilio> ... people usually don't write junk in their size attribute<br>
<emilio> `select:is([multiple], [size]:not([size="1"]))` is probably close enough in practice today<br>
<fantasai> `select:not([size>1],[multiple])`<br>
<astearns> ack dbaron<br>
<fantasai> dbaron: One, I tend to agree that if you're building a design system, you probably want these sorts of things<br>
<fantasai> dbaron: I think part of the reason we don't see much demand is that select is so hard to style, don't run into this problem much<br>
<fantasai> dbaron: if styling select worked more reliably, they would want on this more<br>
<fremy> +1 to what dbaron just said, styling select is a pain<br>
<fantasai> dbaron: Quoted HTML, which defines the display size of a select element<br>
<fantasai> dbaron: condition for a combobox vs listbox is display size being equal to 1 or not<br>
<fantasai> zcorpan: or multiple attribute being present or not<br>
<fantasai> dbaron: There's a few reasons the selectors above are wrong<br>
<fantasai> dbaron: one is that you need to test for size being zero<br>
<fantasai> dbaron: because HTML applies rules for non-negative integers<br>
<fantasai> dbaron: you want a valid size that is zero or 2 or more<br>
<fantasai> dbaron: or the multiple attribute<br>
<astearns> q?<br>
<fantasai> dbaron: it's doable if you had HTML non-negative integer parsing<br>
<fantasai> dbaron: but might be worth having this pseudo-selector anyway<br>
<fantasai> TabAtkins: fantasai's point was that dealing with invalid things is the sort of things that UA needs to care about, but page author doesn't<br>
<fantasai> TabAtkins: if they're putting random trashi in their size attribute, that's their problem<br>
<heycam> +1 to if we do have a way to do this, would rather a specific pseudo-class rather than a general integer parsing selector<br>
<fantasai> TabAtkins: but HTML UA needs to deal with all kinds of random trash<br>
<fantasai> dbaron: As you go further down the stack to style sheets meant to apply to more and more pages, get closer to needing to match implementation<br>
<fantasai> dbaron: bootstrap might get bugs on this<br>
<fantasai> TabAtkins: Bootstrap can say, "don't write random trash in your size attribute and this will work correctly"<br>
<fantasai> TabAtkins: if we were stricter in parsing this earlier we wouldn't have this problem for UAs<br>
<fantasai> TabAtkins: but even widely-used library, nobody needs to deal with this much trash<br>
<fantasai> TabAtkins: put a number here, and it works. Put a non-number here and it'll not work<br>
<fantasai> fremy: Authors shouldn't have to read the spec to figure out the conditions<br>
<fantasai> fremy: of course they can copy some weird code, but not very understandable<br>
<fantasai> fremy: you will copy and paste it, but not clear what it does at first sight<br>
<fantasai> fremy: if already implemented in engines, have this pseudo-class<br>
<fantasai> fremy: that sounds useful so why not<br>
<fantasai> fremy: why are we wasting time discussing if it's just removing a prefix in the code, seems silly<br>
<astearns> ack fantasai<br>
<fantasai> astearns: We started with what we called a pseudo-class, and now discussing maybe not having pseudo-class<br>
<fantasai> astearns: with arguments presented so far, anyone convinced we should have it?<br>
<fantasai> heycam: me<br>
<fantasai> astearns: Should we try to resolve to add pseudo-class?<br>
<fantasai> fantasai: I'd like to hear from Rachel Andrew and emeyer<br>
<fantasai> fantasai: if they are like, "Yes, we should definitely have this!" then great<br>
<emilio> FWIW this is how Gecko used to implement this with attribute selectors: https://hg.mozilla.org/mozilla-central/rev/13062d9979d254481851c0f8c9d9e608d91f6ae3<br>
<fantasai> fantasai: If not, I'm skeptical<br>
<rego_> there has been a lot of research about styling select in openUI, does anyone know if this topic was discussed?<br>
<fantasai> emeyer: It's hard for me to say, a pseudo-class mostly feels correct here, but fantasai is correct, we have so many pseudo-classes now<br>
<fantasai> emeyer: even more than I realized until recently<br>
<fantasai> emeyer: So I'm not sure I'm 100% convinced that it's best<br>
<fantasai> emeyer: Some way of doing this is good<br>
<fantasai> emeyer: but whether it should be a pseudo-class or ???<br>
<fantasai> fantasai: We would add number-based attribute selectors, and you would make a selector<br>
<fantasai> astearns: It would be a copy-paste incantation<br>
<fantasai> fantasai: still have to do that if it's a pseudo-classs!<br>
<emilio> Another interesting edge case is `size=""`<br>
<heycam> emilio, similar but not exactly the same as the current WebKit UA style rule selectors<br>
<fantasai> TabAtkins: Who is asking for this? In the UA is one thing, but do other people need it?<br>
<heycam> emilio, yes that is exactly the difference<br>
<fantasai> zcorpan: reset stylesheets use it<br>
<emilio> q+<br>
<fantasai> zcorpan: incorrectly, usually<br>
<fantasai> fantasai: They are copy-pasted, so they can write a proper selector<br>
<astearns> ack emilio<br>
<fantasai> zcorpan: but used in lots of pages, should get all the cases correct<br>
<fremy> https://github.com/sansotmon/asistencia-salvarte/blob/50dde64556294e8e42dbb2f7950f1b9c078ebef7/web/core/themes/olivero/css/components/form-select.css<br>
<TabAtkins> Importantly - if they're not getting it right, *is this causing problems for people*?<br>
<fantasai> emilio: empty size attribute is another case<br>
<fantasai> emilio: also slightly more efficient to do a pseudo-class<br>
<fremy> ```[dir="ltr"] select[multiple] { padding-left: 9px }```<br>
<TabAtkins> Are they getting bugs and ignoring them because parsing numbers via CSS is hard? Or are they just not getting bugs?<br>
<fantasai> emilio: pre-parses faster than other random attributes<br>
<fremy> ^ this is wrong, first hit on github<br>
<fantasai> emilio: If ppl feel this is useful, then maybe it's not worth copy-pasting a weird incantation<br>
<rachelandrew> q+<br>
<astearns> ack rachelandrew<br>
<fantasai> rachelandrew: I think in terms of being easier to explain and less error-prone, pseudo-class is good<br>
<fantasai> rachelandrew: but do ppl actually want to do this, is also a valid concern<br>
<fantasai> rachelandrew: if people aren't asking for it<br>
<fantasai> rachelandrew: I like things to be straightforward<br>
<fantasai> rachelandrew: but we also have a lot of pseudo-classes, and have to teach people<br>
<fantasai> rachelandrew: so I don't have a strong feeling, but like emeyer I'm on the fence<br>
<fantasai> astearns: Then what I want to do is to close off the discussion in this meeting, take back to issue, have whatever the actual correct integer and multiple check would be<br>
<fantasai> astearns: so we have something to compare<br>
<fantasai> astearns: and come back to this issue on a telecon<br>
<fantasai> zcorpan: OK<br>
<fantasai> astearns: any other questions on this?<br>
<emilio> fantasai: do we want to add integer attr selectors?<br>
<emilio> ... generally speaking, do we want a proposal for that?<br>
<emilio> astearns: I dont' think we can decide that r/n<br>
<fantasai> astearns: not decide right now<br>
<fremy> select[multiple], select[size] { height: auto; }<br>
<fremy> in bootstrap<br>
</details>
--
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/7422#issuecomment-1249567427 using your GitHub account
--
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 16 September 2022 16:35:37 UTC