Closed
Bug 780060
Opened 12 years ago
Closed 4 years ago
implement CSSSupportsRule::conditionText
Categories
(Core :: CSS Parsing and Computation, defect)
Core
CSS Parsing and Computation
Tracking
()
RESOLVED
FIXED
People
(Reporter: heycam, Assigned: heycam)
References
(Blocks 1 open bug)
Details
The spec grew a conditionText IDL attribute on CSSSupportsRule. That should be easy to expose since we already record it.
Assignee | ||
Comment 1•12 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•12 years ago
|
Assignee: nobody → cam
QA Contact: cam
Comment 2•12 years ago
|
||
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•12 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•12 years ago
|
||
Sent mail to ask: http://lists.w3.org/Archives/Public/www-style/2012Aug/0131.html
Assignee | ||
Comment 5•12 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.
Comment 6•12 years ago
|
||
Landed on inbound.
Assignee | ||
Comment 7•12 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•12 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•12 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•12 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•12 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)
Updated•8 years ago
|
Blocks: css-conditional-3
Assignee | ||
Comment 15•4 years ago
|
||
This was added some time ago.
Status: ASSIGNED → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•