[css-view-transitions] Make CSSOM interface read-only

[emilio]

I think we have a resolution to make new OM interfaces read-only somewhere, but I couldn't find it. #6819 / #7033 (comment) etc are pointers tho...

In any case, any strong reason to make https://drafts.csswg.org/css-view-transitions-2/#navgation-behavior-rule-interface writeable? If not, could we just make it read-only?

cc @nt1m @noamr @tabatkins

[francescorn]

This is the resolution for making OM interfaces read-only: #7850

[noamr]

This is the resolution for making OM interfaces read-only: #7850

This seem to be about nested media-queries... am I missing something?

[noamr]

I think we have a resolution to make new OM interfaces read-only somewhere, but I couldn't find it. #6819 / #7033 (comment) etc are pointers tho...

In any case, any strong reason to make https://drafts.csswg.org/css-view-transitions-2/#navgation-behavior-rule-interface writeable? If not, could we just make it read-only?

cc @nt1m @noamr @tabatkins

It would be a (minor) shame to make them readonly. e.g. CSSViewTransitionRule.typeList is a DOMTokenList which has toggle etc. If this is the way we're going this is not a strong opposition but I'd like to see a clear resolution about this.

[khushalsagar]

I'm ok with making this read only given the recent resolution to add mutable types to the VT object: https://drafts.csswg.org/css-view-transitions-2/#dom-viewtransition-typelist.

The recommended pattern if authors need to set type per navigation would be to use this in pageswap/pagereveal.

[css-meeting-bot]

The CSS Working Group just discussed [css-view-transitions] Make CSSOM interface read-only, and agreed to the following:

• RESOLVED: Make CSSViewTransitionRule readonly
• RESOLVED: Change use of DOMTokenList to something more appropriate for readonly interfaces

The full IRC log of that discussion

<fantasai> emilio: We generally had resolved to make a buch of new CSSOM interfaces read-only
<fantasai> emilio: ViewTransition had a weird DomTokenList thing
<fantasai> emilio: I think we resolved to do dynaic changes in a different way? If so I would prefer if it was read-only.
<vmpstr> q+
<iank_> q-
<ntim> q+
<astearns> ack vmpstr
<fantasai> vmpstr: We've made the types mutable via ViewTransition object
<khush_> +1
<fantasai> vmpstr: so I don't think we need to make the interface writeable, so support change to readonly
<bramus> +1
<fantasai> astearns: Other comments/concerns with making readonly?
<fantasai> ntim: Does this affect anything in View Transitions L1
<fantasai> ntim: curious if it affects existing implementations
<fantasai> ?: This is for opt-in for cross-document transitions, so L2 only
<fantasai> ntim: ok
<fantasai> emilio: what interface does the CSS rule implement in L1?
<fantasai> ?: It has an IDL retrieved via API call. There's no CSS at-rule.
<vmpstr> s/?/vmpstr/
<fantasai> s/?/vmpstr/
<fantasai> emilio: Also DOMTokenList should probably be a FrozenArray or something
<ntim> I removed the css-view-transitions-1 label from the issue :)
<fantasai> PROPOSED: Make CSSViewTransitionRule readaonly
<fantasai> s/aonly/only/
<fantasai> astearns: any objections?
<fantasai> RESOLVED: Make CSSViewTransitionRule readonly
<fantasai> astearns: Should we try resolution for changing DOMTokenList?
<fantasai> fantasai: we can at least resolve that it needs to change
<fantasai> PROPOSED: Change use of DOMTOkenList to something more appropriate for readonly interfaces
<fantasai> RESOLVED: Change use of DOMTokenList to something more appropriate for readonly interfaces

[cdoublev]

If I am not mistaken, CSSViewTransitionRule attributes can still be re-assigned if they are not readonly. Is it an oversight?

csswg-drafts/css-view-transitions-2/Overview.bs

Lines 423 to 424 in 6e7ae33

	attribute ViewTransitionNavigation navigation;
	attribute CSSViewTransitionTypeSet types;

[noamr]

If I am not mistaken, CSSViewTransitionRule attributes can still be re-assigned if they are not readonly. Is it an oversight?

csswg-drafts/css-view-transitions-2/Overview.bs

Lines 423 to 424 in 6e7ae33

	attribute ViewTransitionNavigation navigation;
	attribute CSSViewTransitionTypeSet types;

Yes, thanks for catching all these!

[emilio]

@noamr it seems a readonly FrozenArray<CSSOMString> rather than a new CSSViewTransitionTypeSet would perhaps be less code / less special?

[noamr]

@noamr it seems a readonly FrozenArray<CSSOMString> rather than a new CSSViewTransitionTypeSet would perhaps be less code / less special?

I'm also OK with that, though there is precedent for those readonly setlikes, e.g. GPUSupportedFeatures, and it seems more "correct" in a way to represent this as a set.
This is an open issue (#10114) and is on the agenda for the next CSSWG call.

[emilio]

@noamr Is there any de-duplication going on during parsing or what not if you specify the same name twice? If not (and that is uncommon), it's more of an array than a set...

[noamr]

@noamr Is there any de-duplication going on during parsing or what not if you specify the same name twice? If not (and that is uncommon), it's more of an array than a set...

Yea, it should appear as a unique-only set in CSSOM, there should be deduping when creating that set by the parser

[noamr]

Reopening for setting the attribute to readonly