- From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
- Date: Tue, 10 May 2011 08:01:49 +1000
- To: "Tab Atkins Jr." <jackalmage@gmail.com>
- Cc: fantasai <fantasai.lists@inkedblade.net>, "www-style@w3.org" <www-style@w3.org>, public-media-fragment@w3.org
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