Suggestion: Element Hiding Helper design
Suggestion: Element Hiding Helper design
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.
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.
The most important suggestion here is changing the wider/narrower/etc. usage, making it simpler than this:
...
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.
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.
...
It can be done this way:Wladimir Palant wrote:I for my part often check the document structure and move the selection again then.
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.
- Adblock Plus Fan
- Posts: 1255
- Joined: Sat Feb 24, 2007 11:08 am
Re: Suggestion: Element Hiding Helper design
Perhaps a Lock to Element hotkey could solve this?Another Anonymous wrote:Also, at that time, I must not move my mouse. I won't say it's really convenient.
ABP video download trick / Want to help? Test new builds/report bugs you find.
- Adblock Plus Fan
- Posts: 1255
- Joined: Sat Feb 24, 2007 11:08 am
I was thinking it would be best if Lock to Element function ignores further mouse hovering, yet still works with W and N hotkeys.
ABP video download trick / Want to help? Test new builds/report bugs you find.
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.
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.
you don't say how. you do say, howeverWladimir Palant wrote:Well, for me DOMi is quite unconfortable to use...
how do you do that exactly? maybe mentally parse the page source?I for my part often check the document structure and move the selection again then.
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?
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.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?
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.
- Lucas Malor
- Posts: 72
- Joined: Wed Aug 23, 2006 7:34 am
- Contact:
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
*and not bugzilla... edited by me
Last edited by Lucas Malor on Fri May 29, 2009 5:47 pm, edited 1 time in total.
- Lucas Malor
- Posts: 72
- Joined: Wed Aug 23, 2006 7:34 am
- Contact: