W3C home > Mailing lists > Public > www-style@w3.org > February 2012

Re: [css3-images] Image fallback feature's dependency on media fragments

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Wed, 22 Feb 2012 14:33:11 -0500
Message-ID: <4F4542F7.6060807@mit.edu>
To: "Tab Atkins Jr." <jackalmage@gmail.com>
CC: www-style@w3.org
On 2/22/12 1:10 PM, Tab Atkins Jr. wrote:
>> There is no such thing.  All properties that do uri stuff do pretty
>> different things, so they're handled on a case-by-case basis.
>
> list-style-image and border-image do pretty different things with
> their images?  Why?  (I'm trying to understand so I don't misstep in
> the future.)

The image in list-style-image needs to participate in vertical alignment 
in a particular way (which means that its size needs to make its way to 
the layout code) and never needs to be resized or tiled.

The image in border-image needs to be resized or tiled.  I haven't 
checked recently whether it also needs to affect layout.

In any case, the behavior you want out of them is pretty different.

>> url() in content is implemented in Gecko by creating an actual image element
>> with src set to that url, basically.  Which means that supporting MF syntax
>> means either adding support to it for<img>  or changing the implementation
>> of 'content' significantly.
>
> That seems weird, but okay.

It seems weird until you realize that the image in 'content' needs to 
participate in line layout exactly like an <img> does (with all the 
vertical alignment fun that entails), at which point it starts to make a 
lot of sense to reuse as much of that code as possible on the layout 
side.  That means using the "inline image" renderer object, which really 
wants to have an actual Element node associated with it that provides 
the image data, unless you significantly rewrite it.  Then the path of 
least resistance is to just give it an Element node that provides the 
image data.  ;)

>> That was precisely the use case, yes.  But since the clip rect is not stored
>> in the URI itself, the URI can just be passed to the image library and then
>> the clip rect applied if needed; the image library only sees one URI.
>
> I don't understand the issue, then.  Surely you could do the exact
> same thing for image() with an #xywh fragment, if that's easiest.
> Just lop the fragment off the url, pass it on to the image library,
> and convert the fragment into a clip rect for yourself.

For background images, I believe we can do something like that, yes.  I 
said that in my last mail.

For general image() in other contexts, the situation is different.

-Boris
Received on Wednesday, 22 February 2012 19:34:18 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:51 GMT