[css-view-transitions-2] CSSOM for CSSViewTransitionRule.navigation does not match implementation

[nt1m]

The spec defines it as:

readonly attribute ViewTransitionNavigation navigation;

and Blink has:

readonly attribute CSSOMString navigation;

This is actually visible on the web, and Blink's behavior is tested inside a WPT:

https://searchfox.org/wubkat/rev/b36cbce69fddb7da33823f316bd8ead5bebee970/LayoutTests/imported/w3c/web-platform-tests/css/css-view-transitions/navigation/at-rule-cssom.html#24

The test expects this attribute to be an empty string, which is not possible if you have enumerated values (ViewTransitionNavigation), the CSSOM would return none with the enum instead of an empty string in this case.

cc @noamr @khushalsagar @mattwoodrow @vmpstr

[noamr]

Thanks, filed https://issues.chromium.org/issues/356649890
If you get to this before us, feel free to change the WPT

[vmpstr]

Closing the issue as it sounds like it's just a Chromium bug. Feel free to reopen if I misunderstood

[noamr]

Actually I think this is debatable, we don't currently have at rules that use enums in that way, and usually CSSOM doesn't try to be fully type-safe in this way. e.g. if we add new navigation types and some browsers don't support them, this would interpret them as invalid rules rather than rules with empty navigation.

[nt1m]

Maybe @tabatkins or @fantasai has an opinion here (I really do not have a strong one for this). Aiming for consistency is best (whatever consistency is in this context)

[noamr]

OK reading https://drafts.csswg.org/css-counter-styles/#the-counter-style-rule:
"""
This at-rule conforms with the forward-compatible parsing requirement of CSS; conformant parsers that don’t understand these rules will ignore them without error. Any descriptors that are not recognized or implemented by a given user agent, or whose value does not match the grammars given here or in a future version of this specification, must be ignored in their entirety; they do not make the @counter-style rule invalid.
"""

I think that this should be the case for this rule as well, and we should change navigation to be a CSSOMString (like https://drafts.csswg.org/css-counter-styles/#the-csscounterstylerule-interface) that returns an empty string when there is no valid navigation rule, as per the current chromium implementation.

[css-meeting-bot]

The CSS Working Group just discussed [css-view-transitions-2] CSSOM for CSSViewTransitionRule.navigation does not match implementation, and agreed to the following:

• RESOLVED: navigation is a CSSOMString, it returns an empty string when navigation descriptor is missing or invalid

The full IRC log of that discussion

<bramus> noamr: looked at similar rules such as counterstyle. conistent to make this a CSSOMString
<bramus> is also what chrome’s implementation does, but spec says its an enum
<bramus> proposal to make it a CSSOMString that returns an emptry string when missing or having an invalid descriptor
<bramus> emilio: is it usefule to differentiate between missing auto or none?
<bramus> noamr: yes, very important for forwardcompat
<bramus> … if one browser adds another type that others dont have yet, then we want to see that there’s a difference between none or invalid
<bramus> emilio: but then you get auto behavior?
<bramus> noamr: no, the ?? is not read for purpose of nav
<bramus> … its a vt role without navigation descriptor and no initial value
<astearns> s/??/unknown value/
<bramus> … similar to having invalid rule
<bramus> emilio: ok, so it is a meaningful distinction
<ntim> q+
<bramus> … can consider making rule invalid alltogether
<bramus> noamr: want to keep consistent with StyleRule
<bramus> emilio: yes, if missing is relevant info then its fine to expose a string
<astearns> ack ntim
<bramus> ntim: how is it different from navigation none?
<bramus> noamr: auto vs invalid and then auto vs none
<bramus> … none would supersede auto
<bramus> … it has a meaing to not do a nav
<bramus> … while invalid is a no-op
<bramus> ntim: so none cancels the nav from the prev doc?
<bramus> noamr: yes
<bramus> astearns: other qs?
<bramus> … current wpt tests this behavior of CSSOMString?
<bramus> noamr: yes
<bramus> astearns: so proposed resolution is to change to CSSOMString that returns empty value when there is no ?? rule
<noamr> proposed resolution: navigation is a CSSOMString, it returns an empty string when navigation descriptor is missing or invalid
<bramus> RESOLVED: navigation is a CSSOMString, it returns an empty string when navigation descriptor is missing or invalid