- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Thu, 08 Aug 2024 15:30:04 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-ui] Pseudo-elements for stylable select`, and agreed to the following: * `RESOLVED: Pseudo-element selectors apply only to the UA-provided elements in a particular role` <details><summary>The full IRC log of that discussion</summary> <gregwhitworth> q?<br> <keithamus> Both the pseudo elements for appearance base mode. Two issues, ???... should these elements cover the author provided thing or the button/datalist not be a target of the pseudo elements<br> <keithamus> The author provided button element; should the element target the author provided or just the fallback? There are trade-offs here.<br> <MikeSmith> RRSAgent, make minutes<br> <RRSAgent> I have made the request to generate https://www.w3.org/2024/08/08-css-minutes.html MikeSmith<br> <gregwhitworth> q+<br> <keithamus> ... Could be developer convenience but could have complications. How does it work with animations, subtree, etc.<br> <keithamus> ... There might be styles we could fall back but not both, so we'd need to invent some internal pseudo element to target the fallback<br> <keithamus> ... Might be better for developers if it targets both<br> <keithamus> s/Both the/jarhar: Both the<br> <gregwhitworth> ack gregwhitworth<br> <keithamus> gregwhitworth: when you go to change it, its no longer the element. I don't know the technical reasons emilio is pushing back on, but as a dev when I replace it I now own that element so wouldn't expect pseudo to work.<br> <gregwhitworth> ack fantasai<br> <keithamus> fantasai: we have several elements that replace default; button, dropdown, I think we have to think about when a dev is styling they might not know exactly how the control is put together.<br> <keithamus> ... It might be implemented as native for a while, upgraded to datalist, you didn't change your stylesheets, you're using a component library...<br> <keithamus> ... I can definitely see why you'd want them to match. The other technical concerns are certainly real.<br> <emilio> q+<br> <keithamus> ... From authoring it would be more convenient and more robust.<br> <gregwhitworth> ack emilio<br> <keithamus> emilio: I think I get both points. As author, I agree with Greg but if you have more generic styles it can be nice to have a single selector. As a component library, presumably they'd export the dropdown in some other way e.g. shadowpart or shadowdom so you cannot target directly yourself.<br> <keithamus> ... Given theres no precedent. Given the complications; like we have a bunch of APIs for exposing pseudo element stuff. Eg getanimations with subtree true returns pseudo element animations, but it would be weird to behave that way... you kind of want the element reference if you have the pseudo but can't do that with shadow root<br> <keithamus> ... Causes inconsistencies with various APIs like this.<br> <gregwhitworth> ack fantasai<br> <keithamus> ... Plus there are usecases for e.g. targeting built in UA one. It's just less complicated to explain if you use pseudo to match the provided, and otherwise not.<br> <emilio> q+<br> <keithamus> fantasai: I meant component library in a much more general sense, like not just web components but CSS libraries or something<br> <gregwhitworth> ack emilio<br> <fantasai> s/something/templates or something/<br> <keithamus> emilio: but then changing implementation from built-in datalist to custom one is a breaking change but no more changing than, for example, changing a button to a link<br> <keithamus> ... if you're using a 3rd party library you need to be mindful of these changes and breaking the API<br> <keithamus> jarhar: sounded like people are in favor of both sides?<br> <keithamus> gregwhitworth: We could straw poll or take it back to the github issue.<br> <keithamus> fantasai: from the agenda it looks like we have this one issue which is a superset of lots of small issues. Can we split this up?<br> <keithamus> gregwhitworth: you want to tackle this as 4 separate ones?<br> <keithamus> fantasai: if they're independently resolvable filing separately makes it easier to focus on each one<br> <keithamus> chrishtr: we could resolve on one of those<br> <keithamus> gregwhitworth: would we want to have a default position?<br> <keithamus> ... if an element gets replaced, the pseudo element being applicable irregardless of which one it is - do we want to resolve on that first?<br> <keithamus> jarhar: that's one of the three.<br> <keithamus> fantasai: I'd agree we should be consistent<br> <keithamus> ... as for which way, I feel like we've heard from two or three people<br> <keithamus> jarhar: I think we discussed this in openui before, a vague memory of people preferring the ???<br> <keithamus> q+<br> <gregwhitworth> keithamus: if we allow the pseudo's to target the author provided is the way to differentiate between author and useragent provided?<br> <fantasai> ::button:not(button)<br> <gregwhitworth> fantasai: yes, because you could...<br> <gregwhitworth> ^ typed out her example<br> <gregwhitworth> keithamus: is that more difficult than than the reverse<br> <gregwhitworth> keithamus: if I want to select for the built-in verse user provided; which one is more complicated<br> <emilio> q+<br> <gregwhitworth> q+<br> <gregwhitworth> ack keithamus<br> <keithamus> emilio: I think especially since you cannot use pseudo elements in :not()... I think fantasai's suggestion might not work without changes to pseudo syntax.<br> <keithamus> ... we don't reveal tag name of the pseudo element. You'd need select:has(datalist:thepsuedo) which is kind of annoyin<br> <keithamus> s/annoyin/annoying<br> <gregwhitworth> q?<br> <emilio> `select:has(> button)::button` or so<br> <gregwhitworth> ack emilio<br> <emilio> ack emilio<br> <keithamus> chrishtr: so this would be in favour of not ???. Like reducing complexity<br> <keithamus> chrishtr: if there's additional engine complexity in trying to match both at the same time, let's go with just the built-in. Let's developers in a straightforward way to differentiate and avoids complexity in the engine<br> <gregwhitworth> ack gregwhitworth<br> <keithamus> gregwhitworth: curious; two jobs to be done: when would I really want to differentiate? To interrogate if there's a user provided vs user-agent provided element.<br> <emilio> q+<br> <keithamus> ... I get fantasai's use case. The component library, there's a contract there... but its low probability. What's the use case though keithamus?<br> <gregwhitworth> keithamus: I don't think I have a good answer to that to be honest<br> <gregwhitworth> ack dbaron<br> <keithamus> dbaron: if we go down the path of making pseudo only match built-in, if the author provided ones are in some cases - I don't know how complex - but if they're complex they could have a pseudo class, to match an existing element. A pseudo class is a thing that matches what you already have, vs a pseudo class to match an element that exists in the UA<br> <keithamus> shadow. One way to do it.<br> <gregwhitworth> ack emilio<br> <keithamus> emilio: I dont think the rules here are particular complicated. You need to be a direct child of the select element, so I don't think the pseudo class is necessary. The reason for interrogating if it's a built-in, if you're not a built-in you can do more complex styling of the innards. If you have a big CSS codebase and 2 ways of addressing the<br> <keithamus> same thing in subtly different ways, it's not amazing but you could want<br> <keithamus> ... to target the built-in with basic styles and non-built-in for more complex styles. If the pseudo matches both you need to undo the pseudo rules with non pseudo selectors.<br> <jarhar> q?<br> <chrishtr> +1, good point<br> <fantasai> Option 1: Pseudo-element selectors apply to both the user-provided and UA-provided elements in a particular role<br> <keithamus> gregwhitworth: two foundational positions for this base one that informs the 3 other issues. User submitted will or won't apply. Should we take this back to the issues? I feel like I'm in favour of _not_ having them to apply to user-provided. Is there a strong reason to go in the other direction?<br> <fantasai> Option 2: Pseudo-element selectors apply only to the UA-provided elements in a particular role<br> <keithamus> ... does anyone have a strong position<br> <fantasai> Option 2.1: Also provide a pseudo-class to select to user-provided (and UA-provided?) elements in a particular role.<br> <keithamus> ... does anyone oppose doing a straw poll?<br> <keithamus> fantasai: I didn't fully catch what dbaron's position on pseudo classes was.<br> <keithamus> jarhar: I think it could differentiate what the element was selecting<br> <fantasai> 1.1: And also provide a pseudo-class on differentiating whether it's a real or pseudo element.<br> <keithamus> dbaron: you could do either way! But perhaps it's better to leave the sub-options out of the straw poll.<br> <chrishtr> option 2<br> <emilio> 2<br> <jarhar> 2<br> <ntim> 2<br> <keithamus> gregwhitworth: for straw poll we'll just do the main options. Please put opion 1 or option 2 in IRC<br> <fantasai> 0<br> <keithamus> 2<br> <gregwhitworth> 2<br> <astearns> abstain<br> <dbaron> 2 (weakly)<br> <fantasai> s/0/abstain<br> <fantasai> RESOLVED: Pseudo-element selectors apply only to the UA-provided elements in a particular role<br> <emilio> q+<br> <gregwhitworth> ack emilio<br> <keithamus> emilio: for the library use case, I think we resolved on the pseudo element kind of a part-like pseudo. If we were really concerned about providing the same API as a component library we could make exportparts work to expose the inner pseudo elements. Then you could expose the same API in both<br> <keithamus> gregwhitworth: does this resolve the other issues jarhar?<br> <keithamus> jarhar: I think it could be worth raising 1 new issue for each pseudo, asking should it exist and what should it be named. WIth that in mind we can close this issue<br> <keithamus> chrishtr: what are the three issues?<br> <keithamus> ... 1 is the one we resolved<br> <keithamus> ... 2 is do we need them<br> <keithamus> ... 3 is what are their names?<br> <keithamus> jarhar: yes<br> <keithamus> chrishtr: are we ready to discuss 2 or 3 yet?<br> <keithamus> gregwhitworth: yes I think it's a bookkeeping issue<br> <keithamus> chrishtr: jarhar could make issues after the meeting and copy the resolutions<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10462#issuecomment-2276112948 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 8 August 2024 15:30:05 UTC