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

Re: [css3-images] Features Overview

From: fantasai <fantasai.lists@inkedblade.net>
Date: Wed, 11 May 2011 14:58:15 -0700
Message-ID: <4DCB0677.2090208@inkedblade.net>
To: www-style@w3.org
On 05/11/2011 10:50 AM, Brian Manthos wrote:
> Brian:
>>> 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");
> Brad Kemper:
>> Suppose we are trying to squeeze into a square that is,
>> say. 100px x 100px, and there are three choices:
>> 1,000px x 4px, 6px x 1,000px, or 50px x 60px. I think
>> I know which I'd choose, but maybe it isn't always clear cut.
> Let's assume you have a 100px x 100px div with 0 padding and 0 border-width
> and the 3 sizes within the same .ico file in your example.
> Would your choice the be the same or different for these cases:
> (a) background-size unspecified
> (b) background-size: 100px 100px;
> (c) background-size: 2px 10px;
> (d) background-size: 2px 100%;
> (e) background-size: 2px auto;
> As it stands today, background-size takes the image intrinsic dimensions as
> (optional) inputs and round/space takes post-background-size sizing as input.
> How far down the rabbit hole do we go for fragments to guess what's most
> desirable at render time?

I think which intrinsic size is the "intrinsic size" needs to be
clearly defined by the spec. Right now, the spec says to choose
the largest size. (I can clarify that to say "by area".) I think
this is relatively unambiguous.

If there are multiple ratios available at that size, then the
current spec says to pick the one that matches the "default object
size" most closely. This is an arbitrary selection, and we could
do other things. Reasonable options seem to be:
   1. Try to match the default object size
   2. Try to match a square
   3. Try to match any given size constraints (exact algorithm TBD)
I went with option 1. I don't mind doing another option, but #3
seems unnecessarily complicated, so I didn't bother trying to
figure it out, size-constrained .ico files not being a common
use case here. :)

The intrinsic size is used as input to the "concrete size". Once
you've resolved that to the "concrete size", then you *separately*
resolve how to draw into that rectangle. So the intrinsic size
might be a large square, but if the size resolution rules might
give you a small rectangle, in which case the .ico, having been
presented with this small rectangle and told to draw itself there,
might well choose a size other than the one given to the intrinsic
size determination.

The issue with pixel-determined fragments is that they become
nonsensical when you have a multi-size object. That is, as Tab
pointed out, a separate issue that MF needs to deal with.

Received on Wednesday, 11 May 2011 21:58:44 UTC

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