Suggestion: Element Hiding Helper design

Various discussions related to Adblock Plus development
Another Anonymous

Suggestion: Element Hiding Helper design

Post by Another Anonymous »

Hello

In my opinion, the current way of choosing an element to block is not as convenient as it could be.

How does it work now:
- First I should choose an element with my mouse.
- Then I usually need to use the "wider" option. On an English version of the Add-on, I have to press 'w' (I'm not sure whether keyboard input language matters). But I use the Russian version, so I must set my language to Russian first, then press the 'ш' key, and when done go back to English. Also, at that time, I must not move my mouse. I won't say it's really convenient.
- Left click, confirm.

So how would I like it to work:
- Show a window, with buttons, instead of the tooltip.
- Choose an element with the mouse by clicking on it.
- Use the wider/narrower/whatever functions by clicking on the proper buttons of the window.
- Click on a proper button of the window (e.g. OK) to accept the selection.

So, basically, this is similar to the element selection method of Remove It plug-in for Maxthon.

By the way, in the window that shows after the element selection, a horizontal scroll in the element tree would be very helpful.

Tell me what do you think.
Wladimir Palant

Post by Wladimir Palant »

So the important suggestion here is choosing the element (clicking it) before you use wider/narrower/etc. However, I for my part often check the document structure and move the selection again then. Any other opinions on that topic?
Another Anonymous

Post by Another Anonymous »

The most important suggestion here is changing the wider/narrower/etc. usage, making it simpler than this:
Another Anonymous wrote:I must set my language to Russian first, then press the 'ш' key, and when done go back to English. Also, at that time, I must not move my mouse.

...
Wladimir Palant wrote:I for my part often check the document structure and move the selection again then.
It can be done this way:
On mouse move, the red border is moving after the cursor position - the current behavior.
On mouse click, that rectangle gets filled with transparent red, and you still can move the mouse (and the red border) to select another object.
User avatar
Adblock Plus Fan
Posts: 1255
Joined: Sat Feb 24, 2007 11:08 am

Re: Suggestion: Element Hiding Helper design

Post by Adblock Plus Fan »

Another Anonymous wrote:Also, at that time, I must not move my mouse. I won't say it's really convenient.
Perhaps a Lock to Element hotkey could solve this?
Wladimir Palant

Post by Wladimir Palant »

Yes, that's an option. And I guess using Cyrillic hotkeys was a mistake on my part (I assumed that people using Russian Firefox locale also browse with Russian keyboard layout - esp. since access keys are Cyrillic as well).
User avatar
Adblock Plus Fan
Posts: 1255
Joined: Sat Feb 24, 2007 11:08 am

Post by Adblock Plus Fan »

I was thinking it would be best if Lock to Element function ignores further mouse hovering, yet still works with W and N hotkeys.
Wladimir Palant

Post by Wladimir Palant »

That's what I was thinking about as well. I would call it "Lock selection" however.
Wladimir Palant

Post by Wladimir Palant »

I implemented a "lock/unlock selection" command but getting the tooltip to accept clicks is apparently more difficult than I thought.
alta88
Posts: 116
Joined: Wed Jun 21, 2006 10:16 am

Post by alta88 »

frankly, EHH is quite uncomfortable to use, and i solely use Stylish for element hiding. if there were some performance benefit it might be worth the trouble, but there isn't; stats aren't important enough for me.

the major problem is the limited mini DOM which, once an element is selected, cannot traverse the full tree (and highlight elements) without a 'restart'.

imo, EHH should be an addition onto DOMi. Stylish adds a menuitem to copy the selected element's selector (a few choices) once the correct one is identified after some trial and error. i have some js code which adds a context menu item (chrome and content) to open DOMi and go to the element under the cursor. i find this much faster and more flexible than the aardvark method.

anyway, this all is jmo.
Wladimir Palant

Post by Wladimir Palant »

Well, for me DOMi is quite unconfortable to use...
alta

Post by alta »

Wladimir Palant wrote:Well, for me DOMi is quite unconfortable to use...
you don't say how. you do say, however
I for my part often check the document structure and move the selection again then.
how do you do that exactly? maybe mentally parse the page source?

perhaps you could address, instead, the 'restart' needed to get to another node. or the fact that if one has 6 items to hide, EHH has to be started 6 times (at least). or the fact that if a mistake is made, a whole other UI has to be started to remove the rule. are you suggesting any of this is comfortable?
Wladimir Palant

Post by Wladimir Palant »

If I position the mouse pointer on the text I want to hide, it should get me into the right branch of the DOM. I press w/n a few times and that does it, without any complicated DOM inspection - why do you need to "restart" that often?
alta

Post by alta »

Wladimir Palant wrote:If I position the mouse pointer on the text I want to hide, it should get me into the right branch of the DOM. I press w/n a few times and that does it, without any complicated DOM inspection - why do you need to "restart" that often?
the simplest example is what i recall from trying this with complex yahoo pages. very often when hiding a node one also needs to hide adjacent sibling nodes, for alignment and getting rid of extraneous spacing etc. the w/n method can't handle adjacentness. the fake DOM is simplified to the point of being an illusion of the real page structure. EHH may mostly be sufficient for simple structure sites and a one-off hide, but trying to use it for anything complex and/or obfuscatory is impossible without a real DOMi.

and, have you ever tried to use it to clean a page with say 20 items to hide? no comparison with the relative ease of DOMi/Stylish. once DOMi is up, it's 2 clicks to get to the exact node under the cursor, so the 20x repeat here is fast.

there's also little things, like :first-child. Stylish always, correctly, adds that in the selector; have to explicitly check that in EHH. and in many cases, the full path selector is necessary, which means selecting/clicking a lot of nodes/checkboxes.
User avatar
Lucas Malor
Posts: 72
Joined: Wed Aug 23, 2006 7:34 am
Contact:

Post by Lucas Malor »

Well, I use Firebug* + Stylish for this, intead of DOM Inspector + Stylish. Firebug* is more simple to use, even if is much slower too.

*and not bugzilla... edited by me
Last edited by Lucas Malor on Fri May 29, 2009 5:47 pm, edited 1 time in total.
User avatar
Lucas Malor
Posts: 72
Joined: Wed Aug 23, 2006 7:34 am
Contact:

Post by Lucas Malor »

Whops. I mean Firebug, not Bugzilla :oops:
Post Reply