The default bug view has changed. See this FAQ.

implement CSSSupportsRule::conditionText

ASSIGNED
Assigned to

Status

()

Core
CSS Parsing and Computation
ASSIGNED
5 years ago
4 years ago

People

(Reporter: heycam, Assigned: heycam)

Tracking

Trunk
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Assignee)

Description

5 years ago
The spec grew a conditionText IDL attribute on CSSSupportsRule.  That should be easy to expose since we already record it.
(Assignee)

Comment 1

5 years ago
I'm trying to implement the setter.  From inside CSSSupportsRule::SetConditionText, how do I get the document to restyle after I update the condition?
Status: NEW → ASSIGNED
QA Contact: cam
(Assignee)

Updated

5 years ago
Assignee: nobody → cam
QA Contact: cam
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?
(Assignee)

Comment 3

5 years ago
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?
(Assignee)

Comment 4

5 years ago
Sent mail to ask: http://lists.w3.org/Archives/Public/www-style/2012Aug/0131.html
(Assignee)

Comment 5

5 years ago
(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.
Depends on: 753517
(Assignee)

Comment 7

5 years ago
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.
(Assignee)

Comment 8

4 years ago
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?
(Assignee)

Comment 10

4 years ago
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.
(Assignee)

Comment 11

4 years ago
Just to confirm, if you assign "(color: green" to conditionText, this should throw, right?
Flags: needinfo?(dbaron)
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.)
Flags: needinfo?(dbaron)
(Assignee)

Comment 13

4 years ago
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?
Flags: needinfo?(dbaron)
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.
Flags: needinfo?(dbaron)
(Assignee)

Updated

4 years ago
Depends on: 914072
You need to log in before you can comment on or make changes to this bug.