W3C home > Mailing lists > Public > www-style@w3.org > May 2011

Re: [css3-images] Features Overview

From: fantasai <fantasai.lists@inkedblade.net>
Date: Fri, 06 May 2011 15:48:59 -0700
Message-ID: <4DC47ADB.3060906@inkedblade.net>
To: "www-style@w3.org" <www-style@w3.org>, public-media-fragment@w3.org
On 05/06/2011 11:41 AM, Brian Manthos wrote:
>>> background-image: url('sprites.png#xywh=10,30,60,20');
> Interesting.
> How does this behave for formats that contain multiple source resolutions within the same file?
> 	background-image: url("http://www.microsoft.com/favicon.ico#xywh=10,30,60,20");

Hm, that's a good question. If we look at the sizing algorithm,
it says to use the largest size when determining the intrinsic dimensions
if there are multiple sizes. So we'd use that, and then clip out the
piece represented by the fragment identifier to get the intrinsic size.

The CSS‚áčObject negotiation algorithm says you use the intrinsic size as
an input into the sizing algorithm to compute a "concrete object size".

Once you have a concrete object size, then you go back to the image
and tell it to paint itself into this rectangle. How it negotiates a
mismatch between itself and the "viewport" it's given isn't defined
by CSS. (It's out-of-scope, since different formats behave differently
when confronted by such a mismatch.) I assume in the normal case (no
fragment), a .ico file will choose the source resolution that best
matches the size it's given. If the fragment is given in percentages,
that still makes sense here. But if it's given in pixels, all the
fragments will be the same size...

Probably what you /want/ to do is translate the pixel sizes to percents
based on the source resolution that was chosen in the intrinsic sizing
step, then choose the one that gives you the best match, just like you
would for the whole image.

Does that make sense?

(On a related note, the Media Fragments WG needs to specify what happens
when the fragment identifies coordinates that are not within the image

Received on Friday, 6 May 2011 22:53:46 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:38:45 UTC