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

On Tue, Aug 7, 2012 at 8:22 AM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:

> 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.)
>

Diamond gradients could easily be emulated (they're basically 2 axial
gradients with clipping).
It's a fairly useful construct so it would be nice to have in the spec.


>
> > 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.
>
> ~TJ
>
>