349813 - Make a way for site (-moz-document) rules to apply on sites *not* matching a URL/prefix/domain

Status: REOPENED

(Core :: CSS Parsing and Computation, enhancement, P5)

Description

[Jason Barnabe (np)]

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

[Mats Palmgren (inactive)]

Attachment: wip

This patch extends the @-moz-document syntax so you can now wrap the
function in an optional :not(), like so:
 :not(domain(mozilla.com))
 :not(url-prefix(http://www.w3.org/Style/))
 :not(url(http://www.w3.org/))

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

[Jason Barnabe (np)]

Does that patch allow for something like this:

@-moz-document domain("mozilla.org"):not(domain("bugzilla.mozilla.org"))

which would match everything in mozilla.org except for the things in bugzilla.mozilla.org? Or does it simply allow you to do this

@-moz-document :not(domain("bugzilla.mozilla.org"))

which would match all non-bugzilla pages?

Comment 3

[Mats Palmgren (inactive)]

(In reply to comment #2)
> Does that patch allow for something like this:
> 
> @-moz-document domain("mozilla.org"):not(domain("bugzilla.mozilla.org"))

No it doesn't, but I agree that combining them as you suggest
is much more useful.

Comment 4

[Mats Palmgren (inactive)]

Attachment: wip2

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
http://lists.w3.org/Archives/Public/www-style/2004Aug/0135.html
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

[Micah Bucy]

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(http://www.w3.org)

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 http://username.deviantart.com/gallery, but considering the number of users out there, it would be problematic to do this url by url.  

Something like 
@-moz-document url(http://*.deviantart.com/gallery) 
would solve this quite nicely.  So I suppose it would be a combination of domain(deviantart.com) and the path that follows it.  Maybe syntax could be 
domain(mozilla.com):path=["/path/restrictions"], 
then likewise there could be
domain(mozilla.com):not(path=["/path/restrictions"])

Comment 6

[Mats Palmgren (inactive)]

(In reply to comment #5)
Please file it as a separate enhancement request.

Comment 7

[Cédric "chewey" Menge]

Attachment: 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

[Cédric "chewey" Menge]

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

[Cédric "chewey" Menge]

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

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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

[Jason Barnabe (np)]

Cedric or Mats, can you address David's comments?

Comment 13

[Lee Hyde]

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

[Jason Barnabe (np)]

Personally, I'd prefer having regex support (bug 398962) than this...

Comment 15

[Lee Hyde]

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("http://www.example.com"):not

???

Comment 16

[Jason Barnabe (np)]

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

[Mats Palmgren (inactive)]

I think this is wontfix if the equivalent can be done using regex syntax.
I'll leave it for dbaron to decide.

Comment 18

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

I think negations are still useful.

Comment 19

[William R. "Xer" Cope]

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

[Lain_13]

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

[Wladimir Palant]

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

[Jason Barnabe (np)]

@-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

[William R. "Xer" Cope]

I'd call it "more complicated than it needs to be."

Comment 24

[William R. "Xer" Cope]

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

[Wladimir Palant]

(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

[LEOXD]

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

[Dan Jacobson]

I can't believe this whole protocol was invented with no thought of exclusion.

Comment 28

[Firefox Portable user]

but you can believe that mozdevs don't give a sh1t about fixing such old bugs.

Comment 29

[Cameron McCormack (:heycam)]

@-moz-document is no longer supported.

Comment 30

[Gingerbread Man]

(In reply to Cameron McCormack (:heycam) from comment #29)
> @-moz-document is no longer supported.

Bug 1035091 is about web sites. This is about user styles:

(In reply to Jason Barnabe (np) from comment #0)
> A common request I've heard regarding user stylesheets…

Comment 31

[Cameron McCormack (:heycam)]

Yes, my mistake, and thank you for re-opening.  (Though I think this is low priority so setting P5 for now.)