Properties Merging and Transform

[SomMeri]

Transform in latest Firefox and Chrome does not work if transformations are separated by comma. It works only if they are separated by space. You can try it here:

• fiddle http://jsfiddle.net/yGe9u/3/
• full example: https://gist.github.com/SomMeri/8080666

Transform for yellow square is space separated and the square is skewed and rotated. Transform for red square is comma separted and and the square is unmodified.

Specification http://www.w3.org/TR/css3-transforms/#svg-transform-list says that comma should be accepted too, but it is not the case right now.

Note: personally, I do not need it to work, but lesscss.org says that it is working.

[seven-phases-max]

It's sad. Properties like transition and background still need commas for merging so this means we need two syntax variants...

[SomMeri]

And shadow-box needs both .

I guess it is too late for this:

• property-name+: for spaces,
• property-name,: for commas

But maybe we could do this:

• property-name+: for commas (as is now),
• property-name_: for spaces

Or this:

• property-name+: for commas (as is now),
• property-name+(,): for commas (consistency sake),
• property-name+( ): for spaces

[lukeapage]

what is shadow-box? do you mean box-shadow? I think that just needs comma since it wouldn't make sense to compose different parts of a single shadow in different places.

okay so I've been against this in the past but what are the downsides of just making the code use the right seperator depending on property?

downside we need to code for properties that don't support comma, but since it is one property at the moment and we could default to comma, which I hope will be the most likely in future?

I don't think the above syntaxes look very pretty and we didn't come up with anything better when we were doing the feature.

alternatively we could also allow passing in the list of properties that use spaces if we want to be forward thinking, though I also don't like having so many options...

[matthew-dean]

okay so I've been against this in the past but what are the downsides of just making the code use the right seperator depending on property?

Probably knowing all the properties where we'd need to do this. Right now it's property dumb. Also, CSS is a styling language for SVG. Not sure about other markup languages. I don't personally like the additions to +:

[SomMeri]

I meant box-shadow.

I think it would be better to have different symbol for space separated values, if we can come up with an acceptable one. Less being property dumb is good thing, especially since properties are going to be interpolated.

The risk of having special behavior for transpose is that the space may later on turn out to be needed in situations we do not think about now.

If that happen, we would have to solve exactly the same problem as we have now, except harder. Plus + would already generate both space and comma. It would be impossible to come back to simple behavior, so we would have no really good options then.

Another suggestion:

• property-name++: for space.

I like the current property-name+:, it is very good match for properties merge feature, so I'm trying to find somethink that will not modify it much.

[seven-phases-max]

property-name^:
property-name.:
property-name‾:
Yes, unfortunately all other symbols look artificial when compared to just perfect +:.

[SomMeri]

• property-name+_:

The idea is to use +, because it is good syntax and then suggest space by _ which is closest non whitespace symbol to space.

• property-name|: - as in concatenate?

[lukeapage]

I think +_ is the best of the bunch

spaces will I think continue to be used as the bottom level seperator and comma as a higher level seperator - I think the w3c would be crazy to come up with a property like

new-property: red, gradient() blue, gradient(); // very confusing!
background: red gradient(), blue gradient();

for that reason I think its very unlikely you would ever want to use both space and comma seperators on the same property - how would you merge which one in the comma seperated list you want to merge with the space seperated one?

So I think it won't work being able to use 2 different seperators on the same property. I also think its strange transform ended up around space - that limits transforms to never be a space seperated list, a transform has to be 1 entity - I guess that makes sense because the entity is a function with comma seperated values (maybe why people use spaces - to distinguish from the "function" argument list.

so.. I still think we aren't backing ourselves any more into a corner by looking at the property.

on the other hand +_ isn't that bad.

[matthew-dean]

@lukeapage You're not wrong about transforms. The fact that you can't simply declare:

rotate: 45deg;

...is a forehead slapper, especially considering how granular backgrounds and borders can be declared. Transform is essentially a "long-form" property, with no short form, so this is one of more frustrating parts of CSS to be sure.

+_ is still awkward, but I have no better option. We could go back to flags (!merge(space)?), but that's uglier than the genius +: that was eventually decided upon.

So, like you, I think it's kind of weird syntactically, but not so bad that we shouldn't help solve this particular issue, since we've already providing merging with commas. Let's put +_: on the table for a bit and see if anything better surfaces. If not, 👍

[matthew-dean]

On the other hand... What I just said prompted an idea. I said it's too bad you can't declare:

rotate: 45deg;

In the words of the brilliant Oscar-winning film "The Core", but what if you could?

.rotate() {
  rotate: rotate(45deg);
}
.scale() {
  scale: scale(1.2);
}
.my-element {
  rotate();
  scale();
  transform: merge(" ", rotate, scale);
}
//output
.my-element {
  transform: rotate(45deg) scale(1.2);
}

Basically, the merge function is a basic concatenation function, using the values of specified properties, and removing the referenced properties from output. (I wouldn't call it "concat" because of the property removal it performs as well.)

[seven-phases-max]

@matthew-dean but does such "merge" differ from:

.rotate() {
    @rotate: rotate(45deg);
}
.scale() {
    @scale: scale(1.2);
}
.my-element {
    .rotate();
    .scale();
    transform: @rotate @scale;
}

?

[matthew-dean]

@seven-phases-max Touché. lol. You are correct. So... wait, why did we need +: again?

[seven-phases-max]

+: is just an abstraction and syntaxic sugar:

.black-box-1() {
    transform+: rotate(45deg);
}
.black-box-2() {
    transform+: scale(1.2);
}
.my-element {
    .black-box-1();
    .black-box-2();
}

The goal (at least as I understand it) is to hide implementation details from .my-element, i.e. it knows nothing about what's happening inside those black boxes, it just uses their styles without knowing what css properties are involved.
(without +: the second transform would just override the first one).

P.S. There're more use-cases of course, for example: #1576 (though originally it seems it was invented just for "autoprefixing" :)

[lukeapage]

And as the layers get bigger, it gets more difficult without property
merging. I've used this feature in the wild where I have guards and loops
to join together a few transforms, though I've forgotten the exact example.

[jonschlinkert]

but does such "merge" differ from:

I think the real advantage of merge is that it allows a selector to copy a declaration from another regular declaration block (e.g. implicit mixin):

.foo {
  box-shadow+: inset 0 0 10px #555;
}
.bar {
  .foo;
  box-shadow+: 0 0 20px black;
}

outputs:

.foo {
  box-shadow: inset 0 0 10px #555;
}
.bar {
  box-shadow: inset 0 0 10px #555, 0 0 20px black;
}

[jonschlinkert]

fwiw I'm cool with whatever is decided on... but my main struggle with the syntax is that despite how concise and clean it is, it's hard to spot even when you're actually looking for it.

Just throwing this out, but what if we used ++ as just the default, making it easier to spot, and then did something like:

property-name++:
property-name+ +:  // or property-name+_+
property-name+,+:

The thing I like about the double ++ is that it's like each + represents one of the values about to be aggregated. but like I said, I'm okay with whatever is decided

[matthew-dean]

👎 to ++. It's so common as "increment this variable" that it is immediately confusing. Whereas += (or +: in this case) is intuitive for merging the previous value with the value that follows.

+_: still works, as an extension of current syntax. It's not the most CSS-y-looking thing, but it has the advantage of being easy to understand.

Also, can we presume that the same would work with variables (in case those values are set by a variable), and interpolated properties?

As in:

.i-set-transform() {
  @transform: scale(1.2);
}
.blah {
  .i-set-transform();
  @transform+: rotate(45deg);
  transform: @transform;
}

Or is that wholly unnecessary and confusing? It just needs to be asked since someone will, eventually. The useful part about merging a variable is that then you could use it to assign to prefixed properties.

.my-class {
  .import-transform();
  @transform+: scale(1.2);
  transform: @transform;
  -webkit-transform: @transform;
}

If we're not going to support variable merging, we should say where the merge assignment will work (+:), since regular assignment (:) works across properties and variables. Although, I guess we call this "property merging", so maybe not an issue.

[SomMeri]

I sent pull request #1788 for this. It implements +_ syntax.

Offtopic: what kid of set-up and tools (mainly IDE) do you use for less.js development? Vim + command line does not seem to be extremely productive so far. Is anybody using Brackets?

[lukeapage]

I use webstorm - its great! and we have a community license for it, just send me your email and I can forward it to you.

[jonschlinkert]

I'm a big fan of sublime text :-)

[Synchro]

I use PHPStorm (which is WebStorm + PHP), love it. The static analysis it does has pre-emptively fixed/avoided so many bugs for me. The thing that has impressed me most so far was when I did a PSR-2 reformat of HTMLPurifier - 16,000 changes in 450 files in one PR - and remained sane!

[seven-phases-max]

I use a couple of primitive text editors with highlighting and node-webkit for debugging. (And yep, Brackets for less-docs md files).

[SomMeri]

@lukeapage By community version you mean open source license? Webstorm sounds great so I would like to get one.

However, if it is the same license, I think I will try to get one for less4j first. It seems to satisfy their conditions, maybe except the "web site" one. If it does not work out, I would ask for less.js one then. I'm not sure if there is any advantage in having two licenses available, but it is not going to be worst.

[lukeapage]

@SomMeri yep, just give me an email address if you want it

[SomMeri]

Closing since #1847 fixed this.