- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 29 Jan 2025 22:37:01 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[cssom-1][css-pseudo-4] getComputedStyle and pseudo-elements with pseudo-classes or sub-pseudo-elements`, and agreed to the following: * `RESOLVED: add bramus as co-editor to CSS Scroll Animations` <details><summary>The full IRC log of that discussion</summary> <kbabbitt> schenney: observation is that with gCS you can gCS an element and an optional pseudo class string<br> <kbabbitt> ... currently speced as being a single pseudo class string<br> <kbabbitt> ... given other issues we just talked about, potential of having first-line hover etc.<br> <kbabbitt> ... no way to gCS on multiple chained pseudos<br> <emilio> q+<br> <kbabbitt> ... would be a change to behavior of gCS to enable<br> <oriol> q+<br> <kbabbitt> ... proposal I agree with is to change 2nd argument from single pseudo selector string to become pseudo element compound selector<br> <lea> q?<br> <kbabbitt> ... propose we extend gCS to instead of single string with one pseudo, list of pseudos<br> <astearns> ack dbaron<br> <kbabbitt> dbaron: both pseudo element and pseudo class in there<br> <kbabbitt> ... need to be careful to distinguish<br> <kbabbitt> ... right now gCS argument is just pseudo element<br> <kbabbitt> ... gives style given what pseudo class is applied<br> <kbabbitt> ... providing a way to change that is a bigger discussion<br> <kbabbitt> ... second piece: I think we discussed this for some other use case<br> <bramus> https://github.com/w3c/csswg-drafts/issues/4456 was the issue<br> <kbabbitt> ... I think we have a resolution to allow multiple pseudo elements in that string<br> <TabAtkins> Yeah, `<pseudo-compound-selector>+` would be the grammar term to use<br> <kbabbitt> schenney: I did not follow up on that, I think we should table this<br> <lea> q+<br> <kbabbitt> s/that/issue 4456/<br> <oriol> q-<br> <kbabbitt> ... we should look at this more before we bring it back<br> <kbabbitt> ... oh wait, I said we should use the resolution for 4456<br> <astearns> ack emilio<br> <kbabbitt> emilio: what dbaron said<br> <kbabbitt> ... I don't think we should accept pseudo classes<br> <kbabbitt> ... for some specific cases it might be useful<br> <kbabbitt> .. doesn't match what happens for elements<br> <bramus> q+<br> <kbabbitt> ... element would give style with pseudoclasses applied at the time<br> <kbabbitt> ... could be use cases to request with a given pseudo class<br> <kbabbitt> ... but I don't think we want to expand that only for pseudo elements<br> <kbabbitt> astearns: if we use 4456 resolution it's only talking about pseudo classes<br> <astearns> ack lea<br> <emilio> s/classes/elements<br> <kbabbitt> emilio: think we should not mess with pseudo classes here<br> <TabAtkins> then we need to make the grammar a little more restrictive, that's fine<br> <dbaron> s/astearns/emilio/<br> <kbabbitt> lea: basically allowing chained pseudoe elements seems reasonable which not<br> <kbabbitt> s/which/why/<br> <kbabbitt> ... hoping we can limit number of times this is needed in the language in general<br> <kbabbitt> ... agree with dbaron about pseudo classes<br> <kbabbitt> ... time to turn that argument into dicutionary perhaps<br> <kbabbitt> ... much larger scoped change than what's discussed here<br> <kbabbitt> ... seems like a useful addition that should be discussed separately<br> <astearns> ack bramus<br> <emilio> ack bramus<br> <fantasai> +!<br> <fantasai> +1<br> <kbabbitt> bramus: hijacking thread ... pseudo elements are not first class citizens in DOm<br> <kbabbitt> ... filed aqn issue for that<br> <kbabbitt> ...11559\<br> <kbabbitt> ...something to think about<br> <kbabbitt> astearns: for this issue, we can just apply resolution from 4456 and reuse mechanism from there?<br> <kbabbitt> schenney: I think it's close no change needed<br> <emilio> https://github.com/w3c/csswg-drafts/issues/11559 fwiw<br> <kbabbitt> astearns: might be good to have example in spec<br> <kbabbitt> schenney: will add example to spec so we can explain<br> <dbaron> I think the key distinction between pseudo-elements and pseudo-classes here is that pseudo-elements are about finding a different object, whereas providing a pseudo-class you're asking the entirely different question of "what would the style for *this* object be if we changed pseudo-class state in this way")<br> <kbabbitt> fantasai: propose adding bramus as co-editor to CSS Scroll Animations<br> <kbabbitt> ... he has contributed very heavily<br> <kbabbitt> ... very much on design side, coming at it from a different perspective by providing examples<br> <kbabbitt> ... he put in as much effort in design as editors have<br> <fantasai> s/examples/demos and use cases/<br> <kbabbitt> bramus: I would be happy to, thank you for acknowledging<br> <kbabbitt> RESOLVED: add bramus as co-editor to CSS Scroll Animations<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10297#issuecomment-2623033432 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 29 January 2025 22:37:02 UTC