Re: background-image-frame

>-----Original Message----- 
>From: Simon Fraser
>Sent: Friday, July 08, 2011 4:52 PM
>To: Andrew Fedoniouk
>Subject: Re: background-image-frame
>On Jul 7, 2011, at 11:51 PM, Andrew Fedoniouk wrote:
>> It would be convenient if CSS will have 'background-image-frame: "string" 
>> '
>> property.
>I presume we'd also need border-image-frame: and similar for any other
>image-using properties that we have?

If it is needed then yes.  If we will use "string"s for specifying name
or index of the frame then changes in the spec are minor.

>> PNG and other image formats support annotated/taged/named
>> sub-images
>Can you cite references for this?

Here is definition of name/value textual chunks:
These chunks with predefined names "id" or "name" can be used
to identify frames. In the same way as implemented in aPNGs:
See Frame Control Chunk that prepends each frame in aPNG.
Similarly name of the frame can be provided as tEXt chunk.

>> so in principle they can be used as image-lists - single-file collections 
>> of
>> multiple images / frames.
>> CSS "sprites" as a workaround are quite popular among Web designers
>> but current solution [1] looks more like a hack rather than a solution.
>I think a media fragments syntax for named frames would be much more
>suitable. Then you could just do:
>background-image: url(foo.png?frame=kitten)
>or something.

The "something" part is the most interesting actually as
'url(foo.png?frame=kitten)' will not work as
'url(foo.png?frame=doggy)' will cause image to be downloaded
once again. Plus issues with proxies, etc.

Using anchors in URLs is probably better:

In any case something like this should be done.

But the main problem is to provide fallback mechanism for UAs that will not 
support of this feature. Subject of @supports mechanism?

Andrew Fedoniouk

Received on Saturday, 9 July 2011 02:49:02 UTC