Last modified: 2014-02-12 23:35:35 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 45757 - Offer options on Special:Preferences#mw-prefsection-rendering to disable "annoying" css
Offer options on Special:Preferences#mw-prefsection-rendering to disable "ann...
Status: NEW
Product: MediaWiki
Classification: Unclassified
User preferences (Other open bugs)
1.21.x
All All
: Low enhancement with 1 vote (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2013-03-05 22:27 UTC by Technical 13
Modified: 2014-02-12 23:35 UTC (History)
6 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Technical 13 2013-03-05 22:27:59 UTC
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:

# Allow superscript and subscript (checked by default)
# Allow text shadowing (unchecked by default)
# Allow text scrolling (unchecked by default)
# Allow text blinking (unchecked by default)
# Allow unicode characters (unchecked by default)
# Allow text/background contrast greater than 7:1 (unchecked by default)
     This one could also offer a drop-down selection to change the ratio
# 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?
Comment 1 Kevin Israel (PleaseStand) 2013-03-07 17:49:17 UTC
(In reply to comment #0)
> # 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.

> # Allow text shadowing (unchecked by default)
> # Allow text scrolling (unchecked by default)
> # 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.

> # 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.

> # 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.

> # 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).
Comment 2 Technical 13 2013-03-07 18:07:05 UTC
(In reply to comment #1)
> (In reply to comment #0)
> > # 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.
>
> > # Allow text shadowing (unchecked by default)
> > # Allow text scrolling (unchecked by default)
> > # 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.
 
> > # 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.
 
> > # 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.

> > # 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.
Comment 3 Kevin Israel (PleaseStand) 2013-03-07 20:17:11 UTC
(In reply to comment #2)
> (In reply to comment #1)
> > (In reply to comment #0)
> > > # 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.

> > > # 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.

> > > # 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.
Comment 4 Andre Klapper 2013-03-13 10:28:15 UTC
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. :)
Comment 5 Technical 13 2013-03-13 11:40:44 UTC
(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.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links