[css-view-transitions-1][cssom] Clarify how getComputedStyle should be have with view-transition pseudo-elements

[noamr]

The current specified behavior in CSSOM re pseudo-elements is a bit vague: https://drafts.csswg.org/cssom/#extensions-to-the-window-interface

If pseudoElt is provided, is not the empty string, and starts with a colon, then:

1. Parse pseudoElt as a <pseudo-element-selector>, and let type be the result.
2. If type is failure, or is an ::slotted() or ::part() pseudo-element, let obj be null.
3. Otherwise let obj be the given pseudo-element of elt.

We should clarify what this mean for view-transition pseudo-elements?

• what happens when there is no active transition
• what happens with wildcards/classes

Current chromium implementation gives an actual value for pseudos with names but no *, and regardless of whether the transition is active. This seems a bit coincidental.

[nt1m]

Personally I think getComputedStyle() should just support the simple form of ::view-transition-group(name), not wildcards, not classes. It doesn't make sense IMO to get the computed style of something that isn't uniquely identifiable.

[nt1m]

what happens when there is no active transition

I think the answer to this is "what happens when you query the style for ::marker on an element that doesn't generate a marker" or similar situations with ::before / ::after / etc.

[noamr]

what happens when there is no active transition

I think the answer to this is "what happens when you query the style for ::marker on an element that doesn't generate a marker" or similar situations with ::before / ::after / etc.

Those are unspecified in the same way.
You can have a ::marker pseudo-element defined on any element, and it's not clear whether it should be resolved in getComputedStyle or only in e.g. li elements.
In all browser it does get currently resolves, which means that getComputedStyle applies to a hypothetical pseudo-element. Currently for view-transition pseudos that works but only for ident pseudos and not for * pseudos.

[css-meeting-bot]

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

The full IRC log of that discussion

<TabAtkins> noamr: gCS() has a second param of a pseudo-element name
<TabAtkins> noamr: in CSSOM it's not clear how this is suppsoed to behave
<TabAtkins> noamr: it says "get the element that is a pseudo" but that's vague
<TabAtkins> noamr: so what shoudl this return if there is no VT at all
<TabAtkins> noamr: but there is style for VT pseudos
<TabAtkins> noamr: one option is, there's no element here so it returns an empty style decl
<TabAtkins> noamr: Another is to say, yes but if there *was* one this is how it would be styled
<TabAtkins> noamr: it gets more complicated when VT classes are involved...
<TabAtkins> q+
<flackr> q+
<fremy> I don't think you can meaningfully compute that, since you don't know the classes and names
<TabAtkins> noamr: main thing about hypothetical route is that it does coincide with how it works on other pseudos
<TabAtkins> noamr: shoudl probably clarify that in CSSOM
<miriam> ack fantasai
<fantasai> https://github.com//issues/9880
<emilio> q+
<TabAtkins> fantasai: raising Tim's suggestion from the issue
<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
<TabAtkins> khush: so the name must be there. if there's *also* classes, and they don't match, what then?
<emilio> qq+
<TabAtkins> khush: today if you pass a class and id but those aren't being applied to th eelement, what happens?
<schenney> q+
<TabAtkins> emilio: I think we discussed this with ::part(), we might have a resolution on that
<miriam> ack emilio
<Zakim> emilio, you wanted to react to fantasai
<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
<TabAtkins> emilio: might be worth looking at that and seeing what we resolve
<flackr> q-
<khush> q+
<TabAtkins> fantasai: you haven't buil the tree yet so there's no order
<fantasai> scribe+
<emilio> ack emilio
<TabAtkins> emilio: if you haven't built it yet, you don't know what to style anyway
<miriam> ack TabAtkins
<fantasai> TabAtkins: I think the easiest answer...
<fantasai> ... we should check up on what we did for ::part, and be consistent
<fantasai> TabAtkins: I'm inclined to the "don't have it work, because doesn't uniquely identify a set of pseudos"
<fantasai> TabAtkins: In general pseudo-element treatment in CSSOM is somewhat nonsensical mishmash of stuff
<fantasai> TabAtkins: I don't think we need to try really hard to make this API work well
<miriam> ack schenney
<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
<khush> q?
<miriam> ack fantasai
<TabAtkins> s/stefan/schenny/
<miriam> ack khush
<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
<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
<TabAtkins> khush: that bit that Tim raised, if you can't identify the pseudo uniquely
<TabAtkins> khush: then it's better to give no style than to try and guess which of the pseudos
<khush> ::view-transition-group(name.foo)
<noamr> q+
<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
<miriam> ack noamr
<TabAtkins> khush: so i think this shouldn't match
<fremy> q?
<fremy> q+
<emilio> ftr the discussion happened https://github.com//issues/2149#issuecomment-380386188 and wasn't ::part() but ::slotted()
<emilio> But we resolved that ::slotted() wouldn't work
<TabAtkins> noamr: I like that gCS just takes the actual ident, no arguments
<khush> +1 to noam's suggestion too.
<emilio> q+
<miriam> ack fremy
<TabAtkins> fremy: +1 to what Noam was saying
<miriam> ack emilio
<TabAtkins> emilio: that makes sense, if that has a uniquely identifiable set of styles
<TabAtkins> emilio: I just linked to the discussion i was remembering, it was about ::slotted(), same reasoning
<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
<TabAtkins> emilio: Between assuming specifying only the name is uniquely identifiable... i don't mind doing that *or* no VT at all.
<bramus> TabAtkins: if we want to reify this more structured, we need a plurality concept
<bramus> TabAtkins: if want to make plurar, then we can giv eyou list of pseudos
<miriam> q?
<emilio> s/plurar/plural
<TabAtkins> TabAtkins: so gCS() can query singular pseudos, but not plural ones
<bramus> s/plurar/plural/
<noamr> Proposed resolution: getComputedStyle only receives a name parameter, no classes or *, and matches an actual initialized vt pseudo
<khush> q?
<khush> q+
<miriam> ack khush
<TabAtkins> khush: We probably want to extend this to all script APIs - webanim has a similar API
<TabAtkins> miriam: with that clarification, sound reasonable?
<noamr> script APIs (getComputedStyle, WAAPI) only receives a name parameter, no classes or *, and matches an actual initialized vt pseudo
<fantasai> +1
<schenney> FYI gCS(id, :highlight(name) is how highlight work.
<TabAtkins> flackr: +1 to the updated proposal, doesn't make sense for element.animate() to affect multiple pseudos
<TabAtkins> RESOLVED: script APIs (getComputedStyle, WAAPI) only receives a name parameter, no classes or *, and matches an actual initialized vt pseudo
<TabAtkins> (noam will work with me/fantasai to make this more structured in the Pseudo spec)

[noamr]

Speaking with @annevk and others, I think we reached the wrong conclusion.
For things like ::placeholder, getComputedStyle should return the style even if this is not an input element. View transition pseudos should behave the same: return the computed style of a view transition element as if it was there regardless of the state of the view transition itself.

[vmpstr]

What's the reasoning for this?

The difficulty here is that some of our view transition styles are conditional on the structure of the tree. For example, isolation is only set on the pair if it has two children. We can certainly just return something if you ask for the style of the pair but there is no view transition or that particular pair doesn't exist, but the choice of what to return depends on what the use case for this is.

[noamr]

What's the reasoning for this?

The difficulty here is that some of our view transition styles are conditional on the structure of the tree. For example, isolation is only set on the pair if it has two children. We can certainly just return something if you ask for the style of the pair but there is no view transition or that particular pair doesn't exist, but the choice of what to return depends on what the use case for this is.

The reasoning is that in current scenarios getComputedStyle is just about style computation and not about finding out information about the state of the pseudo-element you're requesting the style for.

[khushalsagar]

The difficulty here is that some of our view transition styles are conditional on the structure of the tree. For example, isolation is only set on the pair if it has two children.

The behaviour per spec is such that the static UA CSS rules here are always in the user agent origin. And the dynamic style sheet which has the tree structure dependent CSS won't be there if there is no transition. So we could compute the pseudo-element style based on that?