Opened 11 years ago
Closed 11 years ago
#27078 closed task (blessed) (fixed)
Use Autoprefixer for CSS vendor prefixes
Reported by: | ocean90 | Owned by: | nacin |
---|---|---|---|
Milestone: | 3.9 | Priority: | normal |
Severity: | normal | Version: | |
Component: | Build/Test Tools | Keywords: | has-patch |
Focuses: | Cc: |
Description
Preamble
Autoprefixer parses CSS and adds vendor prefixes to CSS rules using values from the Can I Use.
So instead of prefixing the CSS by ourselves, let Autoprefixer handle this.
Build Tool
For our build process we can use the Grunt plugin grunt-autoprefixer.
Patch
The attached patch does two things:
- Adds the autoprefixer task to Gruntfile.js. The task will run *after* the files are minified. Why? We are still supporting patches from core.svn. So we have to prevent changes in the non-minfied files, otherwise patches won't apply correctly to core.svn or if made from core.svn.
- Removes existing CSS rules which are already prefixed.
Files which should be prefixed are: wp-admin/css/*.min.css, wp-admin/css/colors/*/*.min.css and wp-includes/css/*.min.css. (Third party styles excluded.)
Discussion
What does it mean to just prefix the minified files?
When running a non-build version (or SCRIPT_DEBUG
is true) some admin screens could look a bit broken (I'm looking at Firefox at the moment).
How much do we care about broken admin screens if non-build?
The patch removes the prefixed lines of border-radius
, transition
, background gradients, box-shadow
and transform
. We could also remove the prefixed versions of :-*-placeholder and just use :placeholder. Autoprefixer will handle this too. But having just :placeholder means, that it doesn't work in any browser.
Do we need a watch task for Autoprefixer?
If yes, we have to minify the files too. But what about SCRIPT_DEBUG
?
Which browser versions should we support?
Autoprefixer supports different ways to declare browser support. Either by global usage statistics or version specific. I have decided to use the versions for now:
- Firefox >= 20
- Explorer >= 7
- Chrome >= 20
- Android >= 2.1 (Kindle, …)
- Opera >= 16.0
- Safari >= 6.0
Attachments (3)
Change History (24)
This ticket was mentioned in IRC in #wordpress-dev by ocean90. View the logs.
11 years ago
This ticket was mentioned in IRC in #wordpress-dev by jorbin_work. View the logs.
11 years ago
#4
@
11 years ago
One possible solution to the problem of keeping src running pretty would be to use http://leaverou.github.io/prefixfree/ only in the src directory. This does come at the cost that using two different tools means src and build may not look perfectly the same, but it would allow for us to run src in prettier than IE7 mode while also eliminating prefixes from our core CSS.
#5
@
11 years ago
-prefix-free is cool, but it doesn't solve the problem of making core.svn harder to patch from. I wouldn't mind eventually abandoning core.svn as a place to patch from, but I don't think holding out for a little while longer is a bad thing.
Or, rather, -prefix-free is something we'd need to do for any site using SCRIPT_DEBUG, not just /src.
#6
@
11 years ago
Seems like this is just an intermediate step.
I would much rather we go all-in and use Compass. I just messed around with grunt-autoprefixer + LESS for an hour, I don't think it is mind-blowingly great. Any tool should take care of all weird back-compat-needing properties like opacity
. autoprefixer doesn't touch it, so a mixin is required. Compass does: http://compass-style.org/examples/compass/css3/opacity/
Prefixes: http://compass-style.org/examples/compass/css3/border_radius/
#7
@
11 years ago
Note, that Compass had no stable releases for a more that year: http://rubygems.org/gems/compass/versions
It generate a lot of unnecessary prefixes. For example, border-radius doean’t need prefixes: http://caniuse.com/border-radius
When Fotorama was moved from Compass it save 10 % of their CSS: https://twitter.com/fotoramajs/status/362686759944982528
Also, it doesn’t support a lot of prefixes. No @keyframes prefixes in stable release. No prefixes for selectors. No prefixes for calc() function.
But @wonderboymusic is right, Autoprefixer is only about prefixes and backward compatible is very different task (BTW, opacity never need prefixes). But you can use Compass for compatible tasks and Autoprefixer will clean it outdated prefixes and add prefixes, that it doesn’t support.
But I think, best solution is to add own mixins for backward compatible, because most of IE hacks is very slow (and old IEs are used on very old PC) and in every case we need to think, does this feature is required or we can use graceful degradation (like in border radius, gradients).
#8
in reply to:
↑ 2
@
11 years ago
Replying to nacin:
We haven't really gotten to the point where he develop repo is "runnable" in production.
Which I think isn't a real problem. Why should a develop branch be used in a production environment. Therefore we have our builds.
I think a good first step (as in, we can do it *today*) would be to use autoprefixer as a development tool, not a build tool.
That would be a minimum. But it also means that we have to ignore colors for now.
Versions to consider: whether we support a few more versions back in FF and whether we support the old branch of a Opera. Also, do we care about old mobile Safari? Autoprefixer has a > 1% option, we should at least include whatever's in that.
I'm fine with supporting FF >= 17 and Opera = 12.1. Opera 15 is the first with Blink, so more or less the same as Chrome. Mobile Safari would be iOS. What is old here? For the percentages take a look at http://caniuse.com/usage_table.php or https://github.com/ai/autoprefixer/blob/master/data/browsers.coffee. The > 1%
option wouldn't make a difference with our values.
Replying to jorbin:
One possible solution to the problem of keeping src running pretty would be to use http://leaverou.github.io/prefixfree/ only in the src directory.
Would be an idea, but I think we should try to avoid to bundle another JS lib. Haven't tested the performance yet, but does it work with many (and huge) stylesheets?
Replying to nacin:
I wouldn't mind eventually abandoning core.svn as a place to patch from, but I don't think holding out for a little while longer is a bad thing.
Would be nice to know how many patches are still coming through core.svn. Abandoning core.svn will make things easier - now and in future.
Replying to wonderboymusic:
I would much rather we go all-in and use Compass.
As much I liked Compass in the past I don't want it back. It adds to many mixins and functions which we will not use in cure. And as iskin mentions, Compass adds a lot of unnecessary prefixes.
back-compat-needing properties like
opacity
.
These properties are just hacks in my eyes. Autoprefixer doesn't care about this - which is great, since it's not a prefix, it's a proprietary property.
#9
follow-up:
↓ 10
@
11 years ago
As far as running out of src (which I do for the vast majority of core dev, FWIW) and back-compat and all this Compass talk:
- If a property is still required to be prefixed for use in any browser, we should be judicious about it, as it should be considered experimental and subject to change. I'd actually question if we should really be using it at all, given that being newest-and-shiniest is not our top priority (saying this knowing that 3.8 introduced a good amount of these). So, in those cases, we should be maintaining them by hand, and they should gracefully degrade, anyway. A pre- or post-processor should not play a part in their usage. This means that using a modern browser should give you the final experience when running out of src.
- In cases like opacity, we should not be attempting to make the particular browser(s) that need that "back compat" match. If something doesn't degrade gracefully, we need to fix the issue, not the tooling.
- Compass is beyond overkill, I am not a fan for the reasons listed above, I am not yet convinced of its longevity, and I still have yet to come to believe that a pre-processor is the right choice for the WordPress project.
Also, ocean90 - I'm not sure I totally understand why it has to run after minification - why not just before?
#10
in reply to:
↑ 9
@
11 years ago
Replying to helen:
Also, ocean90 - I'm not sure I totally understand why it has to run after minification - why not just before?
It must only work on .min.css files, otherwise core.svn will have prefixes and develop.svn won't, making CSS patches difficult if not impossible to create, apply, and test. The alternative I proposed is using this as only a development tool for now, versus on build — it puts prefixes directly into src that can then be committed.
But it also means that we have to ignore colors for now.
Nope — while we could use it as a development tool (putting prefixes into src to then be committed), we could also use it as a build tool for colors. It's just two different tasks.
#11
@
11 years ago
I still have yet to come to believe that a pre-processor is the right choice for the WordPress project.
... This is tricky, because depending on who you ask, the answer would range from "YES" to "ABSOLUTELY NOT."
In the end, what any project wants is minified CSS file that will load fast when gzip gets involved. Also, what any project wants is modular code.
*I* (me, my opinion) would be yes, let's go full-bore - I don't feel like 1) we get a huge wave of CSS patches and 2) when we do, it wouldn't be horrendous if the noob provided 17 lines of CSS that one had to convert into Saaaaassssy CSS code. 90% of the PHP patches are stale in Trac right now, and will require being rewritten. 99.9% probably have weird white space that needs fixing.
It's funny that everyone is hating on Compass, because that was one of the selling points of SASS over LESS. (I continue to prefer LESS.) Even if Compass or "unnamed tool" is overkill, it's not used in prod, so shouldn't matter. Any random node module will require dozens of dependencies.
#12
@
11 years ago
BTW, why you speaking only about Sass and LESS? Why not Stylus? It use JS compiler, can be run inside browser as LESS. But it is powerful as Sass and even more (for example, has block mixins to clean media queries).
This ticket was mentioned in IRC in #wordpress-dev by DH-Shredder. View the logs.
11 years ago
#14
in reply to:
↑ 13
@
11 years ago
Replying to ircbot:
This ticket was mentioned in IRC in #wordpress-dev by DH-Shredder. View the logs.
In todays dev chat we have decided to use one Autoprefixer task as a development tool (putting prefixes into src to then be committed) and one as a build tool for colors.
Working on a new patch.
#15
@
11 years ago
27078.2.patch includes the two tasks. autoprefixer:colors
runs after colors
(while writing this I noticed that we can include it in the colors
task too).
autoprefixer:core
adds the prefixes into src and can be run by a committer.
Patch updates also browser support:
- Firefox >= 17
- Explorer >= 7
- Chrome >= 21
- Android >= 2.1
- Opera >= 12.1
- Safari >= 6.0
27078.2-prefixed.patch includes 27078.2.patch + autoprefixer:core
, so that you can see the difference.
#17
@
11 years ago
- Owner set to nacin
- Resolution set to fixed
- Status changed from new to closed
In 27174:
This ticket was mentioned in IRC in #wordpress-dev by jorbin. View the logs.
11 years ago
#20
follow-up:
↓ 21
@
11 years ago
- Resolution fixed deleted
- Status changed from closed to reopened
Safari >= 6.0
Needs Safari 5.0 for iPad 1st gen and iPhone 3GS.
#21
in reply to:
↑ 20
@
11 years ago
- Resolution set to fixed
- Status changed from reopened to closed
Replying to Denis-de-Bernardy:
Needs Safari 5.0 for iPad 1st gen and iPhone 3GS.
Safari in Autoprefixer's config refers to desktop Safari; mobile Safari is iOS. In testing, it makes no actual difference to specify it, because Android 2.1 requires just as many, if not more, -webkit- prefixes.
I think this is great. The discussion points give me some concern and are definitely things we need to discuss.
Patching from core.svn is still something we "allow." I would have to run some queries to see how often patches come from one versus the other. A proper Git mirror is in place now for develop.svn, which means that angle is less of a concern, at least. We would need to make it more prominent, as right now a lot of documentation has still not caught up.
We haven't really gotten to the point where he develop repo is "runnable" in production. Does anyone auto-deploy develop.svnthe way you might do so on your auto-svn-updated site? I still use core.svn on mine. So develop.svn is a higher barrier to entry.
Only working on "build" means that even a pretty good way to run and test WordPress, outside of "src/", would become more difficult to use. Right now all you lose is color schemes and RTL, and of course SCRIPT_DEBUG is forced. Making UI and design "choppy" in src/ is not something I'll enjoy. (I for one develop in src/ primarily, unless I'm doing front-end work.)
I think a good first step (as in, we can do it *today*) would be to use autoprefixer as a development tool, not a build tool. So we have it directly prefix src/. This would have to be done on pre-commit. It can optionally be included in patches. A run of
grunt
would expose any problems before commit. If a committer misses it, it's not a big deal. We can add a test to make sure it runs "clean" (without modifying files). Drawbacks are plenty, but it does take the guess-work and extra thought required out of auto-prefixing for the time being, and then we can figure out where it fits into our build workflow soon.Versions to consider: whether we support a few more versions back in FF and whether we support the old branch of a Opera. Also, do we care about old mobile Safari? Autoprefixer has a > 1% option, we should at least include whatever's in that.