- From: Sebastian Zartner <sebastianzartner@gmail.com>
- Date: Sun, 19 Aug 2012 01:22:57 +0200
- To: "Tab Atkins Jr." <jackalmage@gmail.com>
- Cc: www-style list <www-style@w3.org>
- Message-ID: <CAERejNYEkgGHsVyjOQTrMwTaMsf6tuF694RRGWE3dOzo_9orjA@mail.gmail.com>
> > 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 UTC