- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Wed, 11 May 2011 14:58:15 -0700
- 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. ~fantasai
Received on Wednesday, 11 May 2011 21:58:44 UTC