Re: [css-images] Lifting restrictions on nesting image-set()

On Oct 3, 2014, at 6:25 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:

> On Fri, Oct 3, 2014 at 2:58 AM, Dirk Schulze <dschulze@adobe.com> wrote:
>> 
>> On Oct 2, 2014, at 10:57 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
>> 
>>> Currently, the image-set() function forbids more image-set()s from
>>> nested inside of it, either directly or inside of other <image> values
>>> (like nesting within a cross-fade()).
>>> 
>>> On the call two weeks ago, I said that I don't think this restriction
>>> is actually needed.  It was originally added due to the complexity of
>>> handling fallback across nested things, but we removed the fallback
>>> ability so that we could later produce a well-tuned fallback()
>>> function or something similar that handled all the fallback properly.
>>> 
>>> Now, though, it shouldn't be hard.  Nesting them is still *weird*, and
>>> there's no reason to do so, but there's no reason to *restrict* it,
>>> which requires additional code to detect and enforce.
>>> 
>>> (I don't currently properly define how the resolution change actually
>>> gets applied to the image; however I define it, some answer will fall
>>> out for what nesting them means.  The actual answer isn't important,
>>> because there's no use-case for nesting them.)
>> 
>> Would it be harmful to investigate in a later version of the spec? In general I like the idea but think that browser need to catch up first. Deep nesting can be tricky. What about a MAY in the spec that turns into a MUST later?
> 
> What do you think might be tricky about deep nesting?  You just
> process at the top level based on the information at that level
> (<resolution>), and make a choice.  If that choice is a function, you
> turn that into an image somehow; this might involve processing a
> second image-set().  Eventually you bottom out into either a url or a
> generated image, along with an intrinsic resolution override.

It happens quite often that “just” turns out to be trickier than expected.

Greetings,
Dirk

> 
> ~TJ

Received on Friday, 3 October 2014 17:16:26 UTC