|Open||None||T269044 Support more CSS properties / rules in css-sanitizer|
|Open||None||T162379 Decide which non-standard CSS properties to support in TemplateStyles|
|Open||None||T216897 Add 'width: -webkit-fill-available' to allowed syntax for TemplateStyles|
- Mentioned In
- T250957: TemplateStyles should tell users not to use vendor prefixes when it sees one
T248416: [EPIC] Drop MediaWiki:Mobile.css and MediaWiki:Mobile.js in favor of TemplateStyles
T243996: [Technical debt pay off] Remove MFMobileMainPageCss from MobileFrontend
T203416: Document which CSS properties are supported in TemplateStyles
T205787: TemplateStyles throws inaccurate errors without providing a save-anyway option
rCSSS7775ef2d9c2d: WIP: Support vendor prefixes
T195946: Allow editors to style main page's differently from other pages for performance and to allow creativity (e.g. MediaWiki:Mainpage.css)
T138622: Help community migrate away from legacy Main page special casing
T192612: Design feedback for refined main page of Russian Wikipedia
T188198: Enable TemplateStyles on ruwiki on 2018-04-10
- Mentioned Here
- T228604: Clean up party of Mediawiki:Common.css at Wikimania 2019
P7061 Autoprefixer prefixed properties for Wikimedia sites
A list of sanitization errors for MediaWiki:*.css pages on Wikimedia projects:.
Unsupported properties in the first 50 errors:
-moz-box-shadow, -webkit-box-shadow -moz-linear-gradient, -webkit-gradient, -webkit-linear-gradient, -ms-linear-gradient, -o-linear-gradient, -moz-border-radius, -moz-border-radius-*, -webkit-border-radius, -webkit-border-*-radius zoom (used for IE CSS hacks) -webkit-background-size, -khtml-background-size, -moz-background-size, -o-background-size -ms-filter, filter -o-user-select -webkit-min-device-pixel-ratio -moz-column-count, -webkit-column-count -webkit-column-gap, -moz-column-gap, -ms-column-gap -moz-column-width, -webkit-column-width, -ms-column-width -webkit-column-break-inside -moz-font-feature-settings, -webkit-font-feature-settings cursor: hand -moz-box-shadow, -webkit-box-shadow -webkit-transition, -moz-transition, -o-transition, -ms-transition -webkit-text-decoration, -moz-text-decoration -webkit-background-size -webkit-print-color-adjust <property>: <value>\9;, <property>: <value> !ie;, *<value> (these seem to be old IE CSS hacks) list-style-type: -moz-kannada will-change pointer-events -webkit-background-clip, -moz-background-clip ::-moz-placeholder, ::-webkit-input-placeholder, ::-ms-input-placeholder -moz-box-sizing, -webkit-box-sizing :-moz-first-node
I grepped for prefixed identifiers in Gergő's test file, core's resources/src directory, and oojs-ui's src directory, then cross-referenced them with caniuse.com and/or MDN. I haven't looked through this to try to make any decisions yet.
|animation, animation-duration, animation-iteration-count, animation-name, keyframes||moz o webkit||13.22% need a prefix, mainly -webkit- for UC browser for Android and old versions of Android browser|
|appearance||moz webkit||1.98% unprefixed, all major browsers only support it prefixed|
|arabic-indic, bengali, devanagari, kannada, oriya, persian||moz||list-style-type, supported unprefixed since Firefox 33|
|pashto||moz||list-style-type, but I find no evidence Firefox or any other browser actually supports it.|
|urdu||moz||list-style-type, supported versions not listed at MDN|
|background-clip, background-size||moz o webkit||94.02% unprefixed|
|border-bottom-colors, border-left-colors, border-right-colors, border-top-colors||moz||Non-standard Firefox extension|
|border-*-radius||khtml moz ms o webkit||Only 0.08% need a prefix|
|box, box-flex, box-ordinal-group, box-pack, flex, flex-align, flex-direction, flex-order, flex-pack, flex-wrap, flexbox, inline-box, inline-flex, inline-flexbox, inline-stack, justify-content||moz ms webkit||11.36% need a prefix, mainly -webkit- for UC browser for Android and old versions of Android browser. Both of those are a 2009 version of the spec.|
|box-shadow||khtml moz ms o webkit||Only 0.14% need a prefix|
|box-sizing||moz webkit||Only 0.45% need a prefix|
|break-inside||moz o webkit||It's not clear anyone actually supports -foo-break-inside rather than other things, see MDN|
|calc||moz webkit||Only 0.25% need a prefix|
|calendar-picker-indicator, clear, expand, focus-inner, inner-spin-button, input-placeholder, outer-spin-button, placeholder, search-cancel-button, search-decoration||moz, ms, webkit||Shadow DOM pseudo-element, unlikely to be needed in TemplateStyles|
|selection||moz||Pseudo-element in Selectors 4, although MDN says everyone except Firefox supports it from when it was in the Selectors 3 draft|
|column-break-after, column-break-before, column-break-inside||webkit||Looks like lots would need this. Some -moz- and -o- are used too, but those don't seem to actually exist|
|column-count, column-gap, column-rule, column-width, columns||moz ms o webkit||Hard to tell, but seems like maybe 22% need a prefix? Again, the largest fraction seems to be UC browser for Android|
|device-pixel-ratio, min-device-pixel-ratio||moz o webkit||Unclear, up to around 22% might want -webkit-|
|filter||moz ms o webkit||18.63% need a prefix, mainly -webkit- for UC browser for Android|
|first-node||moz||Non-standard Firefox extension|
|fixed||moz||font-family. Poorly-documented Firefox hack that should die|
|font-feature-settings||moz ms o webkit||16.53% need a prefix, mainly -webkit- for UC browser for Android and old versions of Android browser|
|font-kerning||webkit||20.79% need a prefix, mainly -webkit- for UC browser, iOS Safari, and old versions of Android browser|
|font-smoothing, osx-font-smoothing||moz ms o webkit||No longer in standards-track documents, 36.76% support, everyone needs a prefix|
|full-screen||webkit||Only useful in combination with JS, it looks like|
|grab, grabbing||moz webkit||0% are listed as needing a prefix, but it looks like Chrome still needs -webkit- here|
|gradient, linear-gradient, radial-gradient, repeating-linear-gradient||khtml moz ms o webkit||10.57% need a prefix, mainly -webkit- for UC browser for Android and old versions of Android browser|
|grid||ms||37.01% support at all, 5.69% (all IE/Edge) need a prefix|
|handler-blocked||moz||Non-standard Firefox extension|
|high-contrast||ms||Non-standard IE @media property|
|hyphens||moz ms o webkit||84% support, 23% need a prefix|
|image-set||webkit||Not-yet-standard Webkit feature|
|inline-block||moz||Only 0.02% need a prefix|
|interpolation-mode||ms||Obsolete IE7 and IE8 property|
|isolate, isolate-override||moz ms webkit||No percentages, but MDN makes it look like only old versions of major browsers need prefixes. -webkit-isolate is noted as being actively dangerous.|
|lang||ms||Apparently :-ms-lang() is only needed to enable the comma-separated list syntax from Selectors Level 4|
|list-number||moz||Non-standard Firefox extension|
|marquee-style||webkit||No, this is almost as bad as text-decoration: blink.|
|max-content||moz webkit||78.57% support, 25.37% need a prefix|
|opacity||khtml moz o webkit||0% listed as needing a prefix|
|outline-radius||moz||Non-standard Firefox extension|
|outline-style||moz||Firefox before 1.5|
|page-break-inside||moz o webkit||0% listed as needing a prefix|
|pre-wrap||moz o||Ancient Firefox, -o- is reportedly unneeded since Opera 8.|
|small-control||webkit||Looks like a webkit font hack like -moz-fixed|
|sticky||webkit||68.66% support, 12.19% need a prefix (mostly Safari)|
|tab-size||moz o||Only 9.73% need a prefix, but that's all of Firefox and Opera.|
|text-align-last||moz webkit||66% support, 1.15% need a prefix|
|text-decoration, text-decoration-style||moz webkit||46.76% support, 12.42% need a prefix (mostly Safari)|
|text-fill-color||webkit||Not any spec, but 78.22% support it with a prefix|
|text-orientation||webkit||No percentages, but MDN makes it look like only old versions of Chrome and Firefox|
|text-overflow||o||Only 0.02% need a prefix|
|text-size-adjust||moz webkit||Safari and UC browser need it|
|touch-callout||webkit||Non-standard Safari feature|
|transform, transform-origin||moz ms o webkit||13.17% need a prefix, mainly -webkit- for UC browser for Android and old versions of Android browser|
|transition, transition-duration, transition-property, transition-timing-function||moz ms o webkit||10.56% need a prefix, mainly -webkit- for UC browser for Android and old versions of Android browser|
|use-text-color||moz||Obsolete Firefox extension, removed in Firefox 52|
|user-select||khtml moz ms o webkit||Everyone except Chrome and Opera needs a prefix|
|writing-mode||moz webkit||29.59% need a prefix, mainly -webkit- for UC browser for Android, Safari, and old versions of Android Browser|
UC browser for Android has an annoyingly high level of usage reported on caniuse.com.
For the first pass, I looked at current versions of Chrome, Firefox ESR, Edge, and Safari, and Android browser 4.4.4. That comes out to:
- Implement the intrinsic and extrinsic sizing properties, with prefixes for Safari and Firefox.
- Multi-column, animation, transformation, and filter properties for Android.
- Text decoration properties, position: -webkit-sticky, and -webkit-min-device-pixel-ratio media query for Safari.
- cursor: grab and cursor: grabbing for Chrome.
- appearance: none (and user-select, but that's already in the code) for everyone.
- -webkit-writing-mode for Android and Safari.
- -webkit-hyphens and -ms-hyphens for Edge and Safari.
- -moz-tab-size for Firefox.
Also, technically we should do Grid for Edge, but I don't want to bother with seeing where the old version of the spec differs from the current one.
Keeping in mind there are probably a variety of difficulties and complications I'm not aware of here, it seems to me that any prefixed property which is worth whitelisting, is worth having the parser automatically include when the unprefixed property is used. Having a full-fledged CSS parser seems like a great opportunity to remove the burden of supporting browsers/browser versions which require prefixed properties from style authors (not to mention it greatly simplifies the process of removing prefixed properties as the browsers/browser versions they support drop out of usage).
It is strange that Wikimedia code uses a lot of needed vendor prefixes, but in TemplateStyles they can’t be referenced. It is probably a good decision from the security side, but then you need to use a library like Autoprefixer that would add any needed prefixes for supported vendors for editors. I had, for example, to remove vendor prefix that provided support for user-select even to my browser (latest Firefox) because otherwise saving page with TemplateStyles was impossible.
Compiled a Browserlist rule for this based on available browser matrix for desktop and mobile:
last 2 chrome versions, last 2 firefox versions, edge >= 11, ie 11, opera > 15, safari >= 5.1, ios >= 6.1, android >= 4.1, and_chr >= 48
Don’t know which are not supported in TemplateStyles, I opted to check all of them. If my browser matrix is wrong, you can probably edit it to get it right.
Out of my personal experience in working with TemplateStyles, having flexbox prefixed properties supported as soon as possible is probably the most crucial out of this. column-width/column-count, too, because column layouts are used in Wikimedia sites’ CSS frequently. Hope this helps in fixing this, this is probably the most noticeable hurdle in working with TemplateStyles for me at the moment.
Edit: noticed that I accidentally inserted ios >= 5.0 instead of ios >= 6.1. Would have to redo this, the list would probably be smaller. Update: nothing changed.
For anyone that will decide to do this task: we got consensus in the Russian Wikipedia to improve the main page using TemplateStyles, and the ability to use prefixed CSS properties would be more than welcome addition to see. Right now I intend to add prefixed properties only directly to Common.css/Mobile.css before pushing new version, which would be less than ideal.
I typed this a while ago, but never hit the submit button. It seems phabricator remembered the comment, and since the issue is still current I'll post it now.
@stjn just on an unrelated note caniuse analytics show that support for prefixed vs. unprefixed flexbox properties is nearly an identical audience. Browsers supporting neither is a much larger group. The amount of bugs and browser diversity with unprefixed flexbox is also rather large. As such I think any time is better spent on having good fallbacks using float/inline-boxes (Which should NOT necessarily have to look the same, just be readable and accessible) being actually much more important.
While initially I figured it was unmanageable to not support prefixes, I have since sort of changed my mind and have not run into situations where this seemed to be an actual real world problem that I have to care about it. This does not mean it cannot be a problem, just that the severity and frequency of it seems much reduced to my initial assessment.
We don’t support browsers supporting neither, so there’s no need to care about that (they can just display one-column layout after all in case of Russian Wikipedia). Bugs with flexbox are also manageable and mostly are concerning older IEs, I don’t see how this is an argument against using it.
The main audience for which flexbox prefxies are needed is older iPads, to be honest.
As part of T228604, ran into several things using zoom: 1; which is preventing me from saving the edit in an AbuseFilter-like fashion.
Is there a path forward here to start whitelisting a bare minimum of known totally safe property/value pairs so as to avoid blocking adoption of TemplateStyles and/or requiring clever hacks where part of the styles stay behind in Common.css (which then causes the cascade to be out of sync, and also mis-matching selectors given auto-wrapping of selectors).
Theoretically, Autoprefixer just uses Caniuse data to match it with a required set of browsers, so it might be possible to use it in the same way (raw Caniuse data is just a lot of JSON) but in PHP. The esteemed Somebody Else would have to port the code in the first link to css-sanitizer, however, and keep up with development of Autoprefixer in the future (the latter is easier than the former).
The autoprefixer thing using caniuse looks good. -webkit-text-emphasis is especially a pain in the alias for Chinese/Japanese, as 71% of global users only get support via this prefixed version. Chrome, ya know.
@stjn Someone is going to need to get a CSS parser for PHP to do it, and it sounds like hard work. Maybe someone else can try some interprocess stuff if shell calls are deemed too expensive? (Or is caching enough to justify shelling?)
@Tgr the compatibility stuff is for browsers, not for us. Just because browsers support them doesn't mean we should encourage their use. We are supposed to only use prefixes when a majority of users are stuck with a browser that only supports them, not when writing code for input. It would be actually good to yell at users for using prefixes when we have autoprefixer later.
I thought that the main (or only) reason for sanitization and allow-listing declarations, is security. Thus any vendor-prefixed rule known to be used by notable browsers, useful for end-users, and with no known security risk, seems trivial to add one-off in individual tasks and patches.
Is this task intended to block that in favour of a generalized solution? Or is this a nice-to-have long term exploration? I'm not sure a how a generalized solution could work or exist, but maybe there's a spec or trusted source that I'm not aware of. Or maybe there's a limitation, cost or concern with the current code that makes it not feasible to add these rules individually?
As a user on wiki, I'm personally torn about allowing vendor prefixes in the general (or was it decided somewhere we should?). On one hand, it would be nice to be more slick (and there is at least one other point above about mixed solutions).
OTOH, some reasons I'm not a fan of vendor prefixes:
- I'm still going to be conservative in what I author on wiki (and really, what looks usable is already figured out). Maybe that's just me and others want to forge ahead.
- Corollary to "maybe": As a gnome, I don't really want to clean out unnecessary prefixes a decade down the road.
- Not really a fan of increasing the HTML payload just to handle the vendor solutions, as compressed as it might be.
There is a subset of prefixed properties (called ‘legacy name aliases’ officially if I am not mistaken) that actually made it into spec:
I don’t know how well the list corresponds with the one compiled by me before, but that is one pointer about this. Every browser has to support those -webkit-/-epub- prefixes now, theoretically.