423985 - Suggestions for additional @-moz-document selection functions

Status: RESOLVED WONTFIX

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

Description

[Lucas Malor (mail: c6kfnkn2uc AT snkmail DOT c0m)]

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

Comment 1

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

(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.

Comment 2

[Lucas Malor (mail: c6kfnkn2uc AT snkmail DOT c0m)]

(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.

Comment 3

[Lucas Malor (mail: c6kfnkn2uc AT snkmail DOT c0m)]

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

Comment 4

[Mats Palmgren (inactive)]

See bug 349813 comment 4 on :not() and AND.

Comment 5

[Lucas Malor (mail: c6kfnkn2uc AT snkmail DOT c0m)]

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.

Comment 6

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

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

[Jason Barnabe (np)]

Bug 398962 is for adding regular expressions.

Having regular expressions for all the cases in comment 0 makes more sense to me.

Comment 8

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

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.