Re: lazy loading for images via css

On Sat, Jun 29, 2013 at 9:16 AM, Liam R E Quin <liam@w3.org> wrote:
> On Sat, 2013-06-29 at 09:12 +0100, Simon Sapin wrote:
> [...]
>> > background-image: image(postponed "foo.png");
>>
>> I think we’d only want the last one. First, redundant features that do
>> exactly the same thing should be avoided.
>>
>> But more importantly it’s not just background images: CSS as more and
>> more places where images are used: list-style-image, border-image,
>> content, … We don’t want to define additional properties or syntax for
>> each of them. Adding stuff in image() has the advantage of being
>> self-contained.
>
> I wonder if an alternative would be an on-demand( <url> ) function that
> could go anywhere that url() can go today? Then it could work for
> sounds, or other resources.

Yes, this is another direction we could take.  Only issue I have with
this is that the most common case for urls in CSS is images, which is
why image() and image-set() optimize the syntax and allow taking
strings directly.  This proposal would mean that you'd have to do:

background: image(on-demand("foo.svg"), on-demand("foo.jpg"));

rather than:

background: image(defer "foo.svg", "foo.jpg");

We could do both, treating the defer as a property of the url, such
that applying it via either method works, even when combined.  Or we
could just do images for now, and wait for demand for other types of
urls to add the more generic solution?

(I'm totally down with more url functions, fwiw.  One oddity - we
can't realistically let them handle unquoted urls, as we can't handle
errors in the same way as url() is handled, since url() is done in the
tokenizer.  We shouldn't have ever put url() into the tokenizer in the
first place, but shrug.)

~TJ

Received on Monday, 1 July 2013 17:18:51 UTC