Description

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.
• 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. So we could add, before the content of the SSX, the following line before using the LESS compiler:

@import "style.less.vm";

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:

@import (reference) "style.less.vm";

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 apply. 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:

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.

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.

The first line of the SSX is used to set the preprocessor

The first line of the SSX could be:

## preprocessor = less

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.