- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Tue, 13 Nov 2012 12:09:55 -0800
- 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 UTC