Page MenuHomePhabricator

Offer options on Special:Preferences#mw-prefsection-rendering to disable "annoying" css
Open, LowPublicFeature

Description

I would love to see a section on Special:Preferences#mw-prefsection-rendering that allows people to opt-in/out to often seen as "annoying" text effects. I am thinking along the lines of a box of check-boxes to:

  1. Allow superscript and subscript (checked by default)
  2. Allow text shadowing (unchecked by default)
  3. Allow text scrolling (unchecked by default)
  4. Allow text blinking (unchecked by default)
  5. Allow unicode characters (unchecked by default)
  6. Allow text/background contrast greater than 7:1 (unchecked by default) This one could also offer a drop-down selection to change the ratio
  7. Allow animation in *.gif images

Drop-down range for minimum and maximum font size in regular text

I would start it at 9pt minimum and 16pt maximum.
Allow the minimum size to go as small as 6pt.
Allow the maximum size to go as large as 36pt?

Version: 1.21.x
Severity: enhancement
See Also:
https://bugzilla.wikimedia.org/show_bug.cgi?id=18854

Details

Reference
bz45757

Event Timeline

bzimport raised the priority of this task from to Low.Nov 22 2014, 1:21 AM
bzimport set Reference to bz45757.
bzimport added a subscriber: Unknown Object (MLST).

(In reply to comment #0)

  1. Allow superscript and subscript (checked by default)

There are plenty of legitimate uses for these, so I don't see the point of adding yet another user option.

  1. Allow text shadowing (unchecked by default)
  2. Allow text scrolling (unchecked by default)
  3. Allow text blinking (unchecked by default)

Possibly, though once the specific CSS properties are identified, they could certainly be overridden using user CSS. Again, no change to core MediaWiki is required for this.

  1. Allow unicode characters (unchecked by default)

This has nothing to do with CSS, and at least the seemingly obvious solution of stripping all characters above U+007F would be unusable on most non-English wikis. Also, some English words (e.g. résumé), as well as IPA pronunciations, contain (or can contain) such characters.

  1. Allow text/background contrast greater than 7:1 (unchecked by default) This one could also offer a drop-down selection to change the ratio

This is ridiculous. Black text on a white background is 21:1 contrast, according to http://juicystudio.com/services/luminositycontrastratio.php . And it's not something that's easy to analyze on the server.

  1. Allow animation in *.gif images

Theoretically, it should be simple and quick to remove everything but the first frame on the fly. However, the current image serving architecture likely would require storing a separate thumbnail of each animated GIF on the server, which would consume additional disk space.

Drop-down range for minimum and maximum font size in regular text

I would start it at 9pt minimum and 16pt maximum.
Allow the minimum size to go as small as 6pt.
Allow the maximum size to go as large as 36pt?

This is really the only part that might make sense, although in my understanding, anyone using such an option would not benefit from the parser cache (as in waiting 30 seconds for the Barack Obama article to load).

(In reply to comment #1)

(In reply to comment #0)

  1. Allow superscript and subscript (checked by default)

There are plenty of legitimate uses for these, so I don't see the point of
adding yet another user option.

  1. Allow text shadowing (unchecked by default)
  2. Allow text scrolling (unchecked by default)
  3. Allow text blinking (unchecked by default)

Possibly, though once the specific CSS properties are identified, they could
certainly be overridden using user CSS. Again, no change to core MediaWiki is
required for this.

It would not be difficult to implement a !locked in the skin style sheets that works in a way similar to how !important use to work in CSS1.

  1. Allow unicode characters (unchecked by default)

This has nothing to do with CSS, and at least the seemingly obvious solution
of stripping all characters above U+007F would be unusable on most non-English
wikis. Also, some English words (e.g. résumé), as well as IPA pronunciations,
contain (or can contain) such characters.

My concern with these characters are the ones that don't render and leave horrible little squares with a number inside of them. If a list could be made of what unicode characters do load with what browsers on what operating systems, then the "problem" characters could be easily removed.

  1. Allow text/background contrast greater than 7:1 (unchecked by default) This one could also offer a drop-down selection to change the ratio

This is ridiculous. Black text on a white background is 21:1 contrast,
according to http://juicystudio.com/services/luminositycontrastratio.php .
And it's not something that's easy to analyze on the server.

I apologize, I was not clear. What I meant was LESS than 7:1. I want more readability and uses of #FCFCFC characters on a #FFFFFF background are highly annoying and disruptive.

  1. Allow animation in *.gif images

Theoretically, it should be simple and quick to remove everything but the
first frame on the fly. However, the current image serving architecture likely
would require storing a separate thumbnail of each animated GIF on the server,
which would consume additional disk space.

I've seen this done on other sites with no extra disk space being used or exceptional processing load time added (it actually made the page load faster), and I would be happy to research and post what I find as to how they did it.

Drop-down range for minimum and maximum font size in regular text

I would start it at 9pt minimum and 16pt maximum.
Allow the minimum size to go as small as 6pt.
Allow the maximum size to go as large as 36pt?

This is really the only part that might make sense, although in my
understanding, anyone using such an option would not benefit from the parser
cache (as in waiting 30 seconds for the Barack Obama article to load).

The key words here are "in regular text". By this I meant all headings excluded. I don't see this as difficult or an issue.

(In reply to comment #2)

(In reply to comment #1)

(In reply to comment #0)

  1. Allow text shadowing (unchecked by default) [...]

Possibly, though once the specific CSS properties are identified, they could
certainly be overridden using user CSS. Again, no change to core MediaWiki is
required for this.

It would not be difficult to implement a !locked in the skin style sheets
that
works in a way similar to how !important use to work in CSS1.

This could go in a separate ResourceLoader module, provided that the inline CSS does not use !important, and should not require further fragmenting the parser cache.

  1. Allow unicode characters (unchecked by default)

This has nothing to do with CSS, and at least the seemingly obvious solution
of stripping all characters above U+007F would be unusable on most non-English
wikis. Also, some English words (e.g. résumé), as well as IPA pronunciations,
contain (or can contain) such characters.

My concern with these characters are the ones that don't render and leave
horrible little squares with a number inside of them. If a list could be
made
of what unicode characters do load with what browsers on what operating
systems, then the "problem" characters could be easily removed.

Character support depends on the set of fonts installed, not just on the browse and OS, so server-side detection isn't really feasible. Users would have to configure the character ranges manually.

  1. Allow animation in *.gif images [...]

I've seen this done on other sites with no extra disk space being used or
exceptional processing load time added (it actually made the page load
faster),
and I would be happy to research and post what I find as to how they did it.

By "additional disk space", I'm referring to the same issue with different sizes of thumbnails: that all are currently cached, even if used infrequently, though it might not be a problem, depending on how many animated GIFs there are. I'm not sure whether the transformation can be done at the caching layer to avoid this.

Drop-down range for minimum and maximum font size in regular text [...]

The key words here are "in regular text". By this I meant all headings
excluded. I don't see this as difficult or an issue.

em/percentage sizing would be problematic unless the replacement process actually understands how HTML element nesting works. Currently, installations that use HTML Tidy to clean up the HTML don't have to care. (I'm referring to Sanitizer::removeHTMLtags(), which uses a simple regex if $wgUseTidy is true, as it is on Wikipedia.)

Also, for this to work reliably, the shorthand font property and the deprecated font element would have to be identified and correctly interpreted as well. Consider this HTML fragment:

<font size="+1"><span style="font: 1.5em serif;">foo</span></font>

I don't consider the potential benefit to be worth the development effort (and possible performance impact) involved. This also applies to the contrast ratio calculation.

I'm tempted to close this report as INVALID, not because the request is invalid but because it covers a lot of different things in only one report, which likely makes it impossible to ever close this request as FIXED.
One request per report only, please. :)

(In reply to comment #4)

I'm tempted to close this report as INVALID, not because the request is
invalid
but because it covers a lot of different things in only one report, which
likely makes it impossible to ever close this request as FIXED.
One request per report only, please. :)

The request is for a sectional box on the appearance preference tab. Getting the box with some of the things would be a start, then I would be happy to create separate reports to add more things.

Aklapper changed the subtype of this task from "Task" to "Feature Request".Feb 4 2022, 11:13 AM
Aklapper removed a subscriber: wikibugs-l-list.