Last modified: 2014-02-12 23:35:35 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?
(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).
(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.
(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.
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.
