Page 1 of 1

Problems customising rule with Element Hiding Helper

PostPosted: Tue Jan 15, 2008 6:30 pm
by sremick
I'm having issues with the Element Hiding Helper. I have been getting into using the "Select element to hide" feature, and often I just click the element and it's the one I want and I'm good to go. But sometimes I'm finding I actually want to go up a few levels after exploring the element tree in Advanced View. The problems arise when I try to customize the filter by unchecking the boxes that were already selected and checking new boxes on parent elements. The resulting rule is a mess and not what it should be.

For example, I go to a Slashdot page and see an element area I want to hide. The best I can do initially with "Select element to hide" and the mouse is:

However, after selecting that and going to Advanced view, I see that the parent DIV would be a better one since it's class=ad1 which seems pretty obvious. So first I unselect the initial "Tag name" and id. My filter now looks like:*

I then go to the parent DIV branch and check the boxes next to "Tag name: DIV" and "class: ad1". Now my rule looks like: > *

When it should be:

What's going on?

PostPosted: Tue Jan 15, 2008 6:42 pm
by rick752
They both mean the same thing. One you start an x-path with the rules, the rule is changed from an "adblock plus specific" rule to a standard css rule (EHH supports both rules and there are advantages to both).

It seems that once you have done anything needs a css rule (like xpathing), unchecking the element that started that type of rule does not revert it back to the ABP-specific rule again.

Needless to say ... both of those rules are the same rule. A single '#' denotes an ABP rule .... Two '##" denotes a css rules. The 'dot' means "class" in a css rule. So " ##DIV.ad1 " actually DOES mean " #DIV(class=ad1) "

PostPosted: Tue Jan 15, 2008 6:51 pm
by sremick
Ok, fair enough. However, would the inability for it to retain the filter type be considered a "bug"? While there very well could be advantages to CSS selectors, that's a whole new filter style I'll need to get my head around after years with the other style, and it won't be happening today (splitting headache) so I'd love to just continue to work with basic ABP rule syntax for now (especially since I'm pretty sure it'll meet all my needs). If it's a bug, who do I report it to?

PostPosted: Tue Jan 15, 2008 8:33 pm
by Stupid Head
If you're going invest significant effort into learning a syntax like you have, I would suggest you learn to use CSS selectors instead of the ABP syntax because it's more flexible and CSS is used by lots of other people. It's not hard to get started.
Code: Select all




The only thing that you can do with the custom syntax that you can't do with CSS selectors is where you leave out the attribute like this:
Code: Select all

With CSS selectors, you would have to write two filters:
Code: Select all

Which you can combine into this:
Code: Select all

That's all it takes to get started.

PostPosted: Tue Jan 15, 2008 11:12 pm
by sremick
Ok, my headache is gone... I'm going to try and learn CSS selectors. :)

From what I've read, am I correct that the trailing "> *" from the example I originally posted is redundant? Meaning that: > *

Is the same as:

Which is also the same as:[class~=ad1]

PostPosted: Tue Jan 15, 2008 11:51 pm
by rick752
@ Stu:

Don't css identifiers need quotes? (I have alway used them when they exist in the page code). I have never tried them without before. Shouldn't your example of:
Code: Select all

... be ...
Code: Select all


I just tried it and it seems that quotes ARE needed using css rules.

PostPosted: Wed Jan 16, 2008 1:25 am
by Dr. Evil
sremick > *

Is the same as:
No, it isn't. The first is "any child of a DIV element with the class 'ad1'", the second is "any DIV element with the class 'ad1'".

When you have selected an element to hide once in EHH, you can't change it without closing and reopening EHH, even though it would be helpful sometimes. You can only change why it's hidden (class and element names, parent nodes, ...).

PostPosted: Wed Jan 16, 2008 8:15 am
by Stupid Head
Quotes aren't need unless there is a space in the value. Are you getting all greens with this test:

The first filter blocks all elements inside the div while the second filter blocks the div element itself. So yes, the second filter would be preferred over the first. And the third filter is the same as the second filter.