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.

(Note that the implementation would be quite easy since it would share almost all its code with the implementation of @media.)

Another possible syntax: @location url(http://bugzilla.mozilla.org/), url-start(http://bugzilla.mozilla.org/show_bug.c) { body { background: yellow; color: black; } }

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.

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).

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.

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 ;)

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*"'.

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.

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

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/*") { // ... }

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?)

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) { /* ... */ }

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.)

Any thoughts on whether url-prefix() or url-start() or something else is better?

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.

(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?

(In reply to comment #19) > Are we still allowing magicalness with the asterisk on these? No.

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.

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

(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.)

+ * example: make search fields on www.mozilla.org white-on-black The example makes it black-on-white, not white-on-black.

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.

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

Does this have a corresponding Firefox bug?

Not needed, FireFox is build from branch which now supports this feature. I guess FireFox 1.1 will have it.

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.

Why not add this very useful tweak to Aviary? Is it somehow dangerous?

It's a pretty large change that also affects @media and some other things.

Link in comment 27 was somehow superceded by http://lists.w3.org/Archives/Public/www-style/2004Aug/0135.html

*** Bug 41975 has been marked as a duplicate of this bug. ***

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