Open noamr opened 7 months ago
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.
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.
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.
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
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.
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.
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.
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?
The current specified behavior in CSSOM re pseudo-elements is a bit vague: https://drafts.csswg.org/cssom/#extensions-to-the-window-interface
We should clarify what this mean for view-transition pseudo-elements?
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.