(In reply to christian from comment #0)

For users that have CSS disabled (but JavaScript enabled)

o_O
...that's a thing?

This is caused by the workaround for bug 61852. I guess we could set a time limit and treat it as a loading error after that. But in general I don't think it's reasonable to expect the site (any site, really) to work with CSS disabled an JS enabled. Had we not this workaround in place, MediaViewer would simply load (and it would be completely useless without CSS, of course).

Middle-clicking (loading in a new tab) should work as a workaround, FYI.

(In reply to Tisza Gergő from comment #1)

(In reply to christian from comment #0)

For users that have CSS disabled (but JavaScript enabled)

o_O
...that's a thing?

“a thing” as in “a real bug that is affecting people”?
Yes, it is affecting me on enwiki.

“a thing” as in “affecting the majority of wmf user base”?
No, probably not.

But in general I don't
think it's reasonable to expect the site (any site, really) to work with CSS
disabled an JS enabled.

I disagree.

CSS is a way to separate content from presentation.
Some visually impaired people are using this separation and turn off
author's choice of presentation while still using the content.
For wikipedia, it allows them to have the article text at full browser
width at any zoom level.
This is helping them a lot to consume articles.

Since CSS and JavaScript are separate things, I do not see a reason
why we'd expect them to additionally turn off JavaScript, if they only
want to turn off CSS. YMMV.

Mass-removing the Multimedia tag from MediaViewer tasks, as this is now being worked on by the Reading department, not Editing's Multimedia team.