https://bugzilla.wikimedia.org/show_bug.cgi?id=45757
--- Comment #3 from PleaseStand <[email protected]> --- (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. -- You are receiving this mail because: You are on the CC list for the bug. You are the assignee for the bug. You are watching all bug changes. _______________________________________________ Wikibugs-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
