Last Comment Bug 814907 - implement CSSGroupingRule and CSSConditionRule
: implement CSSGroupingRule and CSSConditionRule
Status: RESOLVED FIXED
: dev-doc-complete
Product: Core
Classification: Components
Component: CSS Parsing and Computation (show other bugs)
: Trunk
: All All
: -- normal (vote)
: mozilla20
Assigned To: Cameron McCormack (:heycam)
:
: Jet Villegas (:jet)
Mentors:
http://dev.w3.org/csswg/css3-conditio...
Depends on:
Blocks: 815021
  Show dependency treegraph
 
Reported: 2012-11-24 14:58 PST by Cameron McCormack (:heycam)
Modified: 2013-01-08 13:03 PST (History)
5 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
patch (23.53 KB, patch)
2012-11-24 15:58 PST, Cameron McCormack (:heycam)
no flags Details | Diff | Splinter Review
patch (v1.1) (23.67 KB, patch)
2012-11-25 20:05 PST, Cameron McCormack (:heycam)
bzbarsky: review+
Details | Diff | Splinter Review

Description Cameron McCormack (:heycam) 2012-11-24 14:58:12 PST

    
Comment 1 Cameron McCormack (:heycam) 2012-11-24 15:58:19 PST
Created attachment 684903 [details] [diff] [review]
patch

Note that I changed the serialisation of @-moz-document rules to remove an extra space after the condition.  I've left SetConditionText() unimplemented, like SetCssText() is.
Comment 2 Cameron McCormack (:heycam) 2012-11-25 20:05:47 PST
Created attachment 685019 [details] [diff] [review]
patch (v1.1)

Force @supports pref on in the test.
Comment 3 Boris Zbarsky [:bz] (still a bit busy) 2012-11-26 18:56:21 PST
Comment on attachment 685019 [details] [diff] [review]
patch (v1.1)

The XPIDL bits make me cry, but converting this to WebIDL is a fight for another day.

Please post to www-style requesting corresponding changes to CSSOM?

>+++ b/dom/interfaces/css/nsIDOMCSSGroupingRule.idl
>+ * Interface for at-rules in the CSS OM.

"at-rules that have child rules"

I'm trying to figure out the usefulness of conditionText if one gets it without checking what sort of condition rule one has.  It has pretty different behavior for @-moz-document and @supports, no?  What's the benefit of having a single interface that hands out strings that mean totally different things depending on which instance of the interface you have?

Apart from that this looks ok, but I'd like to understand the API design here.
Comment 4 Cameron McCormack (:heycam) 2012-11-26 19:02:42 PST
So these interface changes are already in the css3-conditional spec, I was just following them.  That conditionText should go on CSSConditionRule was a recent WG decision, I believe.

Whether having conditionText there and not individually on each of CSSMediaRule, CSSDocumentRule (when that goes into css4-conditional) and CSSSupportsRule, possibly with different names, is useful, I'm not sure.  (It might be useful for a style sheet editing UI that lets you double click to edit the condition?)  Maybe dbaron could say more.
Comment 5 Boris Zbarsky [:bz] (still a bit busy) 2012-11-26 19:13:26 PST
Comment on attachment 685019 [details] [diff] [review]
patch (v1.1)

Ah, ok.  If dbaron is already on board with the interface chnages, r=me
Comment 6 Cameron McCormack (:heycam) 2012-11-26 21:31:40 PST
https://hg.mozilla.org/integration/mozilla-inbound/rev/cb43db016af6

Note You need to log in before you can comment on or make changes to this bug.