Open
Bug 349813
Opened 18 years ago
Updated 2 years ago
Make a way for site (-moz-document) rules to apply on sites *not* matching a URL/prefix/domain
Categories
(Core :: CSS Parsing and Computation, enhancement, P5)
Core
CSS Parsing and Computation
Tracking
()
REOPENED
People
(Reporter: jason.barnabe, Unassigned)
References
Details
Attachments
(2 files, 1 obsolete file)
9.98 KB,
patch
|
Details | Diff | Splinter Review | |
8.68 KB,
patch
|
dbaron
:
review-
dbaron
:
review-
|
Details | Diff | Splinter Review |
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•18 years ago
|
||
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•18 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•18 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•18 years ago
|
||
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•18 years ago
|
Assignee: dbaron → mats.palmgren
Comment 5•18 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•18 years ago
|
||
(In reply to comment #5) Please file it as a separate enhancement request.
QA Contact: ian → style-system
Comment 7•17 years ago
|
||
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•17 years ago
|
||
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 9•17 years ago
|
||
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•17 years ago
|
||
Cedric or Mats, can you address David's comments?
Comment 13•15 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•15 years ago
|
||
Personally, I'd prefer having regex support (bug 398962) than this...
Comment 15•15 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•13 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.
Comment 17•13 years ago
|
||
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.
Comment 19•13 years ago
|
||
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•13 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•13 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•13 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" :).
Comment 23•13 years ago
|
||
I'd call it "more complicated than it needs to be."
Comment 24•13 years ago
|
||
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•13 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•12 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•12 years ago
|
||
I can't believe this whole protocol was invented with no thought of exclusion.
Updated•11 years ago
|
Assignee: matspal → nobody
Comment hidden (abuse-reviewed) |
Comment 29•6 years ago
|
||
@-moz-document is no longer supported.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → WONTFIX
Comment 30•6 years ago
|
||
(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…
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
Comment 31•6 years ago
|
||
Yes, my mistake, and thank you for re-opening. (Though I think this is low priority so setting P5 for now.)
Priority: -- → P5
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•