TYPO3 Core

sprite-icon-api is now included in beta2. In short the task of this api ist to "replace" t3lib_iconWorks::skinImg for showing Icons in the backend, ass css-class with background.
As sprite api works with css classes beside of image-Tags (likeskinImg) this will fail as long the icon is not included in the BE-stylesheet.

Easiest example: The record icons of extension tables. List-Module would build them via spriteApi, but core-stylesheets cannot have css definitions for extension icons.

Therefore, there has to be another API which handles icons building sprites in TYPO3.

In the current sprite-icon-api I solved the problem with an temporary helper function buildTcaSpriteIcons, which builds an stylesheet-file for all tca-table-record icons and registers them as "usuable" in the sprite-icon-api. There, no sprite is generated but every icon is loaded as single background-image.

In long term there has to be concept / handler to make this transparent and which might be able to auto generate sprite-files and additionally allows extension developers to register icons for use in the icon-api, so that, their be modules might be skinned to.

Since there has been a very long discussion about "should we generate sprites", "should they be static", "sprites at all", "how many sprites should we have" etc. this concept has to be very flexible.

So with Benni I thought about an concept, which could be implemented fast enough for 4.4, would allow enough flexibility to fullfill all wishes arised in the discussions.

What I have done:
--------------------
- invented t3lib_spriteManager, who should take care of the things mentioned above
- invented an interface t3lib_spriteManager_spriteIconGenerator
- made the handler configurable: $GLOBALS['TYPO3_CONF_VARS']['BE']['spriteIconGenerator_handler'] (objects which implement the above interface)
- t3lib_iconManger contains two static function for extension Developers:

t3lib_iconManager::addSingleIcons - will allow Ext-Developers to register their icons to get included in sprites, which they may use them afterwards with t3lib_iconWorks::getSpriteIcon('extensions-$extKey-iconName');

t3lib_iconManager::addIconSprite - if the extension ships an already build sprite with corresponding css, it can be registered with this function

The plan is the following:

typo3 4.4 should ship an "simple" handler (becuase of the timeframe):
t3lib_spriteManager_simpleHandler
This one just does, what our workaround t3lib_iconWorks::buildTcaSpriteIcons already does, plus the icons registered via the api. But without sprite-generation. All icons are just included as single background-image.

This will make the sprite-icon-api just committed usuable for the core as of now. There is only a performance gain in core sprites or static sprites delivered by extensions.

TYPO3 4.5 should ship t3lib_iconManager_autoGenerateSprite and t3lib_iconManager_manualGenerateSprite
(issue imported from #M14324)