Closed
Bug 423985
Opened 16 years ago
Closed 16 years ago
Suggestions for additional @-moz-document selection functions
Categories
(Core :: CSS Parsing and Computation, enhancement, P4)
Core
CSS Parsing and Computation
Tracking
()
RESOLVED
WONTFIX
People
(Reporter: cjcypoi02, Unassigned)
References
(Depends on 1 open bug)
Details
(Keywords: css-moz)
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b5pre) Gecko/2008031806 Minefield/3.0b5pre Build Identifier: 1) boolean expressions (not, and, or). Example: @-moz-document (domain(google.com) and not url-prefix(http://www.google.com/search)) {...} 2) domain-strict rule. True only if the site is in the specified domain, or in www subdomain. Example: @-moz-document domain-strict("google.com") {...} is applied only to google.com and to www.google.com, and not to images.google.com 3) url-suffix: self-explaining 4) limited regexp: a) "dom-single" must begin with a . character (or with the start of domain), and end with the first . or / character after it (or with the end of url) b) "dom-greed" is like dom-single, but ends with the first / character (or with end of url) c) "protocol" is for any protocol Example: @-moz-document url-prefix(protocol + dom-single + "google" + dom-greed) {...} is applied to www.google.com, images.google.co.uk, but not to upload.video.google.com Reproducible: Always
(In reply to comment #0) > 1) boolean expressions (not, and, or). Example: > > @-moz-document (domain(google.com) and not > url-prefix(http://www.google.com/search)) {...} I think this has been proposed in another bug. > 2) domain-strict rule. True only if the site is in the specified domain, or in > www subdomain. Example: > > @-moz-document domain-strict("google.com") {...} You can do this with url-prefix("http://google.com/"). > 3) url-suffix: self-explaining Why would you want it? (Or do you really want mime-type()?) > 4) limited regexp: I don't think it's worth the complexity. If we want something like this, I'd want to use JavaScript-compatible regexps so that we can just reuse its existing regexp code, which would be much simpler than writing another implementation.
Priority: -- → P4
Summary: Suggestions for additional @-moz-document rules → Suggestions for additional @-moz-document selection functions
Reporter | ||
Comment 2•16 years ago
|
||
(In reply to comment #1) >> 2) domain-strict rule. True only if the site is in the specified domain, or in >> www subdomain > > You can do this with url-prefix("http://google.com/") Well, it's not the same. url-prefix("http://google.com/") is not applied to https://google.com/, or http://www.google.com/ etc. I should add all possibility. >> 3) url-suffix: self-explaining > > Why would you want it? (Or do you really want mime-type()?) For example, this rule could be applied to any pages like this: http://some-site.org/some-string/hello.html >> 4) limited regexp: > > If we want something like this, I'd > want to use JavaScript-compatible regexps so that we can just reuse its > existing regexp code, which would be much simpler I don't know... a full support of js regexps could causes security problems, I think.
Reporter | ||
Comment 3•16 years ago
|
||
Instead of regexp, I think it could be implemented a simpler function, host-prefix(). It should match an host if it begins with specified domains, or with www.domains Example: @-moz-document host-prefix("site.co") {...} will match site.co, www.site.co, site.co.uk, site.co.my.us etc, but not forum.site.co or site.com
Reporter | ||
Comment 5•16 years ago
|
||
Well, since this bug is a mess ^__^'' I'll set it as invalid and I'll open another bug within 48 hours with only "domain-strict" and "host-prefix" suggestions, if no one is opposed to this.
I really don't see how host-prefix is useful, given how DNS works. Likewise, I'm opposed to domain-strict, since it makes "www." magical and can be written easily with url-prefix. Having a separate bug isn't going to make me more likely to want them. I have no idea why you think full JS regexps would cause security problems.
Comment 7•16 years ago
|
||
Bug 398962 is for adding regular expressions. Having regular expressions for all the cases in comment 0 makes more sense to me.
OK, given that :not() is bug 349813 and regular expressions are bug 398962, I think the remainder of this bug is wontfix; I prefer the solutions described in those bugs to the ones proposed here.
Status: UNCONFIRMED → RESOLVED
Closed: 16 years ago
Resolution: --- → WONTFIX
You need to log in
before you can comment on or make changes to this bug.
Description
•