Last Comment Bug 238099 - (@-moz-document) implement at-rule for matching on site/document URL
(@-moz-document)
: implement at-rule for matching on site/document URL
Status: RESOLVED FIXED
: css-moz
Product: Core
Classification: Components
Component: CSS Parsing and Computation (show other bugs)
: Trunk
: All All
: P1 enhancement with 6 votes (vote)
: Future
Assigned To: David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch)
: Hixie (not reading bugmail)
Mentors:
http://lists.w3.org/Archives/Public/w...
: 41975 (view as bug list)
Depends on: 945302
Blocks: 41975
  Show dependency treegraph
 
Reported: 2004-03-20 10:04 PST by David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch)
Modified: 2014-05-09 12:23 PDT (History)
48 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
work in progress (54.78 KB, patch)
2004-06-30 16:06 PDT, David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch)
no flags Details | Diff | Review
patch (54.59 KB, patch)
2004-07-01 15:24 PDT, David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch)
no flags Details | Diff | Review
work in progress (70.46 KB, patch)
2004-07-28 15:55 PDT, David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch)
no flags Details | Diff | Review
patch (70.34 KB, patch)
2004-07-28 17:19 PDT, David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch)
no flags Details | Diff | Review
patch (103.96 KB, patch)
2004-07-29 16:10 PDT, David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch)
bzbarsky: review+
bzbarsky: superreview+
Details | Diff | Review
patch (104.85 KB, patch)
2004-08-04 16:55 PDT, David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch)
no flags Details | Diff | Review
patch (104.36 KB, patch)
2004-08-05 02:17 PDT, David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch)
no flags Details | Diff | Review

Description David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2004-03-20 10:04:32 PST
An at-rule that scopes rules to a set of pages based on URL would be useful for
user stylesheets.  See proposal in
http://lists.w3.org/Archives/Public/www-style/2003Dec/0058.html and also bug
237478 comment 7.

It may be a requirement that it be possible to do both prefix matching and exact
matching of the URL.
Comment 1 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2004-03-20 10:05:25 PST
(Note that the implementation would be quite easy since it would share almost
all its code with the implementation of @media.)
Comment 2 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2004-03-20 10:07:51 PST
Another possible syntax:

@location url(http://bugzilla.mozilla.org/),
          url-start(http://bugzilla.mozilla.org/show_bug.c) {

  body { background: yellow; color: black; }

}
Comment 3 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2004-03-25 15:59:07 PST
Now I think I prefer @document to @location.  Also, rather than url() and
url-start(), it could take a string, and if the last character in the string is
'*' then it could be magical.
Comment 4 Vidar Haarr (not reading bugmail) 2004-04-19 13:58:14 PDT
How about just using CSS selector syntax for it?

Like:
document[uri*="bugzilla.mozilla.org"] {}
document[uri$="advertisement/"] {}
document[uri="http://bugzilla.mozilla.org/show_bug.cgi?id=238099"] {}

Then we would benefit from any potentially added selector syntax rules in the
future (i.e. regexp and possibly others).
Comment 5 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2004-04-19 14:39:02 PDT
Because there's no "document" element and there's no "uri" attribute, normally.
 But there could be.

Also, because you'd often want more than one rule to apply to the URL.
Comment 6 Vidar Haarr (not reading bugmail) 2004-04-20 01:10:01 PDT
I'm not sure it matters at all, but this was copied from the CSS2 spec (I didn't
check the CSS3 spec):
<http://www.w3.org/TR/REC-CSS2/syndata.html#at-rules>
"CSS2 user agents must ignore any '@import' rule that occurs inside a block or
that doesn't precede all rule sets."

So this basically means that if an at-rule was implemented for this, they could
only be specified at the top of userContent.css ?

I know that neither the document "element" or the uri "attribute" exists - I
thought perhaps it'd be possible to expose "virtual" elements? Could it perhaps
be possible to expose the URI attribute to the HTML element instead? Then you'd
have the entire DOM tree defined already, without needing to discuss what should
be the child of @location or document, for example.

> Also, because you'd often want more than one rule to apply to the URL.
I'm not sure I understand?

Anyway, I'm just pouring out thoughts here - it's just my .2 NOK ;)
Comment 7 Anne (:annevk) 2004-04-20 05:11:19 PDT
Difference:

  document[uri="http://bugzilla.mozilla.org"] html{ background:green; }
  document[uri="http://bugzilla.mozilla.org"] body{ background:lime;  }

  @document "http://bugzilla.mozilla.org"{
   html{ background:green; }
   body{ background:lime;  }
  }

The more rules, the better @document is. Note that the syntax of at-rules can be
changed, so that "URI-matching" is made possible. Like '@document "*contact*"'.
Comment 8 Vidar Haarr (not reading bugmail) 2004-04-20 06:44:45 PDT
d'oh, thanks for making that clear, Anne :)
So would these be possible?

@document "*bugzilla*":not("id=238099") {
  // select every bugzilla page in the world except that bug
  // I'm not even sure this is valid :not syntax :)
}

@document "http://", @document ("https://mywebpage.com") {
  // select http:// and mywebpage.com, but not other https sites
}

I'm sorry about the SPAM. I probably should've asked this on irc.mozilla.org, or
read some documentation.
Comment 9 Mano (::mano, needinfo? for any questions; not reading general bugmail) 2004-06-05 05:43:19 PDT
URIid is a very nice workaround for this bug, but it handles sites onl by their
main URL

http://extensionroom.mozdev.org/more-info/uriid
Comment 10 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2004-06-30 16:06:11 PDT
Created attachment 152066 [details] [diff] [review]
work in progress
Comment 11 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2004-07-01 15:24:04 PDT
Created attachment 152145 [details] [diff] [review]
patch

This works.  I just need to figure out what the right syntax and behavior is --
I'm not sure I like this (which is, making "*" at the end magical):

@-moz-document url("http://www.mozilla.org/docs/") {
  // ...
}

@-moz-document url("http://www.mozilla.org/*") {
  // ...
}
Comment 12 Hixie (not reading bugmail) 2004-07-02 01:31:39 PDT
Does that mean I have to say:

   @-moz-document url(http://www.mozilla.org/*) { ... }
   @-moz-document url(http://mozilla.org/*) { ... }

...to style all the pages on mozilla.org's primary site? (i.e. is there no
domain-suffix style matching?)
Comment 13 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2004-07-27 18:47:13 PDT
I'm now leaning away from regexps, since the escaping would be a mess, e.g.
url(http://.*\\.mozilla\\.org/.*).  I think I want three functions:
domain(mozilla.org)
 - matches any URL whose hostname is "mozilla.org" or ends with ".mozilla.org"
url-prefix(http://www.mozilla.org/docs/)
 - matches any URL beginning with "http://www.mozilla.org/docs/"
url(http://www.mozilla.org/)
 - matches "http://www.mozilla.org/"

and I probably want to allow multiple functions per rule, e.g.:

@-moz-document url-prefix(http://www.mozilla.org/docs/),
               domain(developer.mozilla.org) {
  /* ... */
}
Comment 14 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2004-07-28 15:55:48 PDT
Created attachment 154597 [details] [diff] [review]
work in progress
Comment 15 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2004-07-28 17:19:26 PDT
Created attachment 154603 [details] [diff] [review]
patch

This works with the test user sheet:

@-moz-document domain(mozilla.org) {
  * { background: aqua ! important; }
}
									       

@-moz-document url-prefix(http://www.mozilla.org/) {
  * { background: green ! important; }
}
									       

@-moz-document url(http://www.mozilla.org/), domain(foo.bar) {
  * { background: yellow ! important; }
}


The @import rule parsing changes are at this point unrelated to this bug, but I
decided I like them anyway.  (In the older versions of the patch it allowed me
to share some additional code for parsing the url() function.)
Comment 16 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2004-07-29 01:22:37 PDT
Any thoughts on whether url-prefix() or url-start() or something else is better?
Comment 17 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2004-07-29 16:10:52 PDT
Created attachment 154706 [details] [diff] [review]
patch
Comment 18 Hixie (not reading bugmail) 2004-07-29 17:26:46 PDT
Pity the strings are hard-coded in so many places, but I guess that's the way 
most of the style system is done.

This should probably be documented somewhere when you check it in.

I like the three functions idea. Seems pretty reasonable.
Comment 19 David House 2004-08-03 01:17:18 PDT
(In reply to comment #13)
> I'm now leaning away from regexps, since the escaping would be a mess, e.g.
> url(http://.*\\.mozilla\\.org/.*).  I think I want three functions:
> domain(mozilla.org)
>  - matches any URL whose hostname is "mozilla.org" or ends with ".mozilla.org"
> url-prefix(http://www.mozilla.org/docs/)
>  - matches any URL beginning with "http://www.mozilla.org/docs/"
> url(http://www.mozilla.org/)
>  - matches "http://www.mozilla.org/"

Are we still allowing magicalness with the asterisk on these?
Comment 20 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2004-08-03 01:45:52 PDT
(In reply to comment #19)
> Are we still allowing magicalness with the asterisk on these?

No.
Comment 21 Boris Zbarsky [:bz] (Out June 25-July 6) 2004-08-04 14:08:42 PDT
Comment on attachment 154706 [details] [diff] [review]
patch

>Index: dom/public/nsIDOMClassInfo.h

>@@ -145,24 +145,25 @@ enum nsDOMClassInfoID {
>   eDOMClassInfo_CSSMediaRule_id,
>+  eDOMClassInfo_CSSMozDocumentRule_id,

This should go at the end of the ID list (see
http://lxr.mozilla.org/seamonkey/source/dom/public/nsIDOMClassInfo.h#195 )

>Index: content/html/style/src/nsCSSParser.cpp
>+PRBool CSSParserImpl::ParseGroupRule(nsresult& aErrorCode,

>+      REPORT_UNEXPECTED_EOF(NS_LITERAL_STRING("end of @media rule"));

s/@media/group/

>+      SkipAtRule(aErrorCode); // @media cannot contain @rules

s/@media/group rules/

>+// Parse a @-moz-document rule.
>+PRBool CSSParserImpl::ParseMozDocumentRule(nsresult& aErrorCode,

Would be nice to give a short syntax summary for @-moz-document before the
function, so it's clear what we're implementing.

>Index: content/html/style/src/nsCSSRules.cpp
>+nsCSSGroupRule::nsCSSGroupRule(const nsCSSGroupRule& aCopy)
>+  : nsCSSRule(aCopy)
>+  , mRuleCollection(aCopy.mRuleCollection)

That's wrong.  Different rules should have different mRuleCollection pointers,
since the rule collection has a pointer to the rule.  This should just be
setting mRuleCollection to null so it'll get lazily created when it's needed.

>-      mRules->EnumerateForwards(SetParentRuleReference,
>-                                NS_STATIC_CAST(nsICSSGroupRule*, this));
>+      mRules->EnumerateForwards(SetParentRuleReference, this);

I believe this is also wrong.  This will cast "this" to void*, then cast back
to nsICSSGroupRule in SetParentRuleReference.  But nsICSSGroupRule is not the
first class this inherits from, so we run into issues (see bug 170699, in
fact).

>+nsCSSGroupRule::InsertStyleRulesAt(PRUint32 aIndex, nsISupportsArray* aRules)

>-  aRules->EnumerateForwards(SetParentRuleReference,
>-                            NS_STATIC_CAST(nsICSSGroupRule*, this));
>+  aRules->EnumerateForwards(SetParentRuleReference, this);

Same issue here.

>+NS_IMPL_ADDREF_INHERITED(nsCSSMediaRule, nsCSSRule)
>+NS_IMPL_RELEASE_INHERITED(nsCSSMediaRule, nsCSSRule)

That should use nsCSSGroupRule, not nsCSSRule, no?  (I realize the latter is
what actually implements the addref at the moment, but nevertheless.)

>+nsCSSDocumentRule::nsCSSDocumentRule(void)

This should set mURLs to nsnull.

>+NS_IMPL_ADDREF_INHERITED(nsCSSDocumentRule, nsCSSRule)
>+NS_IMPL_RELEASE_INHERITED(nsCSSDocumentRule, nsCSSRule)

Again, s/nsCSSRule/nsCSSGroupRule/

r+sr=bzbarsky with the above issues fixed.
Comment 22 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2004-08-04 16:55:49 PDT
Created attachment 155219 [details] [diff] [review]
patch

This is revised according to the comments, except:
 * I made mURLs an nsAutoPtr
 * I put the new id before the SVG ifdef and changed the comment in
   nsIDOMClassInfo
 * I changed SetParentRuleReference to cast to nsCSSGroupRule instead of
   nsICSSGroupRule
Comment 23 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2004-08-04 17:47:12 PDT
(In reply to comment #21)
> >+NS_IMPL_ADDREF_INHERITED(nsCSSMediaRule, nsCSSRule)
> >+NS_IMPL_RELEASE_INHERITED(nsCSSMediaRule, nsCSSRule)
> 
> That should use nsCSSGroupRule, not nsCSSRule, no?  (I realize the latter is
> what actually implements the addref at the moment, but nevertheless.)

Actually, that doesn't compile, since the methods are ambiguous on
nsCSSGroupRule.  (And that's fine, since as long as AddRef is all forward to the
same thing, everything is fine.)
Comment 24 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2004-08-05 02:17:29 PDT
Created attachment 155257 [details] [diff] [review]
patch
Comment 25 Jesse Ruderman 2004-08-10 21:55:06 PDT
+ * example: make search fields on www.mozilla.org white-on-black

The example makes it black-on-white, not white-on-black.
Comment 26 MW 2004-08-13 13:43:01 PDT
I'm not sure if my comment should be filed as a  bug/rfe seperately. If so,
please let me know. 

If site-specific rules are applied to current tab content, then perhaps that
should trigger FF Style-Switcher icon. Furthermore whenever userContent.css
entries have modified current tab content, the Style-Switcher icon should be
triggered. The icon could then have an option to View content with/without
applying the site-specific rules/userContent.css rules.
Comment 27 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2004-08-19 15:01:48 PDT
Fix checked in to trunk, 2004-08-05 11:26 -0700.

I also posted to www-style about this:
http://lists.w3.org/Archives/Public/www-style/2004Aug/0134.html
Comment 28 Jon Hall 2004-08-24 05:12:57 PDT
Does this have a corresponding Firefox bug?
Comment 29 Anne (:annevk) 2004-08-24 06:14:50 PDT
Not needed, FireFox is build from branch which now supports this feature. I
guess FireFox 1.1 will have it.
Comment 30 Asa Dotzler [:asa] 2004-08-24 07:04:18 PDT
To follow up and clarify what Anne said, this doesn't require a Firefox bug
because it's a gecko feature, not an application level feature so all of the
gecko-based products pick this up for free.  This change didn't and won't land
on the Aviary branch from which the Firefox and Thunderbird 1.0 releases will
happen so you won't get this feature in those releases. You should be able to,
however, get this feature in Firefox today if you're using trunk builds. 
Comment 31 junk 2004-08-25 04:35:58 PDT
Why not add this very useful tweak to Aviary? Is it somehow dangerous?
Comment 32 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2004-08-25 10:25:12 PDT
It's a pretty large change that also affects @media and some other things.
Comment 33 Felix Miata 2004-12-07 02:31:28 PST
Link in comment 27 was somehow superceded by
http://lists.w3.org/Archives/Public/www-style/2004Aug/0135.html
Comment 34 Vidar Haarr (not reading bugmail) 2005-09-15 09:34:20 PDT
*** Bug 41975 has been marked as a duplicate of this bug. ***
Comment 35 Jan Steffen 2007-01-04 10:28:10 PST
nested @-rules don't work (tested in Firefox 2.0)
> @-moz-document domain(mozilla.com)
> {
>     @media print {some_rules..;}
> }

Is this a mozilla bug or invalid CSS?
That would be nice for site specific print styles.
For a workaround see http://groups.google.com/group/mozilla.web-developers.css/msg/15d9c465eb778ea

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