Script-friendly Spriting Tools

[Andrew Schaaf]

Hi all,

At the awesome New York Web Performance meetup last night, there was interest in script-friendly spriting tools, and some of us chatted at the end.

Here's one possible scripting interface for the tools. I have a partial implementation. I'll {work on,commit} it this weekend.

https://github.com/andrewschaaf/spriteutils/blob/master/README.markdown#files

Anyone interested in meeting up for a couple hours during work hours sometime next week and work on consolidating...

• ...what I've done
• ...what you've done
• ...what the world has done

...into a super-duper spriting suite (#webperf branded?) with a nice website?

- Andrew

[Sergey Chernyshev]

Great work, Andrew!

Let's think of all different tools that can create sprite.json format and use it to manipulate images, e.g. PHP script or desktop app to update the sprite with new component image and so on.

BTW, I think you should change sprite-html-viz to be just a webpage, maybe even in PHP or something for simplicity of installation. I can probably create it.

And I think, it's probably a good idea to invite Steve Souders and other people who work on spriting to discuss sprite.json format.

I've created a sample sprite layout file: https://github.com/sergeychernyshev/spriteutils/blob/master/samples/sharingbuttons.json

Let's work on different samples and usecases for it to make sure formats and tools will reflect as many as many of them as possible.

         Sergey

[Andrew Schaaf]

The implementation is up!

https://github.com/andrewschaaf/spriteutils

On Nov 14, 2010, at 11:58 PM, Sergey Chernyshev wrote:
>
> BTW, I think you should change sprite-html-viz to be just a webpage, maybe even in PHP or something for simplicity of installation. I can probably create it.

I was planning to have it generate HTML (with images embedded via base64 URIs). Do you mean it should emit '...HMTL...' instead of '{"html": "...HTML..."}'? Or that sprite-html-viz should be provided as a service somewhere?

> Let's think of all different tools that can create sprite.json format and use it to manipulate images, e.g. PHP script or desktop app to update the sprite with new component image and so on.

> [...]

> Let's work on different samples and usecases for it to make sure formats and tools will reflect as many as many of them as possible.

Yes, let's!

I can't put time into brainstorming for other people's potential use cases at the moment, but would be happy to adapt as they arise.

Also, maybe GUIs and other wrappers ought to be outside the scope of spriteutils. A #webperf-branded site and wrapper suite, perhaps?

Andrew

[Julien Wajsberg]

does this do the same as SmartSprites ? http://csssprites.org/

[Sergey Chernyshev]

Similar purpose, but not exactly like CSSSprites.org - it will provide
sprite-metadata and tools independent from CSS and will allow for
automated build of the sprites and CSS updates without meta-data
within CSS.

Sergey


On Nov 15, 6:18 pm, Julien Wajsberg <fel...@gmail.com> wrote:
> does this do the same as SmartSprites ?http://csssprites.org/

[Julien Wajsberg]

Okay, level_of_abstraction++ :-)

Sounds good.

On 16 November 2010 17:39, Sergey Chernyshev

[gekkstah]

I could not participate the meetup but would like to participate the
discussion.
So I dont quite understand, what sprite.json is supposed to be.
Would you mind explaining it ?


But I think at least the approach of csssprites.org is, if I am not
missing out anything, not the best.
Why should you want to write your CSS first "as if there was no
spriting" and then let a tool run over it to sprite everything ?

We chose another approach:

In an "input folder" you store all images that are used on your site
and shall be sprited.
To separate them, we divide them into subfolders like "icon",
"upgrade" or "user".
The single images/icon inside get named just like: "icon-ext-
questionmark.png" or "upgrade-ext-termsconditions.png".

That is, we create one CSS file from it and (in this case) three png-
files, one for each subfolder one CSS File like:

.icon {background-image: url(/img/icon-sprite.png) no-repeat 0 0 }
.upgrade{background-image: url(/img/upgrade-sprite.png) no-repeat 0
0 }
.user {background-image: url(/img/user-sprite.png) no-repeat 0 0 }

.icon-ext-questionmark { background-position: 0 40px}
.upgrade-ext-termsconditions { background-position: 0 55px }

Whereas the markup will look like:

<img src="/img/transparent.gif" class="icon icon-ext-questionmark">

All what the guy who is spriting has to do, is to drop the new/changed
graphic properly named into the subfolder and generate the sprite and
CSS again.
If you make sure your generated CSS and PNG's never get edited
*manually*, even your Designers can do the spriting job for you and
you will never have to care about new icons/graphics again. We even
include a PNG Crusher here.

What do you think ?
I would be glad for any feedback

Cheers
Bjoern

[Sergey Chernyshev]

The goal of the tools is to not have anyone do the spriting, that's the whole idea. Or at least reduce maintenance for this work.

One of the workflows is like this - CSS/HTML person cuts up mockups that were given to them and creates a bunch of icon files and then uses them within CSS as usual.

Then, automated or manual tools are used to create sprite.json for those icon files that can be sprited together. Ideally, tools like SpriteMe (or coolRunnings) can be automated to generate this kind of file.

Now, upon deployment, third tool can use sprite.json file to automatically stitch files together into a sprite image and rewrite CSS file.

This can be tied into version control system hooks and detect when any image is changed or new sprite-able image is added or CSS changed adding a new rule that allows for spriting.

Hope this explains the idea.

BTW, another possible part of this is to allow automated mockup cutting into icons, but that's another story ;)

Thank you,

         Sergey


--
Sergey Chernyshev
http://www.sergeychernyshev.com/

http://www.meetup.com/Web-Performance-NY/

http://www.showslow.com/