Make a cheatsheet on the rules syntax
Re: Make a cheatsheet on the rules syntax
They should be in the same table but having some section headers there would make sense.
Working on that list once again makes me wonder whether we should have $dtd, $xbl and $ping - chances of seeing any of these types on the web are more than slim. Maybe we should just list them as $other.
Working on that list once again makes me wonder whether we should have $dtd, $xbl and $ping - chances of seeing any of these types on the web are more than slim. Maybe we should just list them as $other.
Re: Make a cheatsheet on the rules syntax
If the cheat sheet is only intended to refer to popular syntax, I would omit all of the options you have listed and add a note to the bottom of the table stating that there are more options available, with the text linking to the existing documentation on filter options.
Re: Make a cheatsheet on the rules syntax
Or that, sounds like a good idea (I guess that at least $match-case would fall into the same category).
Re: Make a cheatsheet on the rules syntax
I created a proposal to reduce the number of type options: forum/viewtopic.php?f=4&t=8244
Re: Make a cheatsheet on the rules syntax
I have only included the options that I think likely to be added to filters by the average user, adding only brief references to dtd, ping, xbl, xmlhttprequest, other, collapse, donottrack and match-case at the bottom of the table.
I have also made a start with element hiding section, adding one example to each of the tables. Does this demonstrate your envisaged arrangement for the section?
I have also made a start with element hiding section, adding one example to each of the tables. Does this demonstrate your envisaged arrangement for the section?
Re: Make a cheatsheet on the rules syntax
I changed the table layout slightly - I think that repeating the table header several times is confusing, also made the section headers regular table cells (but spanning two columns). I'll probably add some additional stying to the section headers later. One more nit: are you sure that xmlhttprequest is uncommon? Anyway, I think that it is starting to look good.
I guess that the separation in the element hiding section makes sense though I would probably say "Domain selection" instead of "Domain matching" (and probably a few more minor wording changes).
I guess that the separation in the element hiding section makes sense though I would probably say "Domain selection" instead of "Domain matching" (and probably a few more minor wording changes).
Re: Make a cheatsheet on the rules syntax
Thanks, I'd been intending to modify the header layout at the end anyway.Wladimir Palant wrote:...also made the section headers regular table cells (but spanning two columns).
I would certainly class the option as uncommon. I cannot imagine that ordinary users, whom I have assumed are the intended audience, would need to know about the option, and even in major subscriptions such as Fanboy's List and Adversity it is only used once in each. The option is used a dozen times or so in EasyList, but relative to the total number of filters it is certainly unusual for it to be required.Wladimir Palant wrote:One more nit: are you sure that xmlhttprequest is uncommon?
Agreed, I will implement this.Wladimir Palant wrote:I would probably say "Domain selection" instead of "Domain matching"
Re: Make a cheatsheet on the rules syntax
I've practically finished the element hiding section of the cheat sheet, but it appears that the column width may need to be adjusted for, for example, example.com,~mail.example.com#selector.
Re: Make a cheatsheet on the rules syntax
Thanks. I've made a few more modifications and, as far as I'm concerned, the cheat sheet is finished. Any comments?
Re: Make a cheatsheet on the rules syntax
Let's make another attempt at this. The cheatsheet has the tendency to grow into large and complicated tables, so I thought about a different approach. Here is what I have so far: en/filter-cheatsheet (some of the old tables still remain at the end). The way it looks right now we could replace the current documentation with it rather than creating an additional page. One would only need to add a "more info" link to some explanation boxes - e.g. going to the full list of filter options or a detailed explanation of separator characters.
Comments?
Comments?