W3C home > Mailing lists > Public > public-media-fragment@w3.org > May 2011

Re: [css3-images] Features Overview

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Mon, 9 May 2011 14:50:02 -0700
Message-ID: <BANLkTikKcceYd4P_aYq=6sx3-ms5kesHmQ@mail.gmail.com>
To: fantasai <fantasai.lists@inkedblade.net>
Cc: "www-style@w3.org" <www-style@w3.org>, public-media-fragment@w3.org
On Fri, May 6, 2011 at 3:48 PM, fantasai <fantasai.lists@inkedblade.net> wrote:
> 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,
>  http://dev.w3.org/csswg/css3-images/#sizing
> 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?

Not quite.  The fragmented url is supposed to transparently represent
the cut-down image, not a full-size image with some magic processing
instructions that end up cutting it down later in the processing
pipeline.  As far as CSS is concerned, it's a smaller image already,
before CSS touches it.

Exactly what that means in terms of multiple-size images is a little
harder to define, then, as Media Fragments doesn't currently define
what happens to a fragmented multiple-size image.  What should happen
is that MF defines the "apply fragment against largest image size,
then convert to percentages to apply to other images", or something
similar, so CSS can then just deal with an ordinary multiple-size

The behavior of fragments should either be completely handled by CSS
or completely handled at a lower level.  If we're using MF, we should
shoot for the latter, which means MF needs some additions to handle
all the relevant cases.

Received on Monday, 9 May 2011 21:52:58 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:52:46 UTC