store variables in less.vars, please !

[jonasfrey]

i use less client side,
all i want is

document.querySelector("body").style.backgroundColor = less.vars["background-color"];

this is would be so easy

[matthew-dean]

Accessing vars is not out of the question, but your use-case is strange. Why isn't your stylesheet simply styling the body?

[seven-phases-max]

Juts in case adding a few tricky snippets to test this feature when (and if) developed:

#1:

div {
    color: @color;
}

.mixin() {
    @color: red;        
} .mixin;

#2:

@color: darken(@c, 42%);

div.a {
    @c: blue;
    color: @color;
}

div.b {
    @c: green;
    color: @color;
}

.-{@c:red}.-;

#3:

@color: .foo.bar(blue)[];

div {
    color: @color;
}

.foo {
    .bar(@c) {
        return: spin(@c, 180);
    }
}

[matthew-dean]

@seven-phases-max Yeah, I didn't want to get into it with the OP, but essentially you would need to evaluate the full sheet, and then could theoretically access eval'd tree to extract a value.

The reason why I (tentatively) marked it as a 4.0 5.0 milestone, is because, in short: my target for 5.0's "browser" support is to essentially remove in-browser parsing, but allow in-browser evaluation of a pre-generated (and serialized to JS) AST. In-browser parsing has long been a "development-only" feature, and not well-supported. So, by limiting what stages happen in the browser, I think we can counter-intuitively actually expand what's possible in a production browser environment.

So, if you can load a bundle, then eval it, you could optionally then attach it as a stylesheet, or extract values from the eval'd tree (or both).

5.0 is still very early in development, but I just wanted to stick a pin in this as a feature to keep in mind. With the right code path, supporting this would theoretically not add any extra overhead.