Re: [css4-ui]/[css4-selectors] Pseudo-class for selecting broken images & other external resources

On 28/12/11 18:30, Brian Kardell wrote:
> I would think that most use-cases (including those spelled out by the 
> initial links) are more about HTTP errors... As long as the thing is 
> about readystate and did a consistent thing for all resources, I think 
> that things beyond that are a different class of problem -  i.e. 
> whether JavaScript threw an error once loaded or while interpreting or 
>  an image contained bad image data, etc.
>
> On Wed, Dec 28, 2011 at 11:17 AM, Boris Zbarsky <bzbarsky@mit.edu 
> <mailto:bzbarsky@mit.edu>> wrote:
>
>     On 12/28/11 6:01 AM, Lea Verou wrote:
>
>         Also, I'm not a browser developer by any means, but I'd guess it's
>         trivial to implement such a thing.
>
>
>     It's trivial to implement the matching (or at least it was in
>     Gecko). Getting dynamic updates right is not quite trivial, as usual.
>
>     I was going to say more, but dbaron's earlier post in this thread
>     covers what I was going to say.
>
>     The set of relevant states depends on the thing we're looking at,
>     by the way; for <object> Gecko also has -moz-type-unsupported,
>     -moz-handler-disabled, -moz-handler-blocked, -moz-handler-crashed,
>     -moz-handler-clicktoplay.  And defining when a script is "broken"
>     is very different from defining it for images...
>
>     -Boris
>
>
I think that the issue of an image that loads but can't be rendered 
should be addressed by the proposal, as the end result is usually the 
same as with HTTP errors so in most use cases, authors would need to 
select both. Ideally, with separate pseudoclasses for HTTP errors and 
broken data. If the same concept is applied to linked scripts and CSS 
files, it's even more important that they are separate, as most CSS 
files these days intentionally contain errors ("progressive 
enhancement") so it would be useless otherwise.

-- 
Lea Verou (http://lea.verou.me | @LeaVerou)