Last Comment Bug 349813 - Make a way for site (-moz-document) rules to apply on sites *not* matching a URL/prefix/domain
: Make a way for site (-moz-document) rules to apply on sites *not* matching a ...
Status: NEW
Product: Core
Classification: Components
Component: CSS Parsing and Computation (show other bugs)
: Trunk
: All All
-- enhancement with 27 votes (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
: Jet Villegas (:jet)
Depends on:
Blocks: 423985
  Show dependency treegraph
Reported: 2006-08-22 18:38 PDT by Jason Barnabe (np)
Modified: 2016-10-19 08:54 PDT (History)
26 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

wip (8.92 KB, patch)
2006-08-27 22:56 PDT, Mats Palmgren (:mats)
no flags Details | Diff | Splinter Review
wip2 (9.98 KB, patch)
2006-09-10 11:04 PDT, Mats Palmgren (:mats)
no flags Details | Diff | Splinter Review
updated Mats' patch to work with current trunk. (8.68 KB, patch)
2007-06-02 23:21 PDT, Cédric "chewey" Menge
dbaron: review-
dbaron: review-
Details | Diff | Splinter Review

Description User image Jason Barnabe (np) 2006-08-22 18:38:54 PDT
A common request I've heard regarding user stylesheets is to have the ability to key on all URLs except specific ones, for example, to style all sites except for Google. Also, this could be useful for web designers who want most of their site styles one way, and certain special pages another.

I'm not going to try to propose a syntax, but a combination of the current syntax and CSS :not seems logical to me.
Comment 1 User image Mats Palmgren (:mats) 2006-08-27 22:56:23 PDT
Created attachment 235706 [details] [diff] [review]

This patch extends the @-moz-document syntax so you can now wrap the
function in an optional :not(), like so:

Nesting is not allowed, this is intentional, eg :not(:not(url(...))) is
a syntax error.

David, besides the syntax, is this something you think is a good feature
at all?
Comment 2 User image Jason Barnabe (np) 2006-08-28 10:11:05 PDT
Does that patch allow for something like this:

@-moz-document domain(""):not(domain(""))

which would match everything in except for the things in Or does it simply allow you to do this

@-moz-document :not(domain(""))

which would match all non-bugzilla pages?
Comment 3 User image Mats Palmgren (:mats) 2006-09-10 11:02:45 PDT
(In reply to comment #2)
> Does that patch allow for something like this:
> @-moz-document domain(""):not(domain(""))

No it doesn't, but I agree that combining them as you suggest
is much more useful.
Comment 4 User image Mats Palmgren (:mats) 2006-09-10 11:04:40 PDT
Created attachment 237625 [details] [diff] [review]

This patch adds the feature suggested by Jason. It allows an arbitrary
number of :not()s to be combined (logical AND) with the existing functions.
Or more formally, it extends the current syntax
to be:

docrule ::= "@-moz-document" S+ url-list "{" S* ruleset* "}"

url-list ::= url-item ( "," S* url-item )*

url-item ::= url-expr ( not-list )* | not-list

not-list ::= not-expr ( not-expr )*

not-expr ::= ":not(" S* url-expr ")" S*

url-expr ::= ( "url(" | "url-prefix(" | "domain(" ) URL ")" S*
Comment 5 User image Micah Bucy 2006-11-14 01:35:11 PST
Well, this seems the most appropriate place for my feature request considering the similarity.

I would suggest the ability to have wildcards in the @-moz-document url(

For an example of where this would be useful.
Deviant art user pages.  Each user gallery is set up exactly the same and the way they are distinguished via url is, but considering the number of users out there, it would be problematic to do this url by url.  

Something like 
@-moz-document url(http://* 
would solve this quite nicely.  So I suppose it would be a combination of domain( and the path that follows it.  Maybe syntax could be 
then likewise there could be
Comment 6 User image Mats Palmgren (:mats) 2006-11-14 02:01:49 PST
(In reply to comment #5)
Please file it as a separate enhancement request.
Comment 7 User image Cédric "chewey" Menge 2007-06-02 23:21:41 PDT
Created attachment 267038 [details] [diff] [review]
updated Mats' patch to work with current trunk.

I just unbitrotted the patch and successfully built a trunk build. It works as advertised. Any chances of getting this into CVS? This would allow for a greatly enhanced functionality in Adblock Plus, allowing whitelisting for CSS rules.
Comment 8 User image Cédric "chewey" Menge 2007-06-11 11:18:47 PDT
Comment on attachment 267038 [details] [diff] [review]
updated Mats' patch to work with current trunk.

r? - Just getting attention for Mats' patch, I don't know if this implementation already is trunkworthy.
But this functionality would generally be great to have.
Comment 9 User image Cédric "chewey" Menge 2007-06-11 11:19:35 PDT
Comment on attachment 267038 [details] [diff] [review]
updated Mats' patch to work with current trunk.

r? - Just getting attention for Mats' patch, I don't know if this implementation already is trunkworthy.
But this functionality would generally be great to have.
Comment 10 User image David Baron :dbaron: ⌚️UTC-8 2007-07-17 18:24:10 PDT
I've skimmed this so far --- it seems like it would make more sense to have an mNegations chain rather than doubling the meaning of mNext and adding andWithPrev and negate booleans.

More later, hopefully...
Comment 11 User image David Baron :dbaron: ⌚️UTC-8 2007-07-18 13:23:26 PDT
Comment on attachment 267038 [details] [diff] [review]
updated Mats' patch to work with current trunk.

Actually, I think this implementation approach is cleaner than what I proposed in the previous comment.

My main objection is in the parsing code:  you need to fix things so it doesn't accept space before a :not() expression that's connected to what precedes it (i.e., when we set haveColon to true).  That probably requires swapping the two IsSymbol checks near the end of the parsing loop and adding separate GetToken calls for with and without whitespace (but the second one has to be done only if you got whitespace).  And if you reverse the order, you could go back to using more standard loop control, and maybe even back to using ExpectSymbol.  And maybe the first GetToken could peek instead, and let the colon always be consumed at the start of the loop.

You should also merge the :not( parsing into a bunch of ||s rather than having a bunch of blocks that do the exact same thing.

r+sr=dbaron with that, although I want to have a look at the parsing code revisions
Comment 12 User image Jason Barnabe (np) 2007-10-07 22:34:06 PDT
Cedric or Mats, can you address David's comments?
Comment 13 User image Lee Hyde 2009-12-01 17:14:28 PST
Has there been, or is there likely to be any movement on this in the foreseeable future? I could certainly see this being of utility and it would be nice to see this feature supported in Firefox 3.7 or failing that 4.0.
Comment 14 User image Jason Barnabe (np) 2009-12-01 17:42:08 PST
Personally, I'd prefer having regex support (bug 398962) than this...
Comment 15 User image Lee Hyde 2009-12-01 18:16:33 PST
I suppose that regular expressions would provide a more versatile solution, although is there precedence for using regex with CSS?

Incidentally, should not the proper syntax *not* rule be as follows:

@-moz-document url(""):not

Comment 16 User image Jason Barnabe (np) 2011-09-04 21:34:28 PDT
Regex is supported now, which should be able to cover the original use cases I specified. The only reason I can see for implementing this would be to have a simpler way to do it without having to deal with look-aheads and such, but I don't think it's worth it. Not sure about the appropriateness of wontfixing my own bug, so I'll leave it to someone else, if desired.
Comment 17 User image Mats Palmgren (:mats) 2011-09-05 00:57:36 PDT
I think this is wontfix if the equivalent can be done using regex syntax.
I'll leave it for dbaron to decide.
Comment 18 User image David Baron :dbaron: ⌚️UTC-8 2011-09-05 08:15:55 PDT
I think negations are still useful.
Comment 19 User image William R. "Xer" Cope 2011-09-05 09:00:38 PDT
Agreed. Mozilla is Mozilla because we have the option to do these things how we want to our own tastes, rather than being restricted to one method which may or may not be more complicated than it needs to be to do something really simple. Besides this just being a more straightforward approach, there are still a lot of people out there who don't like regular expressions.
Comment 20 User image Lain_13 2011-09-05 09:11:14 PDT
Hi, sorry for interfering but anything with simple and readable syntax are better then regular expressions with lookaheads. Proposed syntax definitely are. I just know how fast regular expression can mutate into something totally unsupportable and unintelligible. I don't really dislike regexps but there is well known phrase about them. If you would like to solve your problem with regular expression then you have two problems. I had enough practice with regular expressions to tell how true this phrase is.

Also if we have selector for specific site then :not() part will be checked only on this particular site. Regexp with lookaheads will be checked for every page. So, this syntax not only simple but performance wise as well.
Comment 21 User image Wladimir Palant 2011-11-16 05:08:15 PST
Just to chime in: Adblock Plus would also need negations, not regexps. Putting the current use case (include some domains but exclude others) into a regular expression is very complicated. So the approach currently used involves XBL tricks that have side-effects.
Comment 22 User image Jason Barnabe (np) 2011-11-16 07:27:21 PST
@-moz-document regexp('https?://(?!(www\\.google\\.com|bugzilla\\.mozilla\\.org)).*') {
body {
	background-color: blue !important;

I wouldn't call it "very" complicated. Perhaps "somewhat" :).
Comment 23 User image William R. "Xer" Cope 2011-11-16 07:48:01 PST
I'd call it "more complicated than it needs to be."
Comment 24 User image William R. "Xer" Cope 2011-11-16 07:50:10 PST
Wait, actually, I didn't even realize this, but not only would I call it that, I already did. Those are the exact words I used a few comments up.
Comment 25 User image Wladimir Palant 2011-11-16 07:53:06 PST
(In reply to Jason Barnabe (np) from comment #22)
I have *domains*, not host names. Some number of domains is included, some are excluded, and all that is generated dynamically. I think that this can be done - but it is a lot more complicated that it needs to be and the performance will most likely be pretty bad as noted by Lain_13.
Comment 26 User image LEOXD 2012-10-08 08:07:11 PDT
Yup. I had a little bit fun with regular expressions (and the string got longer and longer), and... yeah... a simple :not would help definitely.
Comment 27 User image Dan Jacobson 2012-12-11 08:59:32 PST
I can't believe this whole protocol was invented with no thought of exclusion.
Comment 28 User image Firefox Portable user 2013-09-01 06:49:00 PDT Comment hidden (abusive)

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