tparscal at wikimedia
Sep 24, 2009, 11:37 AM
Post #1 of 2
(167 views)
Permalink
|
|
Re: JS2 design (was Re: Working towards branchingMediaWiki 1.16)
|
|
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
Wikitech-l[at]lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
|
