Syntax differences

[xdissent]

Is being compatible with the official LESS parser a goal?

[leafo]

It was initially. I haven't been paying attention to the development of the original lately, so I am sure there are differences that I haven't been able to keep track of.

[jtousek]

I've checked it - official Less is far behind this. :)

[xdissent]

One thing that constantly trips me up is the difference between calling mixins with arguments. Official LESS uses @mixin(arg1: 10px, arg2: #fff); while LESSPHP uses @mixin(arg1: 10px; arg2: #fff);. The difference is so subtle that I miss it every time when visually debugging, and there's no mention of the divergence in the docs. Since LESS is relatively new and I'd imagine a lot of people hadn't messed with LESS at all before they started using LESSPHP, it's probably just affecting me personally. Either way, it would be nice to fix or at least note the difference very publicly.

[jtousek]

it should not be a big problem to find it and change it in the source code ;)

[xdissent]

Ok ok I'm forking it now. I've got a few patches to add anyway. I'll send a pull request to leafo in a minute.

[jtousek]

yeah I also have some patches for leafo to add, but I've done it with Less 1.6 so I'll probably wait until final 2.0 is out

[xdissent]

Wait, this thing is actually versioned? =)

[leafo]

xdissent, there is a reason why I use ; instead of ,.

If you recall, a single css property's value can be a comma separated list of things. If you use , as your delimiter for arguments then that limits what you can pass to a function.

eg.

@font-mixin(@family: verdana, arial; @color: blue) { 
    font-family: @family;
    color: @color;
}

.something {
    @font-mixin(helvetica, sans-serif; green);
}

I did the argument passing before official less, so I just decided on ; and brought up the issue but it was apparently ignored.

[xdissent]

Oh oh I see. Wow, good catch. After following the official LESS package since conception, it's become apparent that cloudhead's development cycle is a pretty… frantic? It's always bursts of rapid changes, with more attention to advancements than fixes or issues. And now it looks like he's completely abandoned the Ruby LESS compiler in favor of a very marginally working Javascript implementation. Par for course I guess.

In light of the rationale behind it, I like the semicolon. It would be killer to update the docs to note the difference though.

[leafo]

The docs implicitly demonstrate it, but I will definitely make it more apparent.
http://leafo.net/lessphp/docs/#args

[superstructor]

leafo,

Firstly thank you for writing this port for the PHP community!

You have a point regarding ";" vs "," for argument separation. However I think its more important to have a standard common compatible LESS syntax between implementations. Otherwise users cannot share LESS CSS code between their e.g. PHP (lessphp) and Node.js/JavaScript (less.js) projects. Even more damaging is that it makes it impossible for anyone to provide a common framework, such as SASS has with the compass framework.

Is there any room for improving this situation with an aim of LESS CSS portability between implementations? Or are you sold on using ";" regardless ? Personally I have no preference for either character but I do feel that "," is the more commonly accepted / "official" syntax.

As a person trying to contribute to the LESS CSS framework space, and as a user of both Drupal/Lessphp + Node.js/Less.js my options basically are:

• hope for agreement in the community on a common syntax
• fork lessphp and maintain a less.js compatible version
• fork less.js and maintain a lessphp compatible version
• only support one implementation in the framework, likely less.js & build a less.js based drupal module

I think the first option, having a common syntax, would be of the most benefit to users of LESS overall. Other options are basically stopgap measures if that fails.

xdissent,

Less.js was in early development when you made your comment. Recent versions work very well and I've been using it for several large projects.

[leafo]

You are the first person to contact me about changing it.

I don't know how entrenched the ; is at this point. I don't want to change it outright, but I do feel that , is more natural. I don't know how often people actually pass comma separated values into functions at all to begin with. I could make , and ; both work as argument separators and have an optional compatibility flag that would make it behave like how it does not.

I prefer the ; just because it makes sense, but if it is getting in the way then I will change it. I just don't have any usecases of other people using lessphp though, so it's difficult to make a decision like this.

[superstructor]

Thanks for your thoughtful response.

I think an optional compatibility flag to enable , support would be the best idea under the circumstances for now.

Beyond that , seams more natural from a functions point of view, while ; seams more natural from a CSS point of view. There are several practical example of why ; would be nice such as font-family and colour stops for CSS3 gradients. In these situations you don't know how many fonts or colour stops the user of the mixin might want so allowing , separation within arguments by using ; as the separator helps in these cases a lot.

If it was a fresh spec with no differing implementations and code out in the wild I think ; would be the best. However under the current circumstances it is not so clear. Maybe someone could ask cloudhead but I think you indicated you already tried ? Maybe less.js could have a ; mode compatibility flag...

I agree you can't just break backwards compatibility for your users by changing it outright for the sake of code portability to less.js.

Compatibility flags will at least significantly improve the situation by allowing users choice in LESS parsers and frameworks. Hopefully the situation will improve even more in the future.

Cheers.

[bobdia]

Are there any other syntax or evaluation differences? There should be a section with any differences at the top of the docs.

Compatibility flags sounds like the best you can do if you fix things that cloudhead is not planning to. +1

As for ; vs , I think this can be solved more elegantly if you just add the ability to escape commas in arguments, or a way to delimit each argument with something like quotes or brackets. That would make Ruby-Less code compatible with lessphp, although not the other way around. Hopefully, they will see the light and follow your example.

[Petah]

Please make it compatible with Ruby-Less (the defacto standard)

You could always split parameters by ,@ (a comma the an at symbol), or provide escaping ,

[superstructor]

In my opinion since http://lesscss.org/ has moved to Less.js instead of Ruby the JavaScript-Less is the "de-facto standard", if there is any standard.

Regardless the parameter syntax is the same. Just think its worth mentioning that if there are any differences between the Ruby and JavaScript versions the JavaScript version should be taken as more authoritative.

[greaterweb]

+1 For compatibility mode, this would be pretty useful.

[leafo]

I am going over lessjs right now to find any differences, please tell me if I am leaving anything out.

I see an e built in function that does the same thing as lessphp's unquote built in, so I made an alias.

I noticed that @ mixins were removed entirely, I don't think I will remove them from lessphp, I don't see a reason to. But, lessjs now treats any 'parametric mixins' as what I used to call abstract mixins, meaning they do not show up in the output. I think this is a good idea and I will replicate this. Should I keep the lessphp's existing functionality of outputting the parameterized block if a flag is enabled?

I added all the color functions that lessjs has, I also replicated the behavior of hsl and hsla functions.

And then there is the matter of the argument delimiter. I am going to add support for ,, but I don't know if I should make it default or not. (I will make it configurable during compile time to use the old syntax)

I am also going to update my documentation, and use the same naming conventions as lessjs.

[arnaudgaudin]

Less.js introduced the %() function, which is equivalent to your quote() function. I think you should make an alias for compatibility. I have also detected a critical bug :
https://github.com/leafo/lessphp/issues#issue/56

[Petah]

Re parametric mixins:

Great, having those mixin functions output to the CSS has always bothered me.

[Larandar]

+1 for compatibility mode. Maybe an option ?? Or the > for list argument ?? :
@Maxins ( @param : color1 > color2 > color3 , @Param2 : value ) { .... }

[mgcrea]

About the compatitibility mode, has it been implemented yet ?

[rjmackay]

In regard to the ; vs , difference, there was an issues around that on less.js too:
less/less.js#35

[leafo]

Check the 3.0 branch, https://github.com/leafo/lessphp/tree/0.3.0
It's meant to match lessjs. It isn't finished yet, but the majority of lessjs-style code should work.

[hermiteu]

Thanks for your effort! I'm gonna check out 0.3.0. I was going through all my less files, changing all , to ; , but it was taking to much time and things got a little unclear in some mixins. Glad you're trying to make it compatible.

[hermiteu]

parses fine! Great, thanks for this! Now I can use less.app, less.js en lessphp together.

[MitchellMcKenna]

Amazing work, much appreciate the new compatibility with official less.

One issue I am having is that the following line from twitter-bootstrap is throwing a parse error (didn't you mention you had created an alias for e function?):
filter: e(%("progid:DXImageTransform.Microsoft.gradient(startColorstr='%d', endColorstr='%d', GradientType=1)",@startColor,@endColor)); mixins.less on line 170