Adapt spriting syntax/features to match transforms.processImages

[papandreou]

• Turn -ag-sprite-group into a GET parameter so that different images mentioned in the same CSS rule can be added to different sprites
• Explore whether this syntax change makes the spriting applicable to sprite images referred to from eg. HTML. Eg. <img src="foo.png?sprite=abc"> ⇒ <img src="blank.png" style="background-image:url(sprite.png);background-position: ...">
• Find out whether to reintroduce the possibility of processing sprited images after they have been generated

[Munter]

In doing this refactoring I think we should rename the commands. If we're not in CSS domain any more the prefix can go. Also I think a sprite group is the base trigger for if an image is a part of a sprite or not, so that's the most common use case. We should drop the '-group' part to make it more easily accessible.

So my suggestion is image.png?sprite=foo&sprite-option=bar

Also I think we should introduce a new sprite group. A global sprite group. One that things will go into if no specific group is mentioned. That enables the following syntax: image.png?sprite, which I feel would be a very common use case for most people. Just a single sprite with no need for naming.

[Munter]

Post processing a sprite

This requires a bit more thought. We could make it chainable through cgi-params, like has already been done in the image post processing with the order being significant.

But we are going to run into trouble because post processing the sprite sheet itself is going to pull in post processing instructions from a number of different images. In the worst case this will cause a conflict in settings and/or a post processing step that was unintended for the rest of the images in the sprite sheet.

I think we need to find a way to define a post processing step of sprite sheets outside the image url's. Maybe stick to the concept of vendor prefixed css properties for defining a specific sprite sheets options.

In that case the only sprite related cgi param would be the sprite group name. And the configuration and post processing would be handled somewhere else. A CSS block maybe?

[Munter]

Wasn't this solved by https://github.com/One-com/assetgraph-builder/blob/master/lib/transforms/buildProduction.js#L45-L49 ?

[papandreou]

Yeah, pretty much. I'm not sure there's much left, except the 2nd bullet:

• Explore whether this syntax change makes the spriting applicable to sprite images referred to from eg. HTML. Eg. <img src="foo.png?sprite=abc"> ⇒ <img src="blank.png" style="background-image:url(sprite.png);background-position: ...">

... which probably isn't that interesting anyway.

[papandreou]

Postprocessing a sprite is still a bit ugly. You have to do something like this:

.foo {
    -sprite-selector-for-group: theGroup;
    -sprite-location: url(?pngquant=128);
    background: red !important; /* optional, will be preserved */
}

.bar {
    background-image: url(bar.png?sprite=theGroup);
}

But I wasn't able to come up with something better. The only really ugly part is the -sprite-location bit.

[papandreou]

Well, it is what it is. Open a new issue if you have a good idea about how to get rid of the -sprite-location ugliness.

[Munter]

I have no new ideas on this. I think we've improved on the common use case. Post processing a sprite sheet other than the default optimizations, which we do anyway, doesn't seem to be that big of a use case.