Whitelisted element may not display as intended

[CODYQX4]

I've noticed that if I whitelist an element, it gets a display: initial !important.

This might not work out if that element is using a different display.

For example on 53.com there is a div#ad-rotator. If I whitelist this, it ceases to be a block element and messes up the layout.

[gorhill]

I see.. So the fix is really to have the whitelisted selectors removed from the set of blocked ones, rather than try to re-enable them, as I can't restore for sure their computed display values.

[CODYQX4]

That makes sense. I figured trying to compute the original CSS value would be no small feat, but removing any block rules on page load that would conflict with the whitelist could work.

…

On 8/7/14, Raymond Hill <notifications@github.com> wrote: I see.. So the fix is to really to have the whitelisted selector removed from the set of blocked ones, rather than try to re-enable it, as I can't restore for sure it's computed `display` value. --- Reply to this email directly or view it on GitHub: gorhill/uBlock#143 (comment)

[gorhill]

Ok, I have a fix.

However, your specific filter would still not work, because I originally made the choice to not support generic exceptions for cosmetic filters: there is no such filters in EasyList or EasyPrivacy. These are rather rare occurrences: for all the lists which ship with uBlock, there are only 8 occurrences of such filters.

Workaround for your specific case is to use: 53.com#@##ad-rotator. Domain- or entity-scoped cosmetic filters are the preferred way for cosmetic filters: Their look-up is more performant, and they can be injected very early in the page.

If I were to enable support, this would add some overhead to the cosmetic filter look-up code, and I rather not introduce a systematic overhead in order to support such rare occurrences.

[CODYQX4]

I am actually using that filter as is already, it just doesn't make it a block element. I used Stylish for Chrome to force it to be a display: block for now.

…

On Thursday, August 7, 2014, Raymond Hill <notifications@github.com> wrote: Ok, I have a fix. However, your specific filter would still not work, because I originally made the choice to not support generic exceptions for cosmetic filters: there is no such filters in *EasyList* or *EasyPrivacy*. These are rather rare occurrences: for all the lists which ship with uBlock, there are only 8 occurrences of such filters. Workaround for your specific case is to use: 53.com#@##ad-rotator <http://53.com#@%23%23ad-rotator>. Domain- or entity-scoped cosmetic filters are the preferred way for cosmetic filters: Their look-up is more performant, and they can be injected very early in the page. If I were to enable support, this would add some overhead to the cosmetic filter look-up code, and I rather not introduce a systematic overhead in order to support such a rare occurrence of filters. — Reply to this email directly or view it on GitHub <gorhill/uBlock#143 (comment)>.