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

Re: [css4-images] First draft of css4-images, feedback requested

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Tue, 7 Aug 2012 08:22:26 -0700
Message-ID: <CAAWBYDC6zwx1VRT9_Ciog-yAyZ3w95y2_iR-X3RL0_-eREwPwA@mail.gmail.com>
To: Sebastian Zartner <sebastianzartner@gmail.com>
Cc: www-style list <www-style@w3.org>
On Mon, Aug 6, 2012 at 10:57 PM, Sebastian Zartner
<sebastianzartner@gmail.com> wrote:
> I am missing the definition of a rectangular gradient like the example at
> pixel2life.com shows [1].

That should just be an addition to the shape keywords you can provide
to radial-gradient().  My initial draft long ago had square,
rectangle, diamond, rhombus, and box (use the box's own shape,
respecting rounded corners, etc.).  I removed them because there was
no graphics library support for them.  (The same thing might kill
conic gradients.)

> Regarding issue 1 (nesting image-set()s):
> I guess it needs to be differentiated between nesting image-set()s directly
> within each other and having image-set()s inside image()s, which are placed
> inside another image-set().
> While direct nesting doesn't make sense in my eyes, allowing them within
> image-set() sounds logical.

That still doesn't solve the issue of what to do about the stacked
resolutions, though.  That's the important question!  ^_^

> Regarding issue 2 (fallback behavior for image-set()):
> I agree that people don't need an additional fallback behavior when they can
> use use image() inside of image-set(). So the user agent must choose the
> most appropriate resolution of an image-set().

Yeah, I think this might be okay.  I'll wait and see how Hixie
responds to suggestions about fallback in @srcset, but I suspect he'll
reject them, and I'll harmonize with that.

> Regarding issue 3 (only allow 'x' within image-set() instead of
> <resolution>):
> The use case for printing is big. So restricting to 'x' doesn't make sense
> to me neither.

Also my thoughts.

> Regarding issue 10 (image-resolution and image-set()):
> I'd say image-resolution should be used to overwrite the resolution of the
> image and should be 'auto' by default, which means to keep the resolution
> untouched.

Yeah, that's what I was considering.  I doubt changing the initial
value will be difficult, as no browser implements it yet, just
printers (and they don't support the CSSOM, so the initial value is
undetectable as long as I don't change its behavior).

> Furthermore providing a resolution for images inside image-set() should be
> optional to allow using the resolution of the image's metadata.

The entire point of image-set() is to let you do resolution-based
negotiation.  Leaving the resolution to the image's metadata defeats
the purpose.

Received on Tuesday, 7 August 2012 15:23:17 UTC

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