Show last authors
1 {{toc/}}
2
3 = Use Cases =
4
5 * **UC1**: Having the LESS features inside an SSX object
6 * **UC2**: Be able to use all the skin's features (mix-ins, variables) in SSX for a good integration with the current skin.
7 * **UC3**: Being able to overwrite a LESS file within a skin object
8
9 = Implementation Ideas =
10
11 == How to deal with the skin ==
12
13 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:
14
15 {{code language="less"}}
16 @import "style.less.vm";
17 {{/code}}
18
19 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).
20
21 So, the code becomes:
22
23 {{code language="less"}}
24 @import (reference) "style.less.vm";
25 {{/code}}
26
27 {{error}}
28 LESS has currently a bug with the (reference) option that concerns us. See https://github.com/less/less.js/issues/1878 and https://github.com/less/less.js/issues/1968 for more details.
29
30 So I have implemented a solution where we manually remove the output of the included file.
31 {{/error}}
32
33 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.
34
35 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>>http://lesscss.org/usage/index.html#command-line-usage-options]]. It should work.
36
37 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>>http://jira.xwiki.org/browse/XWIKI-11394]]).
38
39 == About the SSX object ==
40
41 We have 3 options:
42
43 === Sol1 - Create a new class: LSSX ===
44
45 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.
46
47 === Sol 2 - Add a new property in the SSX object ===
48
49 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.
50
51 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.
52
53 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.
54
55 For colibri, the first SSX will work, but the other will fail.
56
57 === Sol 3 - The first line of the SSX is used to set the preprocessor ===
58
59 The first line of the SSX could be:
60
61 {{code}}
62 ## preprocessor = less
63 {{/code}}
64
65 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.
66
67 === Decision ===
68
69 Personally, I prefer the second solution. It looks easier for a web-developer.
70
71 == Cache ==
72
73 Of course, any SSX object that contains LESS code must be cached.

Get Connected