T3DD10: It's all about sprites

By: Steffen Ritter

Steffen Ritter and Steffen Gebert presented the technical changes in TYPO3 for the skinning of the back end at the Developer Days including the CSS sprite concept the UserExperience Week kicked off. Steffen Gebert has done a lot of work in implementing Lars Zimmermann's new design for the backend that started at last year's User eXperience Week while Steffen Ritter implemented "the sprite stuff". This article explains what CSS sprites is all about.

Sprite containing large number of images.

With TYPO3 version 4.4 we ship a fancy new backend design with the aim to make the heart of TYPO3 more usable and attractive to TYPO3 users. 

Reading the release notes, NEWS.txt and/or following the newsgroups you probably stumbled on one buzzword: "sprites".

For outsiders this might sound like "it's all about sprites". On further investigation you'll find sprites, a sprite-API, a sprite manager API, sprite manager handlers and a sprite generator.

But what is it really about:
The sprite API is the one you'll address for rendering icons in the backend, it's task is to generate html output for icon requests displayed in backend modules.

Therefore the sprite API relies on an internal cache storing the information about which icons are present in the system. This cache is managed by the sprite manager. The sprite manager API is the point where you might register your own icons. Then it takes care of CSS inclusion (for your sprites and icons), rebuilds the icon caches and might call the sprite generator (not included in 4.4) to build an sprite-image from single registered icons. Furthermore it takes care of automatically registering icons of your extension TCA-tables to be usable through sprite API.

The sprite generator is the most important part of this whole system of sprites-classes interacting. It has the task to collect single icons from the file system and build one sprite graphic and a CSS file addressing the single icons within the sprite as well as returning the icon names of the generated icons so that the sprite manager may add them to the icon cache. It is not included with version 4.4 and had been just an prototype for generating sprites shipped with this version.

Until now it's a finished class shipping with 4.5, which generated sprites 2-dimensional, allowing different image sizes within one sprite and aims to provide an easy to use interface that can be used by extension-developers directly f.e.: frontend-usage.

The Handlers for the Sprite Manager can be different implementations on how the sprite-manager builds and collects it's caches and information. Version 4.4 ships with a simple version just adding every single additional icon as background image, so that they are usable through sprite-API. For sure with this there is no speed-benefit.

The handler interface using the sprite Generator is not completely finished by now. We are at about 80% and going to ship in two different versions:

1. generating sprites as often as needed
2. regenerating sprites only on triggering

Conclusion:
The system of sprite-classes interact while each class has it's own task. The sprite manager mainly addresses the extension-developers, sprite-API the backend-module coders.

The future plan is supporting extension developers by providing a user-interface to the sprite generator in extdeveval so that extensions developers might ship their extensions with sprites instead of single icons or as an addition to them.

Further details can be found in doc_core_skinning.