It might be necessary to process both styling approaches, no-sprites and sprites, at each build. Of course, the sprites approach will still be optional, but we would have to always process the no-sprites target first. There are a couple of reasons for this.

First, some components might need to include a background image meant to be repeated on both axes (x,y). As we know, a background image meant to be repeated on both axes can not be part of a sprites image; it has to remain separate because the browser would display the rest of the sprites image and not just the tile that we want. So, we have to allow this possibility in our general skinning approach.

Second, it could just be the case that a component developer just wants to keep certain images separated and not include them in sprites images. This could be for whatever reason: size, performance, bandwidth, etc. Also, this takes care of the problem with SmartSprites of not copying CSS files without annotations, and we wouldn't have to do anything special to avoid this problem.

This has to be implemented alongside ICE-6215, so that we don't have to tell cssurlmapper where the images are located, but we would just use a common resource library. This way every generated skin resource would be inside a generated resource library.