- From: Bert Bos <bert@w3.org>
- Date: Wed, 7 Mar 2012 19:58:49 +0100
- To: www-style@w3.org
On Tuesday 28 February 2012 02:22:12 Tab Atkins Jr. wrote: > On Wed, Feb 22, 2012 at 10:57 AM, Tab Atkins Jr. <jackalmage@gmail.com> wrote: > > This is something I meant to file on myself a while ago, but forgot > > about. :/ > > > > Before this morning, the image() function only skipped an image if > > it was a format that the UA couldn't decode or knew wasn't an > > image. While addressing some LC feedback, I broadened this to also > > skip an image if it's a URL that uses a fragment identifier syntax > > the UA doesn't understand. > > > > I'd like to slightly broaden this "invalid image" definition so > > that other features can hook into it. Specifically, I'd like to > > allow element() to trigger fallback in image() if it hits one of > > the "error" cases that currently produce a transparent image. If > > element() is used alone, it would still produce a transparent > > image as currently specified; it would just trigger fallback if > > used in image(). > > > > With an explicit hook, other sources of <image> could potentially > > hook into this as well, though I'm not currently aware of anything > > else that would want to. You mean like linear-gradient() and radial-gradient()? Why wouldn't they make sense inside image()? > > > > Any objections? > > I've heard no objections since Wednesday, so I've made this change. Bert -- Bert Bos ( W 3 C ) http://www.w3.org/ http://www.w3.org/people/bos W3C/ERCIM bert@w3.org 2004 Rt des Lucioles / BP 93 +33 (0)4 92 38 76 92 06902 Sophia Antipolis Cedex, France
Received on Wednesday, 7 March 2012 18:59:19 UTC