1
|
|
|
<?php |
|
|
|
|
2
|
|
|
|
3
|
|
|
require __DIR__ . '/vendor/autoload.php'; |
4
|
|
|
|
5
|
|
|
/** |
6
|
|
|
* lesserphp |
7
|
|
|
* https://www.maswaba.de/lesserphp |
8
|
|
|
* |
9
|
|
|
* LESS CSS compiler, adapted from http://lesscss.org |
10
|
|
|
* |
11
|
|
|
* Copyright 2013, Leaf Corcoran <[email protected]> |
12
|
|
|
* Copyright 2016, Marcus Schwarz <[email protected]> |
13
|
|
|
* Licensed under MIT or GPLv3, see LICENSE |
14
|
|
|
* @package LesserPhp |
15
|
|
|
*/ |
16
|
|
|
|
17
|
|
|
/** |
18
|
|
|
* The LESS compiler and parser. |
19
|
|
|
* |
20
|
|
|
* Converting LESS to CSS is a three stage process. The incoming file is parsed |
21
|
|
|
* by `lessc_parser` into a syntax tree, then it is compiled into another tree |
22
|
|
|
* representing the CSS structure by `lessc`. The CSS tree is fed into a |
23
|
|
|
* formatter, like `lessc_formatter` which then outputs CSS as a string. |
24
|
|
|
* |
25
|
|
|
* During the first compile, all values are *reduced*, which means that their |
26
|
|
|
* types are brought to the lowest form before being dump as strings. This |
27
|
|
|
* handles math equations, variable dereferences, and the like. |
28
|
|
|
* |
29
|
|
|
* The `parse` function of `lessc` is the entry point. |
30
|
|
|
* |
31
|
|
|
* In summary: |
32
|
|
|
* |
33
|
|
|
* The `lessc` class creates an instance of the parser, feeds it LESS code, |
34
|
|
|
* then transforms the resulting tree to a CSS tree. This class also holds the |
35
|
|
|
* evaluation context, such as all available mixins and variables at any given |
36
|
|
|
* time. |
37
|
|
|
* |
38
|
|
|
* The `lessc_parser` class is only concerned with parsing its input. |
39
|
|
|
* |
40
|
|
|
* The `lessc_formatter` takes a CSS tree, and dumps it to a formatted string, |
41
|
|
|
* handling things like indentation. |
42
|
|
|
*/ |
43
|
|
|
class lessc extends \LesserPhp\Compiler |
|
|
|
|
44
|
|
|
{ |
45
|
|
|
|
46
|
|
|
// for compatibilty reasons with older copies of lessphp |
47
|
|
|
} |
48
|
|
|
|
The PSR-1: Basic Coding Standard recommends that a file should either introduce new symbols, that is classes, functions, constants or similar, or have side effects. Side effects are anything that executes logic, like for example printing output, changing ini settings or writing to a file.
The idea behind this recommendation is that merely auto-loading a class should not change the state of an application. It also promotes a cleaner style of programming and makes your code less prone to errors, because the logic is not spread out all over the place.
To learn more about the PSR-1, please see the PHP-FIG site on the PSR-1.