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" notifications@github.com 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?