W3C home > Mailing lists > Public > www-style@w3.org > November 2012

Re: [CSS4] Image catalogs (a.k.a. CSS sprites) idea

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Tue, 13 Nov 2012 12:09:55 -0800
Message-ID: <CAAWBYDCJ1PC1QQ6p50ES7ExneLHmyoqDkktsbC7DqrVDXTaaMQ@mail.gmail.com>
To: Andrew Fedoniouk <news@terrainformatica.com>
Cc: www-style list <www-style@w3.org>
On Mon, Nov 12, 2012 at 12:43 PM, Andrew Fedoniouk
<news@terrainformatica.com> wrote:
> CSS4 images module define concept of Image Fragments [1] like:
>
>   background-image: image('toolbar.png#xywh=40,0,20,20')
>
> But this solution is not scaleable well when for different DPIs when
> we need to use toolbar.png, toolbar-2x.png, toolbar-4x.png images.

Sure it is.  You'd just do:

  image-set( "toolbar.png#xywh=40,0,20,20" 1x,
"toolbar-2x.png#xywh=80,0,40,40" 2x );

> And yet such declarations are very hard to maintain.
>
> So thinking about the @image-map construct:
>
> Let's assume we have this declaration:
>
> @image-map my-sprites {
>     src: url(toolbar-icons.png);
>     cells: 16 2;  /* 16 in a row, 2 rows */
>     parts: icon-bold,  /* logical names of cells, one by one */
>              icon-italic,
>              icon-font-name,
>              icon-font-size,
>              ...;
> }
> That defines image catalog made of fragments of toolbar-icons.png file.
>
> So later in CSS we can define something like this:
>
> .toolbar > button.bold {  background-image: image-map(my-sprites,icon-bold);  }
> .toolbar > button.italic {  background-image:
> image-map(my-sprites,icon-italic);  }
> etc.
>
> Note that this group of declarations is using only logical names - is
> not tied with pixel sizes of original images.
>
> The src may use multiple image sources:
>
> @image-map my-sprites {
>     src: url(toolbar-icons.png) 100dpi,
>           url(toolbar-icons-2x.png) 300dpi,
>           url(toolbar-icons-print.png) 600dpi );
>     cells: 16 2;  /* 16 in a row, 2 rows */
>     ...
> }
> in this case such single declaration will be flexible to different
> screen resolutions.
>
> The image-map may also define catalogs of parts of variable sizes:
>
> @image-map my-logos {
>     src: ...;
>     cells: 16 4;  /* 16 in a row, 4 rows */
>     parts: logo-this 1 1 4 4, /* spans 4x4 cells from 0,0 */
>              icon-fb 5 1 1 1,  /* spans 1 cell at 5,1 */
>              ...;
> }
>
> If we have such @image-map then we don't need image-set [2] construct.

Usually when someone says something like this, it's because they're
defining a new primitive that obviates the need for a larger, more
magical construct.  This isn't the case here - you are simply defining
an alternate syntax for the same functionality as image-set() + Media
Fragments.

That's not a problem, just making it clearer what the scope of your
suggestion is.

Actual comments - this seems to be equally powerful to just combining
image-set() and Media Fragments.  The maintainability issue is
equivalent to storing the image-set() into a variable.

For example, your code:

> @image-map my-sprites {
>     src: url(toolbar-icons.png) 100dpi,
>           url(toolbar-icons-2x.png) 300dpi,
>           url(toolbar-icons-print.png) 600dpi );
>     cells: 16 2;  /* 16 in a row, 2 rows */
>     parts: icon-bold,  /* logical names of cells, one by one */
>              icon-italic,
>              icon-font-name,
>              icon-font-size,
>              ...;
> }

could be written as:

:root {
  var-toolbar-icon-bold: image-set( "toolbar-icons.png#xywh=0,0,20,20" 100dpi,

"toolbar-icons-3x.png#xywh=0,0,60,60" 300dpi,

"toolbar-icons-print.png#xywh=0,0,120,120" 600dpi );
  var-toolbar-icon-italic: image-set( ... );
}

Then used as:

foo { background-image: var(toolbar-icon-bold); }

Roughly the same footprint, but built using only things that already
have experimental implementations.

~TJ
Received on Tuesday, 13 November 2012 20:10:43 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:21:02 GMT