Option to prefix functions?

[stevenvachon]

I'm using Myth with Less.js and would prefer to use the CSS spec of color() and not Less.js'. I'd also prefer not to muck up my code with "tilde quotes":

color: ~"color( var(--header-color) blend(var(--header-color-dark) 50%) )";

I see this as being similar to the strictMath option.

Essentially, I'd like to use Less.js mainly for its nesting ability only.

Edit:
Actually, I need data-uri(), so disabling options is not a great idea. New idea in following comment.

[stevenvachon]

Prefixing functions would be a great way to avoid issues like the one outlined above and would more clearly differentiate Less.js functions from native CSS functions, much like is achieved with jQuery through $. By making this feature optional, backwards compatibility would not be affected.

Setting prefixFunctions option to true would change things like:

color: color()

to:

color: _color()

[seven-phases-max]

Some people (e.g. me) don't like "underscore bloated" code for its dirty look. Actually Less already has a solution for ambiguous function names (e.g. contrast): if Less function can't handle provided arguments the whole statement outputs "as is" (e.g. filter: contrast(100%); will compile to filter: contrast(100%);).

I think we could do the same for color function as soon as the corresponding standard (CSS Color Module Level 4?) is past its earlier draft. For the moment it's difficult to decide if this will do the trick though as they may change the syntax yet.

[stevenvachon]

This is where a bloatFunctionsWithUnderscores option would allow for Less.js and Myth to play together more nicely and with more future-proofing. I don't use nearly as many Less.js functions now that I have Myth, so my code would be largely unaffected.

[lukeapage]

Another example of something that could be achieved in the future with a plugin in v2

[lukeapage]

(it doesn't seem like a core concern at the moment) though its an interesting idea

[stevenvachon]

I've heard that v2 syntax will be {{ }} encapsulated, which would completely solve this issue.. When can we expect v2, anyway?

[stevenvachon]

Hello?

[lukeapage]

No there are no plans for {{ }}
Most of the 2.0 changes are around api and plug-in. It should be possible
in 2.0 to write a future proof plugin that prepend s _ to every function.
See the 2.0 pull request for more information.
On 26 Aug 2014 16:52, "Steven Vachon" [email protected] wrote:

Hello?

—
Reply to this email directly or view it on GitHub
#2102 (comment).

[stevenvachon]

Running into this issue again but with cssnext.

http://lesscss.org/usage/#plugins-for-plugin-authors does not mention whether access is given to Less' core functions/methods. I haven't yet started any dev on it, but may have to for my current project.

[seven-phases-max]

http://lesscss.org/usage/#plugins-for-plugin-authors does not mention whether access is given to Less' core functions/methods.

Nothing there is write-protected so it's not a problem to remove core color function within a plugin.

[stevenvachon]

Won't that cause issues with mixins, though? They could be provided by a dependency. Is there a way to prefix the function only in a css context?

[seven-phases-max]

Won't that cause issues with mixins, though?

Mixins? You mean, will it break a code that uses Less's color? Sure, it will.

Is there a way to prefix the function only in a css context?

Define "CSS context". Less functions can be used everywhere CSS functions can, so there's no "non-CSS context" (or in other words, any CSS code you pass through the Less (except @import (inline)) is in "Less context").

[stevenvachon]

I was hoping to force the use of underscore prefixed functions outside of mixins only. Mixins should still support unprefixed. It makes sense that this wouldn't be possible.

[seven-phases-max]

It's possible to do the opposite (i.e. limit your nextcss code to a certain scope) if using "the other" plugin format:

& {
    @plugin "your-disable-color-plugin.js";
    // here goes the code (including imports) where you want `nextcss` `color(...)`
}

where your-disable-color-plugin.js would be something like
(since there it's easier to overwrite/override the core function by "do nothing" version instead of removing it):

functions.add("color", function() {});

(or so, honestly I did not used this plugin format yet).

[stevenvachon]

Interesting, but the goal is to provide a means of keeping the Less CSS code as future-CSS-like as possible -- meaning that @plugin is litter.

I suppose that I could write a new color function that looks for differing arguments and either returns literal input or uses existing functionality. Sounds like a can of bugs, though.

[stevenvachon]

Published less-plugin-future-compat.