- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Mon, 12 Feb 2024 19:30:36 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed ``[css-view-transitions-1][cssom] Clarify how `getComputedStyle` should be have with view-transition pseudo-elements``, and agreed to the following: * `RESOLVED: script APIs (getComputedStyle, WAAPI) only receives a name parameter, no classes or *, and matches an actual initialized vt pseudo` <details><summary>The full IRC log of that discussion</summary> <TabAtkins> noamr: gCS() has a second param of a pseudo-element name<br> <TabAtkins> noamr: in CSSOM it's not clear how this is suppsoed to behave<br> <TabAtkins> noamr: it says "get the element that is a pseudo" but that's vague<br> <TabAtkins> noamr: so what shoudl this return if there is no VT at all<br> <TabAtkins> noamr: but there is style for VT pseudos<br> <TabAtkins> noamr: one option is, there's no element here so it returns an empty style decl<br> <TabAtkins> noamr: Another is to say, yes but if there *was* one this is how it would be styled<br> <TabAtkins> noamr: it gets more complicated when VT classes are involved...<br> <TabAtkins> q+<br> <flackr> q+<br> <fremy> I don't think you can meaningfully compute that, since you don't know the classes and names<br> <TabAtkins> noamr: main thing about hypothetical route is that it does coincide with how it works on other pseudos<br> <TabAtkins> noamr: shoudl probably clarify that in CSSOM<br> <miriam> ack fantasai<br> <fantasai> https://github.com/w3c/csswg-drafts/issues/9880<br> <emilio> q+<br> <TabAtkins> fantasai: raising Tim's suggestion from the issue<br> <TabAtkins> fantasai: gCS() should just support the simple form, with the name, not wildcards or classes. doesn't make sense to gCS() from something not uniquely identifiable<br> <TabAtkins> khush: so the name must be there. if there's *also* classes, and they don't match, what then?<br> <emilio> qq+<br> <TabAtkins> khush: today if you pass a class and id but those aren't being applied to th eelement, what happens?<br> <schenney> q+<br> <TabAtkins> emilio: I think we discussed this with ::part(), we might have a resolution on that<br> <miriam> ack emilio<br> <Zakim> emilio, you wanted to react to fantasai<br> <TabAtkins> emilio: don't rmeember if it's to do what elika said (don't return things that aren't uniquely identified) or use the first in tree order to represent it<br> <TabAtkins> emilio: might be worth looking at that and seeing what we resolve<br> <flackr> q-<br> <khush> q+<br> <TabAtkins> fantasai: you haven't buil the tree yet so there's no order<br> <fantasai> scribe+<br> <emilio> ack emilio<br> <TabAtkins> emilio: if you haven't built it yet, you don't know what to style anyway<br> <miriam> ack TabAtkins<br> <fantasai> TabAtkins: I think the easiest answer...<br> <fantasai> ... we should check up on what we did for ::part, and be consistent<br> <fantasai> TabAtkins: I'm inclined to the "don't have it work, because doesn't uniquely identify a set of pseudos"<br> <fantasai> TabAtkins: In general pseudo-element treatment in CSSOM is somewhat nonsensical mishmash of stuff<br> <fantasai> TabAtkins: I don't think we need to try really hard to make this API work well<br> <miriam> ack schenney<br> <TabAtkins> stefan: reason that ::spelling/etc report the pseudo-style on any element is a security/privacy issue, so you can't tell whether there's a spelling error or not. that doesn't apply here<br> <khush> q?<br> <miriam> ack fantasai<br> <TabAtkins> s/stefan/schenny/<br> <miriam> ack khush<br> <TabAtkins> khush: +1 to - i don't know what we did for ::part() so that might change - but +1 to idea that if the element wasn't even generated, just give an empty decl. no reason to compute style if the element doesnt' exist<br> <TabAtkins> khush: a lot of that is dependent on what class/name you've set up, other data only known when the transition si actually happening<br> <TabAtkins> khush: that bit that Tim raised, if you can't identify the pseudo uniquely<br> <TabAtkins> khush: then it's better to give no style than to try and guess which of the pseudos<br> <khush> ::view-transition-group(name.foo)<br> <noamr> q+<br> <TabAtkins> khush: in this selector, it's possible that the pseudo that corresponds to "name" doesn't have a .foo, so the selector doesn't match, but if you ask for gCS(..., "name.foo") it wouldn't mamke sense<br> <miriam> ack noamr<br> <TabAtkins> khush: so i think this shouldn't match<br> <fremy> q?<br> <fremy> q+<br> <emilio> ftr the discussion happened https://github.com/w3c/csswg-drafts/issues/2149#issuecomment-380386188 and wasn't ::part() but ::slotted()<br> <emilio> But we resolved that ::slotted() wouldn't work<br> <TabAtkins> noamr: I like that gCS just takes the actual ident, no arguments<br> <khush> +1 to noam's suggestion too.<br> <emilio> q+<br> <miriam> ack fremy<br> <TabAtkins> fremy: +1 to what Noam was saying<br> <miriam> ack emilio<br> <TabAtkins> emilio: that makes sense, if that has a uniquely identifiable set of styles<br> <TabAtkins> emilio: I just linked to the discussion i was remembering, it was about ::slotted(), same reasoning<br> <TabAtkins> emilio: We made this not work for ::slotted for the reasons given by elika and tab - there's no single element it represents, so this would be consistent<br> <TabAtkins> emilio: Between assuming specifying only the name is uniquely identifiable... i don't mind doing that *or* no VT at all.<br> <bramus> TabAtkins: if we want to reify this more structured, we need a plurality concept<br> <bramus> TabAtkins: if want to make plurar, then we can giv eyou list of pseudos<br> <miriam> q?<br> <emilio> s/plurar/plural<br> <TabAtkins> TabAtkins: so gCS() can query singular pseudos, but not plural ones<br> <bramus> s/plurar/plural/<br> <noamr> Proposed resolution: getComputedStyle only receives a name parameter, no classes or *, and matches an actual initialized vt pseudo<br> <khush> q?<br> <khush> q+<br> <miriam> ack khush<br> <TabAtkins> khush: We probably want to extend this to all script APIs - webanim has a similar API<br> <TabAtkins> miriam: with that clarification, sound reasonable?<br> <noamr> script APIs (getComputedStyle, WAAPI) only receives a name parameter, no classes or *, and matches an actual initialized vt pseudo<br> <fantasai> +1<br> <schenney> FYI gCS(id, :highlight(name) is how highlight work.<br> <TabAtkins> flackr: +1 to the updated proposal, doesn't make sense for element.animate() to affect multiple pseudos<br> <TabAtkins> RESOLVED: script APIs (getComputedStyle, WAAPI) only receives a name parameter, no classes or *, and matches an actual initialized vt pseudo<br> <TabAtkins> (noam will work with me/fantasai to make this more structured in the Pseudo spec)<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9880#issuecomment-1939408219 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Monday, 12 February 2024 19:30:39 UTC