[Done] Extending filter syntax
Re: Opinions requested: extending filter syntax
Could you please tell us what are the different types we can use ? As I use a french build, I cannot use the french words I've found in Adblock.Wladimir Palant wrote:I would like to specify what types of elements filters apply to.
There are these ones for instance :
*$link
*$object
*$background
*$script
*$img
*$style
Is it already usable ?Wladimir Palant wrote:Furthermore I would like to treat third-party images/scripts/etc specially.
I'm sorry, this really needs to be documented. The possible type options are:
other
script
image
stylesheet
object
subdocument
document
link
background
They are *not* localized. You can combine them like this:
You can also negate them:
Finally there is one additional option which is match-case:
Will match "http://server.com/Ads/something.gif" but not "http://server.com/ads/something.gif". Third-party option is not yet implemented, there are some issues with it.
other
script
image
stylesheet
object
subdocument
document
link
background
They are *not* localized. You can combine them like this:
Code: Select all
*/ads/*$script,image,object
Code: Select all
*/ads/*$~stylesheet
Code: Select all
*/Ads/*$match-case
I think the idea is good, but I'd think it get a problem if advertisers would use URIs containing a $ symbol and/or \d. (I think there's the same problem with the pipe at the end of URIs.) I guess some escaping syntax could be useful.
The market share of users with Adblock Plus is not very high, of course. But I remember the much-less-known/used extension Layerblock already had problems with some advertisers (layer-ads.de) always modifieing there Layers slightly so these weren't blocked anymore. As it wouldn't hurt the advertisers when they would change their URIs in any way, I'd think some will do.
The market share of users with Adblock Plus is not very high, of course. But I remember the much-less-known/used extension Layerblock already had problems with some advertisers (layer-ads.de) always modifieing there Layers slightly so these weren't blocked anymore. As it wouldn't hurt the advertisers when they would change their URIs in any way, I'd think some will do.
The dollar sign $ is only "special" if followed by a list and the pipe | is only treated specially if found at the start or end of the filter - not a problem yet. Btw, I've already seen somebody using "*.html" in the address - without much success
Yet a way to escape things somehow would be good in fact, I'm looking for solutions here.
Yet a way to escape things somehow would be good in fact, I'm looking for solutions here.
It just came to my mind you could use the same escape syntax like http. I've myself not yet decided if it's a good or a bad idea. I just thought, I'd share it with you.
In the end this would mean using this:
The problem with this is surely that only advanced users would know of it and that it'd always be a problem to find out what the hex value of e.g. the # sign was again.
Maybe just a different approach of adding the extra information would be the best. Instead of modifieing the filter directly use another textbox at the right of it called "special" or something where you type in these informations (@@, |, ##, $ or anything coming in the future). This could also be extended to a dialog that allows the novice user to use these options.
This doesn't solve the problem with * (which matches itself anyway) and \d+ though.
In the end this would mean using this:
Code: Select all
%7c |
%23 #
%24 $
%2a *
%5c \
%2b +
%25 %
Maybe just a different approach of adding the extra information would be the best. Instead of modifieing the filter directly use another textbox at the right of it called "special" or something where you type in these informations (@@, |, ##, $ or anything coming in the future). This could also be extended to a dialog that allows the novice user to use these options.
This doesn't solve the problem with * (which matches itself anyway) and \d+ though.
I can't use this escaping because URLs are already escaped in this way And anyways, it is far too complicated.
My idea so far was somewhere along these lines:
I don't like creating a second regular expressions syntax (especially the last escaping sequence is all but perfect) but I should need some of these for new features - and plain regular expressions are too difficult to parse.
My idea so far was somewhere along these lines:
Code: Select all
{4} => .{4}
{4,8} => .{4,8}
{d4,8} => \d{4,8}
{d*} => \d*
{*} => \*
{$} => \$
{[a-z]} => [a-z]
{[a-z]2} => [a-z]{2}
{x7B}{x7D} => \{\}
We finally have documentation on the options: http://adblockplus.org/en/filters#options
- Lucas Malor
- Posts: 72
- Joined: Wed Aug 23, 2006 7:34 am
- Contact:
I would ask if $third-party will be implemented in a future... above all I'm interested in filters like this:
so I could apply a specific filter only for one domain, speeding up the filtering for the other domains that don't need that filter.
Code: Select all
www.site1.com/someannoyingstuff$~third-party
- Lucas Malor
- Posts: 72
- Joined: Wed Aug 23, 2006 7:34 am
- Contact: