Description

• Use Cases
• Implementation Ideas
  • How to deal with the skin
  • About the SSX object
    • Sol1 - Create a new class: LSSX
    • Sol 2 - Add a new property in the SSX object
    • Sol 3 - The first line of the SSX is used to set the preprocessor
    • Decision
  • Cache

Use Cases

• UC1: Having the LESS features inside an SSX object
• UC2: Be able to use all the skin's features (mix-ins, variables) in SSX for a good integration with the current skin.
• UC3: Being able to overwrite a LESS file within a skin object

Implementation Ideas

How to deal with the skin

For UC2, we need to include the LESS file of the current skin in any SSX object. So we could add, before the content of the SSX, the following line before using the LESS compiler:

But we do not want to have all the CSS classes of the skin written in every SSX! Fortunatly, we can use the "reference" option of the LESS Compiler to include it, but without adding the imported styles to the compiled output (see: http://lesscss.org/features/#import-options-reference).

So, the code becomes:

But we have an other problem. style.less.vm needs to be executed with velocity to initialize some variables (mainly about color themes) but right now, velocity is NOT executed on imported files. It is intended, because some collisions could happen between the LESS and the Velocity Syntax. So, to be able to integrate any LESS library, we do not execute Velocity on imported files and I don't think we should change that behaviour.

What can we do is creating a new temporary directory, in which we write the velocity output of the imported file, and then execute the LESS compiler on the SSX with that new temporary directory as an include path. It should work.

For UC3, the same solution could be applied. If the skin document overwrites a file, we can put this file in that temporary directory and when LESS will look for an "example.less" file, it will look in that temporary directory BEFORE looking at the regular directory (it was first explained there).

About the SSX object

We have 3 options:

Sol1 - Create a new class: LSSX

Instead of modifying the SSX implementation, we can create a LESS Stylesheet Skin extension (LSSX) that would have the same behaviour except that it will use the LESS compiler.

Sol 2 - Add a new property in the SSX object

This new property would be called "CSS pre-processor" and the user would be allow to select between: "none", "less", "sass", or any new language that we want to support in the future.

Problem: if a skin does not have LESS variables, the compilation will fail. This means that an extension using this new system will no more be compatible with Colibri.

A solution for that would be to have 2 SSX objects in the extension. One with old CSS code for Colibri (prefixed by .skin-colibri), and one with the LESS code.

For colibri, the first SSX will work, but the other will fail.

Sol 3 - The first line of the SSX is used to set the preprocessor

The first line of the SSX could be:

The values could be "none" (default), "less", "sass" or anything else in the future. It has the benefit that this syntax could be used in files and not only on SSX object.

Decision

Personally, I prefer the second solution. It looks easier for a web-developer.

Cache

Of course, any SSX object that contains LESS code must be cached.