mirror of
https://github.com/laylavish/uBlockOrigin-HUGE-AI-Blocklist.git
synced 2026-08-06 02:12:35 -04:00
[GH-ISSUE #4] opacity: 0 versus the default display: none?
#4
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: DYNR/uBlockOrigin-HUGE-AI-Blocklist#4
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @eishiya on GitHub (Mar 2, 2024).
Original GitHub issue: https://github.com/laylavish/uBlockOrigin-HUGE-AI-Blocklist/issues/4
I've been enjoying using the list so far, now that it works on DDG via uBO :D! I manually added most but not all of the nuclear list to my custom filters, and took the opportunity to experiment with the filters themselves. Removing the
:style(opacity:0.00!important;)part causes the default behaviour (display: none) to take effect, which I've found more convenient, especially for searches with a lot of rubbish results. While the change is a simple matter of search and replace for a manually updated list, I can't really do the same for the main list pulled from the repo.If it's not too much trouble, would it be possible to have versions of the lists provided that don't include the custom style, allowing uBO to completely hide those elements instead? This way, people can choose the one best suited to their preference or search engine (in my testing, DDG looked good without the custom style, but Google looked messy).
Comparison on DDG with and without
:style(opacity:0.00!important;):with:
without (
display:noneis applied by default)The image results in these aren't completely the same, DDG served slightly different results every time I tried ): You'll have to trust me that a bunch of elements are hidden in the second one xP
Speaking of
:style(opacity:0.00!important;), why0.00instead of just0?Unrelated, but not worthy of an issue I think: the nuclear deviantArt, etsy, etc filters are very likely to break other sites as artists often link these in their social media profiles, on their websites, etc, and the filters hide the entire containing div. Perhaps the nuclear list should be amended to specify specific search engines, as was done for dreamup recently?
Also, pinterest has a load of regional domains in addition to .com. In my custom filter, I changed it to
pinterest., which captures those, but is still fairly unlikely to match any non-Pinterest sites.@laylavish commented on GitHub (Mar 3, 2024):
The thing is, without the custom styling, it breaks Google Search if there are too many queries that include AI generated content. See the video below:
https://github.com/laylavish/uBlockOrigin-HUGE-AI-Blocklist/assets/128162304/34e944a2-d3fd-459c-bf7d-2db877b16330
From my testing, DDG & Bing both handle uBlock
display: nonejust fine, just not Google Search weirdly. That's why I opted for the styling, as it fixes Google Search, while also hiding AI away.If you want to block sites on DDG with
display:none, you can try uBlacklist which handles blocking in a similar way. The only difference between the potential uBOdisplay:nonelist and uBlacklist is the procedural filters currently (working on that for uBlacklist too).As for the
0.00instead of just0, I was experimenting with just lowering the offending sites' opacity to a low value, say 0.05, so you would know which one is AI and what is not (if that makes any sense). Instead, I just went with0as the default, since most people (myself included) just want them hidden.Lastly, as you probably noticed, I reverted the change of just hiding the entire div in favor of specifying domains that it would work on (eg. DDG, Google, Bing). Solves a lot of the issues before (and it just makes more sense to me imo). So yeah, now everything is geared to specific search engines. And, yeah i'll add the regional domains of Pinterest too!
@lavafroth commented on GitHub (Jan 8, 2025):
We might be inadvertently selecting the div that lazily loads the next set of images. Consider my filter which blocks images from
facebook.com. You can see the loading spinner. Any new image loaded fromfacebook.comis immediately discarded.Demo: https://youtu.be/LvHJeVEDYF0
Here's the filter
@laylavish commented on GitHub (Apr 30, 2025):
Well, now I just went with
remove(), so now these elements should just be removed outright.