Feature Request - the following functions would be useful: top(), bottom(), left(), right()

[scottrippey]

An example says it best:

@margin: 1px 2px 3px;
.ruleset {
    margin-top: top(@margin); // Outputs "1px"
    margin-right: right(@margin); // Outputs "2px"
    margin-left: left(@margin); // Outputs "2px"
}

When I have a variable that holds a margin (in shorthand syntax), I would like to be able to extract the top/bottom/left/right values.
I have several mixins that require @Margin and @padding as parameters, but I need to break it down into -top, -bottom, -left, and -right. Currently, I have 8 separate variables, which makes the mixin much harder to use and way too verbose.

[lukeapage]

Makes sense. What about

pick(@multi, top)

Where the second argument can be top/left/bottm/right or a number ?

[scottrippey]

That's a good idea, making it more generic means this pattern could somehow be applied to extract ANY shorthand value, right?
For example: margin: top right bottom left, border: width style color, background: color repeat position.
However, now I can see that this might be getting out of hand. What do you think?

[scottrippey]

Unrelated question: (I don't know where else to ask)
I created a LESS Live Preview that lets you "test" new LESS features by showing you the compiled CSS.
http://www.less2css.org
Is there a good way to promote it to LESS users?

[gustavohenke]

That was not found bro :P

[scottrippey]

@gustavohenke Sorry, my coworker changed the URL to the much-more-exciting http://www.less2css.org :)

[lukeapage]

@scottrippey looks really good. any chance you could do a "live preview" (or try it? or something else?) button and put it in a pull request to https://github.com/cloudhead/lesscss.org ? Otherwise if you could raise an issue there I would be happy to add something myself.

[lukeapage]

w.r.t the issue, I wouldn't support width, style, color keywords as we don't know for sure the position - I would say people would have to use numbers. I would suggest maybe just top, left, right, bottom and we could also be intelligent - e.g. if there are only 2 values or 1 value, pick the right one.

[gustavohenke]

Wow, what a great job bro :)

If you guys could do the live preview as mentioned above, it would be perfect. I already knew about http://css2less.cc, which is now down, but yours looks very better than what this one was :D

[scottrippey]

@agatronic LESS2CSS - I've been working with Brian (my coworker) to support some sort of "snippet" link mechanism so that a "try it live" button can include the appropriate snippet. When that's working, I'll create the pull request to lesscss.org :) Thanks for the encouragement.

If I want to discuss this further, how should I do that? This thread is already hijacked by this conversation, but GitHub seems to have removed all PM. Is there another means of GH communication, apart from Issue Comments?

[scottrippey]

@agatronic w.r.t. pick(...) > I think you're on to something. Supporting a syntax like pick(@var, (top|right|bottom|left| [0-9]) ) would be pretty slick. The t|r|b|l keywords would be "smart" and deduce the padding shorthand, while an integer would choose the value at the given index. What makes more sense, 0-based index or 1-based index? I'm leaning toward 1-based.
Examples:

pick(1px 2px 3px, left) // 2px
pick(1px 2px 3px, 2) // 2px
pick(1px solid red, 3) // red

[matthew-dean]

Hmmmmm.......

I can't help but feel like there's some aspect of CSS where this idea breaks down. It seems like we're designing a new feature / function around a very narrow use case.

Let me throw a monkey wrench in here:

@myBackground: #f00 url(background.gif) no-repeat fixed 0 0;

This shorthand consists of 5 CSS values, even though it is 6 "blocks" separated by spaces. Is 0 0 value 5? Or is it value 5 and 6? So the programmatic extraction of values doesn't match the number of values CSS considers there to be, and this can't be the only case of this in CSS. So, do you stick with a programmatic, space-separated definition? Or do you maintain LESS's goal to "extend" CSS, and thus attempt to do some wizardry to merge values 5 and 6?

On the other hand, this whole question could be circumvented by approaching in a different way:

@myBgColor: #f00;
@myBgImage: url(background.gif);
@myBgRepeat: no-repeat;
@myBgAttachment: fixed;
@myBgPosition: 0 0;

@myBackground: @myBgColor @myBgImage @myBgRepeat @myBgAttachment @myBgPosition;

.ruleset {
   background-color: @myBgColor;
}

It's more verbose to define, but it's also not ambiguous. And it appears like the pick position doesn't change programmatically; that is, you always know which value you really intend to extract, so why not define it explicitly?

The pick function is a cool idea, but for me, it fails the test of clarity. That is, it isn't necessarily intuitive what the return value will be, which means more documentation, more examples for something that I'm guessing few people will want to do: define a variable with a value of a CSS shorthand and then only use part of that value in another ruleset.

If LESS gets smart enough to "know" what each parts of a value are, and how they map to explicit CSS values, then I can see something like this being a lot more intuitive, and in that case, the more intuitive syntax would be what @agatronic first suggested:

@myMargin: 1px 2px 3px;

.ruleset {
  margin-left: pick(@myMargin, left);
}

But that takes a lot of logic, and I don't think we are there yet. (And we may never get there).

My $0.02.

[lukeapage]

I think 0 vs 0 0 is an even narrower usecase.. and surely in these cases
you might know enough about your input that it isn't an issue.

The win for me is around the big use case of top, left, right, bottom and a
simple way of specifying a margin property and then using the left
component of it.. very difficult for any library to do without js.

I considered 1 function better than 4 (more succinct). Introducing numbers
was both for flexibility and because of requests for indexing themes. I
like the idea of being able to define a set of 5 colours for themes 1-5 and
then picking the colour for the theme number passed in.

So I see multiple applications and usefulness with a little function and no
feature changes as a big win.

[scottrippey]

@MatthewDL Great points, I agree that "extracting" a value from a shorthand syntax is troublesome, obfuscating, and is not what I want to do. Also, LESS currently has no "awareness" of CSS shorthand properties, nor does it need to.

@agatronic I think the biggest use-case, by far, is the TRBL capability. And I agree, too, that we don't need to dilute the namespace with 4 dedicated functions. But has a precedent already been set by the red green blue and alpha functions? And do you think that top right bottom left methods could one day need a different definition?

I think I'm back to square-one ... I'd like to see 4 separate top(@pad) right(@pad) bottom(@pad) left(@pad) functions.

[scottrippey]

I created a pull request for this feature, please let me know what you think? This is my first pull request.
#1110

[bfricka]

Hi there,

I'm the dude who wrote less2css with Scott and put the website up. I added the link to the nav on lesscss.org and opened a pull request.

[lukeapage]

@MatthewDL what do you think now - if you are in favour of accepting the 4 functions I'll just consider myself over-ruled.

Personally I prefer a more powerfull function, but nothing stops us from having both the shorthand and a pick function in the future

[scottrippey]

Let's continue this discussion on the Pull Request #1112.

[matthew-dean]

Commented in Pull Request #1112.