- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Fri, 3 Oct 2014 12:25:35 -0400
- To: Dirk Schulze <dschulze@adobe.com>
- Cc: www-style list <www-style@w3.org>
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. ~TJ
Received on Friday, 3 October 2014 16:26:21 UTC