noai.duckduckgo.com shows a HUGE duck

[Mæstro]

removed (commented out) in userContent and site works
View Source shows most (all?) SVG have a viewbox

Could you please explain how to do this in more detail? I have heard vaguely before about ‘usercontent’ having to do with CSS, but that is as far as my knowledge goes.

[Lucio Chiappetti]

1) I went to .moonchild productions/pale moon/xxxxxxx.default/chrome in my profile, edited userContent.css and added the code supplied by vannilla (to enable)

2) I went to the same file and enclosed such code between /* ... */ (java style comments) to disable (but keeping "historical track")
I confess I had to look another file to verify the necessary comment style (could not remember if #, // or /* ... */ )

[Mæstro]

1) I went to .moonchild productions/pale moon/xxxxxxx.default/chrome in my profile, edited userContent.css and added the code supplied by vannilla (to enable)

2) I went to the same file and enclosed such code between /* ... */ (java style comments) to disable (but keeping "historical track")
I confess I had to look another file to verify the necessary comment style (could not remember if #, // or /* ... */ )

Applying Vannilla’s code works on one of my test sites for removing the LLM summary button, but not the giant @ button lower on that page or the SNS icons on my other test site, both when viewed with website.net * * block in µBlock. That this solution works in part suggests that usercontent.css rules of some sort should work, but when I open the inspector and click on any of the surviving, offending SVG icons, nothing happens, and it is hard to wade through the source code to tell which entries they are so they can be targeted.

[Moonchild]

There's nothing wrong with SVG having a viewbox; it just specifies the internal viewing frame of the SVG. What is wrong is if websites assume the dimensions in the viewbox also automatically mean the external dimensions of the image object of the SVG; they don't.

[Mæstro]

There's nothing wrong with SVG having a viewbox…

I think the problem, from my perspective, is that µBlock does not classify SVG as ‘images’, so µBlock permits them to pass even if I have specified to block pictures and all resources. This leaves me without any way to get rid of them if I do not want them. Perhaps I could rephrase my question as ‘how can I create a cosmetic filter in µBlock which will hide any SVG (in buttons or otherwise) on a given site?’ Rules which I suppose ought to work, like https://bang-dream.bushimo.jp##svg or https://bang-dream.bushimo.jp##.svg, have no effect.

[adoxa]

Using the filter bang-dream.bushimo.jp##svg does remove the SVG elements on that page, but that's only the icons in the social media (OFFICIAL) buttons.

[Mæstro]

Using the filter bang-dream.bushimo.jp##svg does remove the SVG elements on that page, but that's only the icons in the social media (OFFICIAL) buttons.

Thank you, this settles my SVG problems! A corresponding filter on HowToGeek suppresses the buttons on that site, too.

[Moonchild]

I think the problem, from my perspective, is that µBlock does not classify SVG as ‘images’

Bit of a tangent.
SVG is a graphics format but it operates in a grey area from a web technology perspective, because it's structured XML so is parsed as a document but the layout object will ultimately be an image object and behave like an image (mostly). This is why some people thought it was a good idea to blur the lines even more and allow e.g. CSS commands to influence the definitions inside the SVG (and apparently take data from the SVG's XML to influence layout outside the SVG, which seems to be the problem here), i.e. chasing document-like integration from an image object.