On 9/24/09 9:31 AM, Jared Williams wrote: >>> * Automatically create CSS sprites? >>> >> That would be neat, but perhaps a bit tricky. >> > Just trying to think how it'd work. > > Given a CSS selector, and an image, should be able to construct a > stylesheet which sets the background property of the css rules and an > single image. > > (#toolbar-copy, toolbar-copy.png) > (#toolbar-copy:hover, toolbar-copy-hover.png) > > And the generated stylesheet would get concatenated with other > stylesheets. > I work with CSS sprites all the time, and have seen some "automated" methods to go from individual images to sprites, but it's not nearly as good of an idea as it sounds.
I will go into depth, but if you don't really care (totally understandable) just understand this. *Automation of sprite creation and implementation is not an efficient use of time in most cases.* First, to use sprites, you have to be in a situation where CSS "background-position " attributes are not already being used. Take for instance the CSS we use to place little icons next to links that are pointing to external URLs. Essentially we set a background image to be positioned "right center" and then move the text out of the way with "padding-right:18px". If you were to sprite this image, you could perhaps use a vertical sprite (images tiled vertically only) but then when the user adjusts the size of the text in their browser they start seeing multiple images on the right. You could add more space between the images so that the text could be pretty big before you start seeing the other icons, but how much space is enough? What limit on text-size adjustment should we declare? Does the extra space between the icons introduce a significant amount of additional data? (maybe not much with PNG compression techniques, but it does add something) In many other cases the background position in both X and Y are being used already so sprites are not a possibility at all. To use sprites like Google does, you would need to change the HTML output to accommodate the technique. For instance you could insert a fixed sized "float:right" div as an icon at the end of the link, but then the elegant way that we apply styles to such links (rules like "a[href^=http://]";) are useless... We would have to make changes to the output of the parser for purely aesthetic reasons (evil), or perform client-side DOM manipulations (requiring JavaScript to to be enabled just to see the external link icon - also evil) --- this is getting messy. My point is not that sprites are bad, it's that they aren't always an option, and take allot of careful design of CSS, HTML and image resources to get working properly. Automating them as is starting to be proposed here includes inventing some sort of instruction set that a computer can read and assemble sprites from, but the problem is usually so complex that such a language would take much more time to invent, create parsers for, test and maintain than to just do the sprites by hand. Automating sprite creation is still a great idea, but it needs to be done in more isolated and predictable cases like generating toolbar icons. This case is more firendly to automation because it's dealing with fixed height and width images that are always displayed in the browser at the same size no matter what. Thes files are currently stored in separate files, so merging them into a single file and generating CSS code that defines the offsets for them to be put to use using automation would be great!. However even this case has it's issues. It makes the toolbar code more complex because we have to support sprite-based images as well as non-sprite-based images (so that users can still customize the toolbar) and we have to handle the naming of the selectors of the generated CSS in some way that won't cause confusion or namespace collision. Finally, the png or gif files that are created by things like ImageMagick are larger (in bytes) than images compressed by hand (using image manipulation software). Even pngcrush or similar utilities fail to outperform manual image compression. The reason is that images can be reduced in size, but when you do this it reduces the "quality" (fewer colors in the pallete make the image look more grainy, aggressive jpeg compression makes the image look more blocky). When performing image compression manually, you use your eyes and image processing in your brain to decide where the line should be drawn between quality and optimization - automated solutions I've used seem to either draw this line arbitrarily or error on the side of quality at the cost of optimal compression. So - not only does the CSS and HTML need close attention when working with sprites, but the image optimization process does as well. Again, I like sprites allot! But in reality, they are an optimization technique that needs careful attention and can cause problems if done improperly. - Trevor _______________________________________________ Wikitech-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikitech-l
