[css-conditional-3] Setting .conditionText interop is terrible

[fantasai]

The CSS Conditional Rules spec specifies that conditionText can be set, and if it is grammatical, updates the condition applied to the CSSConditionRule to which it applies.

So far, Firefox mostly supports this correctly on CSSMediaRules, and mostly fails on CSSSupportsRule; and neither Blink nor WebKit seem to support setting conditionText at all. See testcase Do we want to file bugs, or redefine conditionText as readonly?

[Loirooriol]

I think this should be consistent with CSSStyleRule's selectorText. I remember getting frustrated at some point because that was readonly on Firefox, but later it got fixed.

[tabatkins]

Being able to update the condition for a rule is somewhat useful for tools today, as you can use it to toggle entire blocks of rules easily by just setting the condition to something that's always-true or always-false. Ultimately we want to solve this use-case better with custom MQs, but given that setting the conditionText does work in at least some places today, I think it's reasonable to preserve that if possible.

[css-meeting-bot]

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

• RESOLVED: Make conditionText readonly

The full IRC log of that discussion

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

[svgeesus]

Fixed by 6c659d6

[cdoublev]

I think the following sentence should be removed in 7.3. The CSSMediaRule interface:

Setting the conditionText attribute must set the media.mediaText attribute on the rule.