Re: [csswg-drafts] [css-conditional-3] Setting .conditionText interop is terrible (#6819)

The CSS Working Group just discussed `conditionText setter interop`, and agreed to the following:

* `RESOLVED: Make conditionText readonly`

<details><summary>The full IRC log of that discussion</summary>
&lt;emilio> topic: conditionText setter interop<br>
&lt;emilio> github: https://github.com/w3c/csswg-drafts/issues/6819<br>
&lt;emilio> fantasai: there's a lot of failures when I was testing this. Firefox was the most correct on @media but fails on @supports. WebKit / Blink doesn't support either<br>
&lt;emilio> ... do we want to file impl bugs or call them readonly?<br>
&lt;emilio> q+<br>
&lt;emilio> TabAtkins: I know setting media attributes on link is useful<br>
&lt;emilio> ... and used by some tooling<br>
&lt;emilio> ... so I think it's useful to continue supporting it<br>
&lt;emilio> ... but I wouldn't shed too many tears if we call it readonly<br>
&lt;fantasai> emilio: I'd like to say that making conditionalText in the OM is different from what tooling does changing medi aof link<br>
&lt;fantasai> emilio: latter depends on ... stylesheets<br>
&lt;fantasai> TabAtkins: I was talking about toggling an @media rule<br>
&lt;fantasai> emilio: But not supported by WebKit and Blink<br>
&lt;fantasai> TabAtkins: Toggling *conditionText* isn't supported. But toggling mediaText *is*, though essentially a synonym<br>
&lt;fantasai> emilio: The media attribute on link or style element toggles the DOM attribute<br>
&lt;fantasai> TabAtkins: not talking about that<br>
&lt;fantasai> TabAtkins: talking about @media rule<br>
&lt;fantasai> emilio: ah, ok, that's weird<br>
&lt;fantasai> TabAtkins: Jonathan Neal has exploited that to toggle entire sets of rules before<br>
&lt;fantasai> Rossen_: So if we move to resolve on making this readonly<br>
&lt;fantasai> Rossen_: would there be any objections to it?<br>
&lt;fantasai> fantasai: I suspect in either case we need changes in implementations<br>
&lt;fantasai> fantasai: just a question of which way we want to go<br>
&lt;oriol> q+<br>
&lt;emilio> ack emilio<br>
&lt;Rossen_> q?<br>
&lt;fantasai> Rossen_: Forcing a normative change here would be encouraging something to change<br>
&lt;emilio> ScribeNick: emilio<br>
&lt;fantasai> fantasai: I have a PR adding tests, just haven't merged because opened this issue<br>
&lt;oriol> Reconnecting headset<br>
&lt;emilio> ack oriol<br>
&lt;emilio> oriol: conditionText seems analogous to selectorText for style rules and that's not read-only<br>
&lt;emilio> ... in the past it was not interoperable but it got fixed<br>
&lt;fantasai> emilio: Counter-example, we made layerName readonly<br>
&lt;fantasai> emilio: and generally leaning towards making OM readonly<br>
&lt;emilio> ... so counter-examples in both directions which is not a great state of affairs<br>
&lt;emilio> Rossen: So options are leave as-is and hoping tests cause browsers to change<br>
&lt;emilio> ... or resolve on making read-only<br>
&lt;emilio> ... should we do a straw-poll?<br>
&lt;emilio> TabAtkins: I'd prefer to make stuff consistently mutable<br>
&lt;bradk> +1 As is, but encourage browsers to change<br>
&lt;fantasai> s/mutable/mutable, given this is analogous to existing htings which are mutable/<br>
&lt;TabAtkins> emilio: Making @supports mutable would be a change<br>
&lt;TabAtkins> emilio: @media dynamically changes but @supports doesn't currently<br>
&lt;smfr> q+<br>
&lt;futhark> Existing issue for Chrome: https://bugs.chromium.org/p/chromium/issues/detail?id=1210073<br>
&lt;emilio> emilio: so that might be why Firefox doesn't support mutating it. In general readonly is going to be easier to get interop on<br>
&lt;emilio> ... but not super-strong feelings either way<br>
&lt;emilio> ack bradk<br>
&lt;emilio> bradk: I think it should be mutable<br>
&lt;emilio> ack smfr<br>
&lt;emilio> smfr: from an implementor perspective we'd like to CSSOM be more readonly, we don't have many incentives to fix these bugs<br>
&lt;TabAtkins> I suppose the fact that @media *does* have the .media mutable means it's okay for the .conditionText to be a readonly version that covers everyone<br>
&lt;bradk> A<br>
&lt;fantasai> 0<br>
&lt;emilio> strawpol: A - as-is, B - read-only<br>
&lt;oriol> A<br>
&lt;florian> 0<br>
&lt;emilio> B<br>
&lt;smfr> B<br>
&lt;TabAtkins> B<br>
&lt;futhark> B<br>
&lt;miriam> 0<br>
&lt;dholbert> 0<br>
&lt;jensimmons> B<br>
&lt;astearns> 0<br>
&lt;jfkthame> 0<br>
&lt;bradk> I don’t feel super strongly about it<br>
&lt;lea> Α<br>
&lt;delan> 0<br>
&lt;TYLin> A<br>
&lt;Morgan> 0<br>
&lt;rachelandrew> B<br>
&lt;tantek> B until there's a use-case described (didn't see it)<br>
&lt;Rossen_> B<br>
&lt;castastrophe> A<br>
&lt;chris> 0<br>
&lt;lea> Reasoning: Readonly puts undue burden on authors when they need to modify these rules to make things easier for implementors<br>
&lt;emilio> RESOLVED: Make conditionText readonly<br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6819#issuecomment-1016695585 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Wednesday, 19 January 2022 17:25:52 UTC