(NSFW) rule34.xxx

[DandelionSprout]

URL(s) where the issue occurs

https://rule34.xxx/index.php?page=post&s=list&tags=thea_sisters+

Describe the issue

De facto placeholder on the right, due to the main-content element being too narrow.

Screenshot(s)

https://images2.imgbox.com/da/b3/wQL2Fpfg_o.png

Versions

• Browser/version: Chrome 87.0.4280.66 x64
• uBlock Origin version: 1.31.1b12 + IDCAC 3.2.5

Settings

Notes

I propose

rule34.xxx##.content:style(width: calc(100% - 220px) !important;)

The current width without this entry is calc(100% - 390px)

This may also apply to some smaller boorus out there, but not to E621, Danbooru nor Gelbooru.

[mapx-]

It's not an ad, not an annoyance .. @okiehsch @gorhill

[uBlock-user]

Sounds like re-styling of the website ?

[DandelionSprout]

My qualified guess is that it was artificially set to calc(100% - 390px) in order to make room for an ad column that must've been blocked many, many years ago.

[gorhill]

The site appears the same with uBO disabled. This is not a case for uBO's lists, restyling sites is not the purpose of any filter lists here.

[InfernalSeraph]

The site appears the same with uBO disabled. This is not a case for uBO's lists, restyling sites is not the purpose of any filter lists here.

Not to contradict you, but for some reason, that's exactly what someone has done (twice now). First it was an Adguard List several months ago, which I disabled because I don't know how to disable individual filters. Now, it's in the uBlock filters list. Line 966: rule34.xxx##body:style(background: #aae5a3!important;)

This breaks dark mode on the site and also styling done outside of ubo. I use Stylus quite a bit to tweak sites, but this code injection somehow precludes any overrides from Stylus. But, more importantly, it directly contradicts the stated purpose that the filter lists should not be restyling sites.

What's even more consternating is the reasoning behind "locking down" the background color. Why would anyone put a rule like that in a filter list for blocking ads?

[Yuki2718]

@InfernalSeraph Hi, this did not contradict the purpose - it was solely added to block clickable ads leading to a third-party site at the time, but the ads went away so now it looks like as if restyling. If you wanna know what kind of ads it were like, I have a very similar example at a Japanese site:

Screenshot


More often than not, network path of this type of ads changes frequently so I prefer :style() than blocking rule, but was not aware of the dark mode issue. Sorry for the trouble and thx in advance for your understanding.

[InfernalSeraph]

@Yuki2718 Thank you for the example and explanation. I hadn't seen ads like that.

Fortunately, both sites (your example and rule34) have CSS variables for the appropriate colors that you can use to compensate for removing the ad image.

On your example, automaton-media.com, --wp-admin-theme-color seems appropriate, while on rule34.xxx, --c-bg is the exact variable you'd want in your rule.

[Yuki2718]

@InfernalSeraph Apparently these variables are not supported in :style() syntax. Anyway I removed the problematic rule. I'll ask AdGuard guys and if they agree the same filter in AG Base will be removed too.

Just found the AG issue shows similar ads: https://github.com/AdguardTeam/AdguardFilters/issues/46545 So apparently these ads are periodically inserted when there's some campaign.

[Alex-302]

Removed obsolete CSS rule.

[gwarser]

Apparently these variables are not supported in :style() syntax.

This works:

rule34.xxx##body:style(background: var(--c-bg) !important)

[Yuki2718]

This works:

Should we re-add the filter with variable? As you see in the AG issue, it's likely they insert ads again.

[InfernalSeraph]

@Yuki2718, as @gwarser's filter shows, the variable needs to be within a var() function. You could even add a fallback color if you were worried the variable itself might be removed or renamed, like:

rule34.xxx##body:style(background: var(--c-bg, #aae5a3) !important)

And CSS variables, even though still not finalized, are implemented and functioning in all major browsers for the past five years or so—thus it should be functional everywhere ubo is supported.

[Yuki2718]

@InfernalSeraph Thx kindly, I'll add your filter. @Alex-302 How about on AG?

[Yuki2718]

https://github.com/uBlockOrigin/uAssets/commit/6cda60f149788436e3396d66c0515d98679c70b0

[gwarser]

Should we re-add the filter with variable? As you see in the AG issue, it's likely they insert ads again.

My comment is only from technical POV. It's your choice.

[Yuki2718]

@gwarser All right, added.

[Alex-302]

@Yuki2718

How about on AG?

Is CSS rule really required? I don't see branded background.

[Yuki2718]

Is CSS rule really required? I don't see branded background.

I see branded background if dark mode was set and the old rule was applied. The new one won't cause that issue and will still block ads as seen in https://github.com/AdguardTeam/AdguardFilters/issues/46545 and a different one I saw when I added the rule - they'll likely to do this again.

[ghost]

@Yuki2718, as @gwarser's filter shows, the variable needs to be within a var() function. You could even add a fallback color if you were worried the variable itself might be removed or renamed, like:

rule34.xxx##body:style(background: var(--c-bg, #aae5a3) !important)

And CSS variables, even though still not finalized, are implemented and functioning in all major browsers for the past five years or so—thus it should be functional everywhere ubo is supported.

I was wondering why a page of raw json content-type had the green background 😄