#lessphp

Die Werbeagentur Dümmler aus Kevelaer hat einen neuen Blog-Beitrag verfasst. http://www.duemmler.info/blog/wordpress-lessphp-fatal-error/

WordPress: lessphp fatal error

I don't know if you guys have used it, or even have heard about it, but it's something definitely worth considering. I've been using it for quite some time now and it really does make your life with CSS easier. You can read up on it here and download it.

It has a full set of features, but here are the ones I use pretty consistently:

Variables: great for helping maintain the color scheme without remember the hex codes for everything.

Mixins: great for using repetitious code. For example, border-radius and each browser extension of it (-moz, -webkit, -o, -ms).

Nesting (bolded for emphasis): just nest everything like you are used to in other languages.

Because LESS is a javascript library to do this stuff, the page might load before the styles are fully rendered. To help avoid this, and to keep your css in a manner that does not require javascript, you have the option to use lessphp. This will compile the code and deliver the css file and I've never had an issue of the page loading before the styles were done. I also prefer to compress the file so it's much less load on the server and user.

Here's a code snippet of how I use lessphp. Put this in a file called styles.php (for example):

<?php if(extension_loaded('zlib')) ob_start('ob_gzhandler'); header("Content-type: text/css"); include "css/lessc.inc.php"; $less = new lessc; echo $less->compileFile("css/styles.less"); if(extension_loaded('zlib')) ob_end_flush(); ?>

However you chose to use it, I'm sure it'll make your life easier.

I discovered LESS after adopting Bootstrap for my personal website. LESS extends traditional CSS syntax, adding dynamic behavior via variables, mixins (reusable chunks), and nested rules among others. Less.js is probably the best known implementation of LESS, however there are LESS compilers for various other languages, including lessphp. This means that LESS can be incorporated within existing architectures without the need to adopt Node.js. Also, all existing CSS files are also valid LESS files so it is possible to incrementally add LESS markup to a code base after enabling LESS, (note that LESS will transform pure CSS too though).

Adding dynamic behavior to CSS is an attractive proposition, but the adoption of LESS requires some careful thought. The concerns that emerged during our conversations in the office boiled down to:

The introduction of a compilation step since LESS needs to be interpreted and transformed into regular static CSS.

Future proofing for a world where LESS is possibly no longer supported.

The introduction of a disconnect between the code being written in LESS and the corresponding CSS being interpreted by the browser.

The compilation is the biggest concern, so here is a look at our options.

Introducing a Compilation Step

It turns out LESS compilation is slow. After exercising LESS with some real files (mostly static CSS, with little flourished of LESS), it became evident that the time taken to compile LESS is nontrivial; taking around 1 second to compile the CSS needed for the top page of Wonderwall for example.

It is well documented that client side compilation via Node.js is not practical, but it is worth reemphasizing that client side interpretation is out of the question. The end user cannot suffer as a result of increased page weight or rendering time, especially not solely to diversify our code base! With this in mind, we have three options:

The first time a LESS/CSS file is requested from the browser, we compile it, serve it, and cache it. We would do this both in development and production. It'd make the initial request slower, but not that much slower, and it would happen infrequently. The LESS and compiled CSS versions would be essentially the same file; only the LESS file would be under version control. The CSS version would be transient, only living in the cache.

In development we do on demand compilation as in #1, but in production we make the LESS compilation part of our deployment/build script. So our production servers would have the compiled CSS and not incur the performance hit of #1. Again, only the LESS version of the files would be under version control. The CSS version would exist in cache in development and on the filesystem/cache in production.

Compiled CSS in production like #2, but with some kind of gross manual compilation step in development. We would have both CSS and LESS files under version control and have an added disconnect of editing a different file from the one we're including in our templates.

Right now, we're weighing up #1 and #2, leaning towards #1 for simplicity. We need to get some metrics around the frequency of cache population before we roll it out though.