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

Re: An error pseudoselector for media

From: François REMY <fremycompany_pub@yahoo.fr>
Date: Fri, 3 Feb 2012 16:10:06 +0100
Message-ID: <41919E9C105548B1985467A8D4724EC8@FREMYD2>
To: "Tab Atkins Jr." <jackalmage@gmail.com>, "Charles Pritchard" <chuck@jumis.com>
Cc: <www-style@w3.org>
Last time the subject was thrown, by Lea Verou, no major advance was done. 
The use cases have been found, a good syntax has been found. Now, we need an 
in-depht specification.

I also had a discussion with Alex Mogilevsky about IFRAME-Content Fallback 
and CSS Named Flows. There was a concensus that the HTML working group had 
to be involved in the proposal in order to succeed, since defining the 
LOADING and ERROR states belongs to HTML, not to CSS. At this time, the 
states are defined at some places but are not exposed anywhere in a coherent 

I just sent a mail to www-dom@w3.org to get someone there to react on this 
(http://www.w3.org/mid/6A001EBAB6984FC38065AE82EF06647F@FREMYD2). However, I 
may have used a wrong mailing list since I'm not used to the HTML side of 
the w3c; www-html seems almost dead.

-----Message d'origine----- 
From: Tab Atkins Jr.
Sent: Friday, February 03, 2012 3:24 PM
To: Charles Pritchard
Cc: www-style@w3.org
Subject: Re: An error pseudoselector for media

On Thu, Feb 2, 2012 at 10:57 PM, Charles Pritchard <chuck@jumis.com> wrote:
> It occurred to me this evening, as I was chatting on webapps about
> createObjectURL, that an error pseudoselector for image elements would be
> darn handy.
> I had to use JavaScript for my project recently, because my primary image 
> is
> a PNG but I've embedded an SVG resource as a fallback.
> Well, my primary image is an SVG at a separate url, and my fallback is an
> embedded SVG... but the point remains.
> It'd be swell to have something like this
> #myImage::error {
>  content: url(#fallback);
> }
> <img src="howdy.png" />
> <svg id="fallback" />
> I know that there are some vendor specific selectors that touch the
> periphery of this case.
> They're mostly about handling the image-broken visualization.
> onerror does not succumb to issues of CORS, so it seems quite safe to use 
> it
> as a semantic with CSS.
> Further, it's possible that an error will occur at any time, such as a low
> memory condition.
> That's something that JS is not so awesome at handling.

Yes, Matt Wilcox started a thread on this subject a few weeks ago.  I
recommend reading that and continuing the conversation there.

Received on Friday, 3 February 2012 15:10:44 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:38:55 UTC