SmartSprites

I agree with this feature. This would avoid to maintain the information in two places. Currently the developer have to keep any changes on the real properties in sync with the SmartSprites directive.
But this issue is far more complex as seen on first sight. In some situations it is most likely not sufficient only to take the properties in the current CSS definition block into account.

Example:

.foo {
background-position: top right;
background-repeat: no-repeat;
background-image: url(../images/foo.png); /** sprite-ref: mysprite; */
}
div.foo {
background-position: 0 -10px;
}

Usage in HTML:

<h1 class="foo">Heading</h1>
<div class="foo">Just a container.</div>

For the above scenario a vertically aligned sprite is used for the foo.png.
The background image for the heading is positioned right and on top. That's fine so far. But the following css definition div.foo overwrites the background position of the same background image for any div using this class. So the div shows the same background image moved a little bit to the top. But because the sprite is vertically aligned that might shows a little bit of the following image on the sprite in the div.
Maybe the developer have to apply a margin-bottom to the directive to cover this possibility...

But it's likely that there are more of such cases when parsing only the current CSS definition block might not be enough and the margin-bottom trick isn't working. And of course reading every CSS inheritance might be an impossible job...

Maybe this is a deadlock example:

.bar {
background-position: top left;
background-repeat: no-repeat;
background-image: url(../images/foo.png); /** sprite-ref: mysprite; */
}
div.bar {
background-repeat: repeat-y;
height: 200px;
}

The sprite is again vertically aligned. For the heading that's ok and valid. But the div repeats the image vertically! And here is the problem: the sprite should be aligned horizontally for this case. But the inheritance gives us a vertically aligned one... I think we are out of luck in this situation. Maybe the simples solution for this is to exclude the image completely from the sprite and use it as normal.

Anyways that's not an issue for the discussed feature but should be further thought of.

What about introducing 3 different modes:

• automatic - read and apply the repeating/position only from the CSS properties
• manual - read and apply the repeating/position only from the provided SmartSprites directive
• combined - read and apply the repeating/position from the CSS properties and overwriting them with any provided SmartSprites directive (which allows special correction if necessary)

I think the combined mode should be the default one if none is defined in the smartsprites.properties.

Funny thing, a few months ago I did some initial thinking on this issue and came to the same conclusions. A fully automatic mode is simply impossible, because we would have to analyse the whole stylesheet (inheritance etc.), and such analysis cannot be performed without knowing the markup (possibly dynamically generated, also using JS) for which the CSS will be applied.

Interestingly, the 3-modes idea also crossed my mind. For stylesheets without much inheritance, the automatic mode should be quite effective, and you could always use the other two modes to tune the settings.

This feature would be really powerful, I'll try to implement it as a priority (most probably together with SMARTSPRITES-22), though most likely not this month, I'm afraid...

Moving out of the 0.3.0 release.