9 blending modes added as LESS operations

[rmariuzzo]

Hi Alexis,

If it is not out of the LESS project scope, you may feel free to add these 9 blending modes.

• multiply
• screen
• overlay
• softlight
• hardlight
• difference
• exclusion
• average
• negation

I also created the test cases, and it works like a clock.

[rmariuzzo]

Alexis, you can bypass the README.md file and keep yours. I didn't notice it was included in the pull request.

[Anahkiasen]

I've been waiting forever for a some of these function, when I have to go from my Photoshop mock-up to the real thing, even though I always try to make the most flexible and dynamic design, I sometimes lack the power of multiply or difference. Really great add !

[rmariuzzo]

@Anahkiasen, that's the reason I got impulsed to add these blend effect, because I was converting my Mock-up from Adobe Fireworks into HTML5/CSS3, then I was missing a few blend modes such softlight to create new swatches from my original palette.

I think this will be a good addition because now I can just replace the following code:

@brand_color_1:       #F16101;
@brand_color_1_light: #F79D0F; /* Full white soft light. */
@brand_color_1_dark:  #E32400; /* Full black soft light. */
@brand_color_2:       #8AA8B0;
@brand_color_2_light: #BBCED3; /* Full white soft light. */
@brand_color_2_dark:  #BBCED3; /* Full black soft light. */

With the follwing:

@brand_color_1:       #F16101;
@brand_color_1_light: softlight(@brand_color_1, #ffffff);
@brand_color_1_dark:  softlight(@brand_color_1, #000000);
@brand_color_2:       #8AA8B0;
@brand_color_2_light: softlight(@brand_color_2, #ffffff);
@brand_color_2_dark:  softlight(@brand_color_2, #000000);

Thanks for your comment. I appreciate the fact that this additions will be a help for others.

[rmariuzzo]

@cloudhead, If you consider to include this addition I will be more than volunteer to prepare the documentation for each blend modes added, so you can include it into http://lesscss.org/. Also, I will not require as an obligation to throw my name in the credits. :) I just made it, because I love coding, and LESS is a great project that helps millions!

[matthew-dean]

Ooo, this plus the contrast function of Issue #488 could make for some really sexy templating. ^_^

[lukeapage]

@Synchro @MatthewDL do you agree this can be merged?

I personally think having powerful color functions fits well into less and how to keep it declarative and still powerful.

@rmariuzzo - @cloudhead has a project for the website documentation - maybe you could open a pull request there.
@Synchro perhaps you could open a pull request to update documentation to add the contrast and luma functions?

[rmariuzzo]

Nice to heard that. I will be more than interesting into adding/updating
the current docs for those 9 blending modes.

Contrast and luma? I will check it up.

Rubens Mariuzzo
On Aug 12, 2012 3:47 PM, "Luke Page" [email protected] wrote:

@Synchro https://github.com/Synchro @matthewdlhttps://github.com/matthewdldo you agree this can be merged?

I personally think having powerful color functions fits well into less and
how to keep it declarative and still powerful.

@rmariuzzo https://github.com/rmariuzzo - @cloudheadhttps://github.com/cloudheadhas a project for the website documentation - maybe you could open a pull
request there.
@Synchro https://github.com/Synchro perhaps you could open a pull
request to update documentation to add the contrast and luma functions?

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/596#issuecomment-7679168.

[Synchro]

Added ticket for contast/luma docs in #895

[Synchro]

And I'm +1 for pulling this.

[matthew-dean]

Well, having a second look at this, I feel like these would all need significant documentation as far as what they mean compared to their, say, Photoshop counterparts. I worry this could cause confusion for someone who falsely thinks that by applying one of these, their element would have the same type of blending on the page. When, in reality, I think these are just color blending algorithms for two individual colors? Is that correct?

I'd like to see documentation first. For instance, how does "softlight" differ from "lighten", and what makes it necessary?

[Synchro]

Yes, they are just applied to two individual colours; it's akin to what photoshop would do with a single pixel.
#785 has some docs for the blend modes it implements that might help. I've noticed that the docs on lesscss.org are not exhaustive - there doesn't seem to be a complete reference, only a kind of overview.

[Synchro]

Incidentally I think #785 should be closed as a dupe.

[lukeapage]

ok, pulled, on my head be it.

[Synchro]

@rmariuzzo - care to write something for less/old-lesscss.org#26 ?

[matthew-dean]

Oh this is already pulled? Did we get @cloudhead's input? These seem like a big deal, and I still don't feel like I have my head wrapped around what they would do or exactly what possibilities they open up. I fear this may introduce confusion and complexity into something that's been kept as simple as LESS.

Bottom line: I cringe at anything that looks like LESS becoming SASS.

[matthew-dean]

In addition, these may be good candidates for solidifying:

a) A plugin syntax and documentation (writing any functions that can be interpreted by LESS as valid keywords),
b) A companion configuration file (w/ syntax and documentation), necessary for a plugin architecture. (See Issue #850)

If LESS had a solid documented plugin architecture, then a lot of these extra helper functions could easily be integrated without expanding LESS core. So, I'm not saying these definitely DON'T belong, but if we had a plugin architecture in LESS that was supported by all compilers, would they more legitimately go there?

[lukeapage]

Sorry, I didn't realise you objected.. can you get to the bottom of a
decision? If you or @cloudhead thinks it should be removed I'll remove it.

I am of the opinion that any functions that make it easier to build a set
of colours from a base theme are useful.. this doesn't complicate the
language it just adds functions that people have the option to use.. and
which the only other option is passing in extra variables, calculated
outside less.

[matthew-dean]

I don't object outright. I just want us to be conservative. It can seem harmless to add extra functions, but as an overall product, each new function is an extra chunk of documentation for someone to sift through. I don't have a clear sense of the value of these functions compared to the existing functions in LESS, so that to me is the balancing act. Do these add enough value to justify adding complexity? If the complexity added is small, or the value added is high, then that gives it some weight.

The second issue I have with it, which may be more important, is that, to me, these are functions that don't have an intuitive output vs. the existing color functions, which do. A developer is less likely to understand "softlight" without several examples and trial and error, whereas "fadeout" or "darken" or "mix" are a lot easier to understand.

So, for me, this may come down to documentation. Is it simple to understand? Is it intuitive? Or will it add confusion and complexity? If it's the latter, then to me, the extra value may not be worth it.

Having said that, I fully understand that it may be HIGHLY valued by someone creating templated libraries, so there's that balance too, and I'm all for providing more tools, just as you said. So then the question is what is the best way to provide that flexibility with adding the lowest complexity and the least chance of confusion to developers new to LESS. In the end, I'd probably fall on the side of supporting something like this, but I want to see it done in the smartest way, so I'd love more input / discussion on what that might be.

[lukeapage]

Your additional suggestion sounds good.. but who's going to do it?

And btw. I did exactly this for dotless.

[matthew-dean]

Which part sounds good? What was it you did for dotless?

[lukeapage]

Allow plugins to extend the base functions and better config which allows
it..

[matthew-dean]

Cool. Then maybe we could separately discuss plugin / configuration syntax, something that works for all parsers and compiling environments, and make a specific recommendation.

[Synchro]

Plugins do seem like an obvious way to go - most of the changes I've wanted could have been done by plugins as they are not core functionality (i.e. involving translation of generic LESS markup to CSS). I've seen other projects move to plugin-based architecture before, usually by shrinking core operations and devolving 'functions' into plugins, and that's generally been achieved without breaking BC; I don't know if that could be done with LESS. In the mean time I don't think we should be too shy about adding functions to core since there's nowhere else to put them for now.

That said, I don't think that functions should necessarily be rejected because they're not common. Colour is obviously a very important part of CSS, and there may be colour processing functions that are unfamiliar to many; much the same thing may be said of 3D or audio functions which are likely to be applicable to CSS generation too. Since LESS can manipulate colours as in any other colour-oriented environment, similar functions should be made available. It's trivial in CSS to specify a colour value, but how that value was arrived at may involve far more complexity.

I don't think code size is a major factor either: execution speed on the server is almost irrelevant since it happens relatively rarely and so long as it doesn't take more than a few seconds it should be fine. Client-side execution is more of an issue, but does that really get much use outside dev environments?

Also it doesn't matter whether a function is implemented in core or a plugin - it will need documenting either way.

[matthew-dean]

All good points. I retract my conservatism. Especially because I got this message from @cloudhead this morning:

if you have time, could you look into integrating this:
[8/20/12 5:21:54 PM] Alexis: https://gist.github.com/1825806
[8/20/12 5:21:58 PM] Alexis: into less?
[8/20/12 5:22:40 PM] Alexis: it's a perceptual luma function
[8/20/12 5:23:19 PM] Alexis: http://www.startupmonday.com/lab/gradients.png
[8/20/12 5:23:40 PM] Alexis: it's the left one, compared to lighten on the right
[8/20/12 5:23:52 PM] Alexis: cheers

Plus... the more I thought about it this morning, part of the core of LESS I'd like to see is a rock-solid foundation for templating libraries (like Bootstrap). A variety of color functions is not a bad idea in that context.

You can still expect me to be conservative on new features. I don't mind being the voice of "Whoa whoa SLOW DOWN PEOPLE!"

So, yep, let's do this. And let people use these as they may.

[matthew-dean]

Oh, and of course, please add @cloudhead's color function if it doesn't match one of the ones already committed.