The spec grew a conditionText IDL attribute on CSSSupportsRule. That should be easy to expose since we already record it.

I'm trying to implement the setter. From inside CSSSupportsRule::SetConditionText, how do I get the document to restyle after I update the condition?

Watch out for that "serializing" bit in the spec. Worth double-checking what that means in practice. As far as getting the document, you could steal the GetDocument stuff from https://bug753517.bugzilla.mozilla.org/attachment.cgi?id=637277 or I could just land the patch that's a part of, since it has reviews and all. Let me know?

It would probably be good if the spec said to trim the white space from the condition before returning it, just like it's trimmed when assigning. My serialized condition includes comments that appear just after the condition, but not any that appear between the "@supports" and the condition. Does that sound right?

Sent mail to ask: http://lists.w3.org/Archives/Public/www-style/2012Aug/0131.html

(In reply to Boris Zbarsky (:bz) [In and out Aug 1 - 10, out Aug 11-20] from comment #2) > As far as getting the document, you could steal the GetDocument stuff from > https://bug753517.bugzilla.mozilla.org/attachment.cgi?id=637277 or I could > just land the patch that's a part of, since it has reviews and all. Let me > know? If you can land the patch that sounds good to me.

Landed on inbound.

Thanks. From http://lists.w3.org/Archives/Public/www-style/2012Aug/thread.html#msg131 it looks like serialization based on the token stream rather than the input source string is what people want. But I think I'll wait until the spec is clearer about the exact serialization before making any changes.

I posted a patch in bug 814907 that includes an implementation of conditionText for @supports rules. I still don't see any definition of exact serialisation in the spec; that patch just uses the same string that is included in the middle of cssText, i.e. the exact string that was in the style sheet between "@supports" and "{", with white space trimmed off both ends.

http://dev.w3.org/csswg/css3-conditional/#the-csssupportsrule-interface says: The conditionText attribute (defined on the CSSConditionRule parent rule), on getting, must return the condition that was specified, without any logical simplifications, so that the returned condition will evaluate to the same result as the specified condition in any conformant implementation of this specification (including implementations that implement future extensions allowed by the general_enclosed exensibility mechanism in this specification). In other words, token stream simplifications are allowed (such as reducing whitespace to a single space or omitting it in cases where it is known to be optional), but logical simplifications (such as removal of unneeded parentheses, or simplification based on evaluating results) are not allowed. So what needs to happen for this bug?

If token stream simplifications are allowed by not required, then we don't need to do anything for getting, but we still need to implement setting it.

Just to confirm, if you assign "(color: green" to conditionText, this should throw, right?

According to http://dev.w3.org/csswg/css3-conditional/#cssconditionrule it shouldn't. But if you think it should, it's worth raising as an issue on www-style. (I don't have much of an opinion, although I am slightly inclined towards thinking it should throw. Tab wrote that part of the spec, I think.)

Oh right. I asked the wrong question then. I should have asked: if you assign "(color: green" to conditionText, this will result in nothing being done, right? And that's because it doesn't match the grammar for supports_condition. On the other hand, CSS.supports() says to parse its argument as a supports_condition, which I take to mean that the regular CSS parser inference of missing closing parentheses at the end of input happens. Am I interpreting correctly?

I don't think that difference was intended. I think the parsing rules should be assumed to be the same, and following normal CSS rules in both cases. And we should probably fix the spec.