[Rejected] $not domain option (exception within a filter)

Various discussions related to Adblock Plus development
Locked
Wladimir Palant

[Rejected] $not domain option (exception within a filter)

Post by Wladimir Palant »

This suggestion comes from the Mozilla Russia forum. It boils down to a new filter option - $not. It could be used like this:

Code: Select all

||example.com^$not=*/no_ads_here/*
So, after not= a second filter (simple filter or regexp) can be specified - if the main filter matches the address the second filter will be tested. Only addresses where the main filter matches but the second doesn't are accepted. This is sort of a local exception rule.

A restriction: this option must be the last option specified (a filter can contain commas, these will be considered part of the filter rather than option separators).

What do subscription authors think about this? Is this useful? Is this too complex?
User avatar
fanboy
Posts: 3446
Joined: Sun Jun 17, 2007 4:45 am
Contact:

Re: $not domain option (exception within a filter)

Post by fanboy »

so something like this would be vaild?

Code: Select all

||example.com,||test.com,||another.com^$not=*/no_ads_here/*
or

Code: Select all

||example.com^,||test.com^,||another.com^$not=*/no_ads_here/*,$not=*/ihateads/*
Wladimir Palant

Re: $not domain option (exception within a filter)

Post by Wladimir Palant »

Nope, instead of the first one you would write:

Code: Select all

||example.com^$not=*/no_ads_here/*
||test.com^$not=*/no_ads_here/*
||another.com^$not=*/no_ads_here/*
As to the second, I guess that you could use regular expressions if you really have to:

Code: Select all

||example.com^$not=/\/(no_ads_here|ihateads)\//
As I mentioned, a comma is a valid part of the filter, you cannot use it to separate filters / filter options.
User avatar
ziutek
Posts: 49
Joined: Sat Aug 08, 2009 10:18 am

Re: $not domain option (exception within a filter)

Post by ziutek »

Why wouldn't it accept '|', like $domain?

I think that the proposition may be a bit overspecialized. It also encourages a style that is very prone to false positives. (I am not a subscription author.)
Wladimir Palant

Re: $not domain option (exception within a filter)

Post by Wladimir Palant »

Because | is also a valid part of a filter, e.g. ||foo.bar or /(foo|bar)/.
MonztA
ABP Developer
Posts: 3957
Joined: Mon Aug 14, 2006 12:18 am
Location: Germany

Re: $not domain option (exception within a filter)

Post by MonztA »

Hm, I don't really know if this is useful. Anyone has a good example where this could be advantageous?
Wladimir Palant

Re: $not domain option (exception within a filter)

Post by Wladimir Palant »

The original example was overclockers.ru. This site is mixing ads with regular images in its images directory. Right now RU AdList seems to block all Flash in that directory and resort to hiding for images. However, looking at it - I'm not very convinced that this proposal will help.
Lain_13
Posts: 114
Joined: Fri Dec 18, 2009 5:24 pm
Location: Wonderful World, Ubuntu Linux
Contact:

Re: $not domain option (exception within a filter)

Post by Lain_13 »

Hi there,

As I told before here (Russian language) I like this feature but I want to have fully functional feature instead of exception by text. I mean all text after "not=" should be treated like fully functional blocking rule with parameters section.

Examples:
||site.com/$not=*/img/$~object - block everything from site.com except of stuff from /img/ folder but block objects from this folder with other junk.
||site.com/$not=$not=/\/(?:fldr1|fldr2|fldr3)\// - block everything from folders fldr1, fldr2 and fldr3 on site.com (also it allows to make regexp for only 1 site).
||site.com/$not=*/fldr1/$not=*/fldr2/ - block everything from site.com except content of folder fldr1 excluding content of subfolder fldr2.

I think this feature should be as flexible as usual exception rule.

p.s. Of course amount of nested rules must be limited to some constant number. E.g. it should be limited to 5 levels.
p.p.s. Sorry for my Runglish. :)
Wladimir Palant

Re: $not domain option (exception within a filter)

Post by Wladimir Palant »

And as I told before - the "fully functional" feature is definitely not going to happen. I know that Russian users like getting complicated toys to play with. But this is really not useful enough for all the complexity it adds (both code complexity and complexity of filter reading/writing). As this goes right now, it doesn't look like even my proposal will be implemented - it would require at least one other filter subscription author to say "yes, that would be useful".
Michael
Posts: 1361
Joined: Sat Dec 19, 2009 12:29 pm

Re: $not domain option (exception within a filter)

Post by Michael »

At the moment EasyList is slowly moving away from adding domain exceptions by using whitelists as alternatives; therefore I think that the $not suggestion would barely be used in the subscription.
Wladimir Palant

Re: $not domain option (exception within a filter)

Post by Wladimir Palant »

Overall votum seems to be: not useful. Rejected.
Wladimir Palant

Re: [Rejected] $not domain option (exception within a filter)

Post by Wladimir Palant »

Comment from Ares2 arrived too late:
Ares2 wrote:Sorry, looks like I'm late to the party. :-( Anyway, this option wouldn't have much value for the "Easy's" anyway.

I know a few sites where something like

||domain.com/img/
@@||domain.com/img/*abc.gif

would be needed and it seems like the new option would take care of that with 1 rule and without the need for whitelist that can't be overridden BUT those are all anti-adblock actions and those sites would simply find another way to make it hard for us if we added that rule.

My vote goes for the already carried-out rejection. :-)
Some general comments from me: I think that I should stop adding filter syntax extensions as much as possible. The syntax is already pretty complicated and it makes sense not to make it any worse. In future there should only be an exception for syntax extensions that clearly benefit many. Syntax extensions for rare and obscure cases will definitely not be implemented.
Locked