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

On Wed, Feb 22, 2012 at 9:53 AM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> On 2/22/12 12:43 PM, Tab Atkins Jr. wrote:
>> Presumably it should be identically usable in the other<image>-using
>> properties besides 'content', right?
>
> 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.)


>> What makes it hard to use in 'content'?
>
> 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's reasonable that a *good* implementation would take more time.  We
>> have a similar difficulty. I'm curious what the use-case for
>> -moz-image-rect() was in the first place, if not precisely what you
>> describe (lots of references to the same image with different rects).
>
> 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.

~TJ

Received on Wednesday, 22 February 2012 18:11:34 UTC