W3C home > Mailing lists > Public > www-style@w3.org > December 2011

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

From: François REMY <fremycompany_pub@yahoo.fr>
Date: Wed, 28 Dec 2011 15:52:21 +0100
Message-ID: <9D8712EF76A44B4CA973CCB91A7EE433@FREMY2>
To: "Lea Verou" <leaverou@gmail.com>
Cc: "www-style list" <www-style@w3.org>
In fact, my idea was to modify the DOM api to add the "error" state. It's 
not logical that such a state don't exist, and if it don't exists, it's 
because the API is inherited from the good old days of IE4.

I really have the feeling CSS and DOM naming should try to be as close as 
possible, to allow reuse of knowledge. Anyway, if the DOM WG is not ready to 
add a new "error" value to readyState for whatever reason, I don't reject 
the idea of using a new name for the CSS purpose, but I feel it's a waste of 
an opportunity to move the web convergence forward. But this is maybe my 
love for ECMAScript that makes me think like that, I don't know.

> Using currently defined states :
>    img:readystate(uninitialized) { content: attr(alt); }
> Additionnaly, we could probably add a new state named "error" :
>    img:readystate(uninitialized) { content: 'Loading...'; }
>    img:readystate(error) { content: attr(alt); }

BTW, even if we end up in lengthy selectors in this case, I don't think this 
is important since that feature should not be used commonly, usually less 
than three times in a website stylesheet.


[EDIT] It seems that the current HTML5 specification defines the readyState 
proprety on the <VIDEO> element only. However, an image has the notion of 
"ready state" as explained here : 
http://www.w3.org/TR/html5/embedded-content-1.html#img-none but there's no 
way to retreive it (beside the very partial "complete" attribute).

-----Message d'origine----- 
From: Lea Verou
Sent: Wednesday, December 28, 2011 3:20 PM
To: François REMY
Cc: www-style list
Subject: Re: [css4-ui]/[css4-selectors] Pseudo-class for selecting broken 
images & other external resources

On 28/12/11 14:23, François REMY wrote:
> Nice idea. Extending :invalid is a bad idea, however, since it has a FORM 
> semantic and many style sheets make the assumption that :invalid only 
> apply to INPUTs &co based on user input and apply formatting accordingly 
> (red background, red text, ...) that are not meant to be applied to an 
> undisplayble image.
> Maybe using readyState could give more granular control over the process? 
> While an image is loading and/or if the image has failled to load, its 
> readystate is "uninitialized".
>    img:onreadystate(uninitialized) { content: attr(alt); }
> Additionnaly, we could probably add a new state named "error" :
>    img:onreadystate(uninitialized) { content: 'Loading...'; }
>    img:onreadystate(error) { content: attr(alt); }
> Just my two cents,
> François
Yeah, I figured extending :invalid would probably be a bad idea, but
thought I'd throw it in anyway :)

Regarding more granular control, I like the idea of being able to target
the "loading" state, something my proposal didn't address. However, I'm
not sure anything besides these states is needed. Redefining readyState
to have different states than the DOM APIs would be confusing for
authors, and maintaining the same states is pointless and would, in the
common case, result in very lengthy selectors.
If we want a parameterized pseudo-class instead of two different
pseudo-classes (:error and :loading), I think it should have a different
name. perhaps :loading-state() or something.

Lea Verou (http://lea.verou.me | @LeaVerou) 
Received on Wednesday, 28 December 2011 14:53:01 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:08 UTC