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

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

From: Sebastian Zartner <sebastianzartner@gmail.com>
Date: Sun, 19 Aug 2012 01:22:57 +0200
Message-ID: <CAERejNYEkgGHsVyjOQTrMwTaMsf6tuF694RRGWE3dOzo_9orjA@mail.gmail.com>
To: "Tab Atkins Jr." <jackalmage@gmail.com>
Cc: www-style list <www-style@w3.org>
>
> That should just be an addition to the shape keywords you can provide
> to radial-gradient().

Ok, fine.


> My initial draft long ago had square,
> rectangle, diamond, rhombus, and box (use the box's own shape,
> respecting rounded corners, etc.).

Great. Much more than I had in mind.


> I removed them because there was
> no graphics library support for them.  (The same thing might kill
> conic gradients.)
>
But just because no graphics library supported them, it doesn't mean they
can't be put into the draft.

Btw. an example is missing for the conic-gradient().


>  > 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!  ^_^
>
If nesting image-set()s should be allowed in any form, the outer-most
image-set() overwrites the resolution of the inner ones.


> > 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.
>
It just feels strange to me that the actual image's resolution is made
completely irrelevant with that approach. It's up to the developer to
define the correct resolution.
Here's a (more or less stupid) example:

image-set("600dpi-Image.jpg" 100dpi, "300dpi-Image.jpg" 200dpi,
"100dpi-Image.jpg" 300dpi);

So you tell the user agent wrong resolutions and the 600 dpi image will
probably the biggest in regard of the file size. Considering the actual
resolution of the images would avoid such conflicts.

Though when it's about saving bandwidth it makes much more sense to decide
considering the actual file size rather than the image's resolution, which
can be easily fetched via HEAD requests. So in the example above there
would be three HEAD requests. The first one would response that the
Content-Length is 1000000, the second is 500000 and the third 150000 and
the user agent with the slow connection would choose the last one instead
of the first one.

Sebastian
Received on Saturday, 18 August 2012 23:23:25 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:58 GMT