[wp-trac] [WordPress Trac] #22862: Consider a CSS preprocessor
WordPress Trac
noreply at wordpress.org
Wed Dec 12 01:14:35 UTC 2012
#22862: Consider a CSS preprocessor
-----------------------------+------------------------------
Reporter: chriswallace | Owner:
Type: feature request | Status: new
Priority: normal | Milestone: Awaiting Review
Component: Administration | Version:
Severity: normal | Resolution:
Keywords: |
-----------------------------+------------------------------
Changes (by bpetty):
* cc: bpetty (added)
Comment:
From the software architecture perspective, this actually abstracts out
even further.
Obviously, implementing admin (or anything in WP) in SASS or LESS would
require adding at least one of the preprocessors to WP. At it's very basic
level, LESS is definitely the easiest, and is already possible to do from
plugins and themes. However, we're really not just talking about admin-
only here. Whatever solution is in place, it's going to need to give
plugins and themes options as well, and it's likely not going to be
adequate unless it gives at least both options of SASS and LESS, not to
mention CoffeeScript.
What we're really talking about here is an asset management system much
like the Rails [http://guides.rubyonrails.org/asset_pipeline.html asset
pipeline], or the CakePHP [https://github.com/markstory/asset_compress
Asset Compress] plugin, except, WP would probably be best using the
[https://github.com/kriswallsmith/assetic Assetic] PHP library currently
used by most Symfony developers. We're already half way there with
WP_Scripts and WP_Styles. This would just extend those.
The ideal system here would handle not just preprocessing of a variety of
popular formats, but also minification, and combination of both CSS and JS
(as a replacement for what we already do using a Subversion asset
minification bot). It would leave everyone the option of using any
preprocessor they want or not using one at all, so admin could be left in
plain CSS (which Helen has some good arguments for) while a theme might
choose to use SASS markup, and a plugin might include some LESS styles.
The problem with all of this is that any system implementing asset
management (except for a LESS-only system) relies very heavily on either a
high performance persistent cache (which WP rarely has available in almost
all shared environments) or at least write access to a public temporary
directory for serving out generated assets just like most page caching
plugins use so the web server can properly manage expiration and caching.
There are sites where WP works without filesystem write access though
(imagine anyone not using media, or using an S3 media plugin). Without
either of those, the best WP can do is serve processed assets directly
from transients (in other words, PHP/WP initialization and a database hit
for all assets). That would result in terrible performance, and should
never be imposed on anyone.
So with that in mind, I don't think this proposal should even be
considered right now, leaving this to plugin territory for now.
--
Ticket URL: <http://core.trac.wordpress.org/ticket/22862#comment:4>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software
More information about the wp-trac
mailing list