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

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

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Wed, 22 Feb 2012 10:10:43 -0800
Message-ID: <CAAWBYDDrv8MK13w6z=6nyGmOOnDA2vR09gBeQrw+W-kRMCbj2Q@mail.gmail.com>
To: Boris Zbarsky <bzbarsky@mit.edu>
Cc: www-style@w3.org
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.

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

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:12 UTC