Re: [css3-images] Features Overview

On Tue, May 10, 2011 at 7:50 AM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
> 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
> image.
>
> The behavior of fragments should either be completely handled by CSS
> or completely handled at a lower level.

I think I agree (assuming I've understood the issue properly).

>  If we're using MF, we should
> shoot for the latter, which means MF needs some additions to handle
> all the relevant cases.

So, can you propose what additional text needs to be added?

Cheers,
Silvia.

Received on Monday, 9 May 2011 22:02:37 UTC