Re: [csswg-drafts] [css-pseudo-4] Custom state pseudo class proposal (#4805)

Web Components f2f minutes here: https://github.com/WICG/construct-stylesheets/issues/45#issuecomment-602756608

Overall there's consensus on implementing `document.adoptedStyleSheets` as an `ObservableArray`.

There also appears to be consensus on moving `document.styleSheets` to a (readonly) `ObservableArray` subclass, so it'll sprout the same array methods.

The contentious question that couldn't be resolved on the call, and which is being left for us to decide, is whether direct assignment of an array is allowed; that is, whether `document.aSS = [ss1, ss2];` works or throws.

Points in favor:
* Other mutating list-like APIs on the platform allow direct assignment, or plan to: `el.classList` allows it; Typed OM array-likes intend to allow it; various CSSOM APIs (`CSSMediaRule.media` and `CSSStyleRule.style` effectively allow it, via their `[PutForwards]` extended attributes that allow setting to a string to replace the associated lists).
* Seems weird to disallow direct setting, when there are other ways to replace the entire array (calling `.splice()`, or emptying the array and then `.push()`ing). Complex restrictions seem bad without strong reasons for them, as it means authors have to learn a more complex API boundary and can't rely on knowledge from elsewhere.

Points against:
* When subclassing a custom element, setting an array assumes that the superclass hasn't set any stylesheets itself; if it has, and you weren't aware of this, the subclass setting an array will wipe out the superclass's sheets. If the subclass instead just always used `.push()`, it wouldn't clobber anything.
* The setter will consume the array, not use it; `document.aSS` will have equal *contents* to the array you set, but not equal *identity* (it'll return an ObservableArray object, not the iterable the author assigned). This is distinct from how userland array-valued properties tend to work, and might be weird.

----

I'm at this point strongly on the "assignment should be allowed" camp. In particular, the first point against was most vociferously argued, and I think it's absolutely something we should reject.  The footgun **is not** "clobbering the superclass's styles", it's subclassing at all. It is exactly as dangerous to naively clobber the superclass's styles as it is to naively append to the superclass's (unknown) styles; both are equally likely to screw up your component with parts not getting the styles they expected.

In addition, this problem is common to *every single aspect of the superclass*, not just styles. Literally *anything* the subclass does might, if it's not aware of what the superclass is doing, screw up what the superclass is doing. Adding a special-case restriction to try and make subclasses less likely to screw up *this specific case* won't materially improve the situation. Even if it *weren't* the case that I think `.push()`ing is just as dangerous (so there's *no way* to reduce the risk anyway), increasing the complexity of the overall API surface for an insignificant improvement in safety is generally a bad tradeoff, I believe. We've made the judgement that similar sorts of tradeoffs aren't worthwhile elsewhere in CSS.

------

So anyway, Agenda+ to get a final decision on this. I secured a promise from Apple to ensure a relevant person attends the CSSWG call, so hopefully this can be bumped for this week's agenda?

-- 
GitHub Notification of comment by tabatkins
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4805#issuecomment-602779436 using your GitHub account

Received on Monday, 23 March 2020 18:30:16 UTC