- 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