compass and multiple backgrounds

[Eric Meyer]

There was a question about this over on the HAML list, so I thought
I'd follow-up here.

There isn't a real strong argument for adding multiple-backgrounds to
compass. There aren't exactly differing implementations or prefixes or
anything like that. What could be useful is setting a fallback (though
it is fairly simple already).

in CSS

.something {
background-image: fallback.png;
background-image: front.png, middle.png, back.png;
}

in SCSS

.something {
background-image: image-url("fallback.png");
background-image: image-url("front.png"), image-url("middle.png"),
image-url("back.png");
}

This can get more complex if you need to handle the repeat and
attachment properties differently for each.

.something {
background-image: fallback.png;
background-repeat: no-repeat;
background-attachment: scroll;
background-image: front.png, middle.png, back.png;
background-repeat: no-repeat, repeat-x, repeat;
background-attachment: scroll, scroll, fixed;
}

It seems to me that the best format for this would be:

@include multiple-bgs(
images("front.png" no-repeat scroll, "middle.png" repeat-x scroll,
"back.png" repeat fixed),
"fallback.png" no-repeat scroll
)

I left out background-position, which would also be important, but you
get the idea. This would require some ruby handling, but when I think
of solutions without ruby I find very little advantage to them. Anyone
ese have ideas?

In side news: I'm considering a collection of mixins specifically for
use with modernizr.js to help with handling graceful degradation.
Similar to this, but with the added functionality of modernizr.

Cheers,
-e

[Eric Meyer]

"Works great...until I tried to use gradients as backgrounds"

There is a bigger issue once we start thinking about gradients or any
other css where the browser-prefixes happen *inside* the property
declaration rather than before it. Compass/Sass simply don't have a
good solution to that at this point, although I'd like to put some
time into solving it.

Maybe we need gradient functions that work as such:

... background-image: front.png, middle.png, linear-
gradient(color_stops(#dddddd, #aaaaaa), left, moz)

Which would put out the browser-specific version needed. In that case
you would have to repeat for each browser:

.multiple {
background-image: front.png, middle.png, linear-
gradient(color_stops(#dddddd, #aaaaaa), left, moz)
background-image: front.png, middle.png, linear-
gradient(color_stops(#dddddd, #aaaaaa), left, webkit)
background-image: front.png, middle.png, linear-
gradient(color_stops(#dddddd, #aaaaaa), left, official)
}

which gives you the flexibility you need for advanced implementations,
and could still simplify into mixins for common use cases. Nothing at
all would have to change in use of the current gradient mixin, it
would simply loop through this function. Our new multiple background
mixin could then use that to handle those extra lines as well.

@include multiple-bgs(
images(
"front.png" no-repeat scroll,
"middle.png" repeat-x scroll,

"color_stops(#dddddd, #aaaaaa), left" repeat fixed),
"fallback.png" no-repeat scroll
);

I'm not exactly certain of the syntax. I'm sure it needs adjustments
to be implemented. Anyone with Ruby knowledge want to jump in and
correct me?

[Yaohan Chen]

I think something like this would be cool. The sass:
background-images("one.png", linear-gradient(...), "three.png")

The css:
background-image: url(front.png), -webkit-gradient(linear, ...),
url(three.png)
background-image: url(front.png), -moz-linear-gradient(...),
url(three.png)
...

"linear-gradient" would be a function which returns a data structure
to be processed by "background-images". Or it could just return a
string and let background-images parse it for the information.

I don't know how "background-images" would be implemented though. In
theory it just needs to check if any argument is a gradient, and write
it in CSS in different vendor syntaxes. However, sass seems to only
allow functions in property values, while "background-images" needs to
output one or more pairs of CSS property names and values. Mixins can
output property names and values, but don't seem to have the required
parsing and processing power.