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

NEW
Unassigned

Status

()

Core
CSS Parsing and Computation
--
enhancement
11 years ago
7 months ago

People

(Reporter: Jason Barnabe (np), Unassigned)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments, 1 obsolete attachment)

(Reporter)

Description

11 years ago
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

11 years ago
Created attachment 235706 [details] [diff] [review]
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?
(Reporter)

Comment 2

11 years ago
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

11 years ago
(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

11 years ago
Created attachment 237625 [details] [diff] [review]
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*
Attachment #235706 - Attachment is obsolete: true

Updated

11 years ago
Assignee: dbaron → mats.palmgren

Comment 5

11 years ago
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

11 years ago
(In reply to comment #5)
Please file it as a separate enhancement request.
QA Contact: ian → style-system
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 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.
Attachment #267038 - Flags: review?(dbaron)
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.
Attachment #267038 - Flags: review?(dbaron)
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 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
Attachment #267038 - Flags: review?(dbaron)
Attachment #267038 - Flags: review-
(Reporter)

Comment 12

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

Updated

9 years ago
Blocks: 423985

Updated

9 years ago
Blocks: 467520

Comment 13

8 years ago
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.
(Reporter)

Comment 14

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

Comment 15

8 years ago
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

???
(Reporter)

Comment 16

6 years ago
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.
I think this is wontfix if the equivalent can be done using regex syntax.
I'll leave it for dbaron to decide.
I think negations are still useful.
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

6 years ago
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

6 years ago
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.
(Reporter)

Comment 22

6 years ago
@-moz-document regexp('https?://(?!(www\\.google\\.com|bugzilla\\.mozilla\\.org)).*') {
body {
	background-color: blue !important;
}
}

I wouldn't call it "very" complicated. Perhaps "somewhat" :).
I'd call it "more complicated than it needs to be."
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

6 years ago
(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

5 years ago
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

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

Updated

4 years ago
Assignee: matspal → nobody
Comment hidden (abuse-reviewed)

Updated

7 months ago
No longer blocks: 467520
You need to log in before you can comment on or make changes to this bug.