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 16:51:54 +0100
Message-ID: <89ED5C4A30D14016B5FFE42D122AB605@FREMY2>
To: "Brian Kardell" <bkardell@gmail.com>
Cc: "Lea Verou" <leaverou@gmail.com>, "www-style list" <www-style@w3.org>
Did you mean something like this?

    #dynamicContent:has( script:readystate(error) ) {

        background: #ffeeee; color: darkred;
        content: ‘Sorry, there was an error while loading the dynamic feed. 
Please refresh to try again’;

    }




From: Brian Kardell
Sent: Wednesday, December 28, 2011 4:06 PM
To: François REMY
Cc: Lea Verou ; www-style list
Subject: Re: [css4-ui]/[css4-selectors] Pseudo-class for selecting broken 
images & other external resources

Since we are talking about level 4, its good to note that there is a subject 
selector and that script tags also have ready states... Given these, it 
would be possible to hide a block or show a loading image or block in its 
place while its own assets are loading (images or scripts referenced 
inside) - as well as potentially deal with failure to load in a 
semi-more-user-friendly kind of way...




On Wed, Dec 28, 2011 at 9:52 AM, François REMY <fremycompany_pub@yahoo.fr> 
wrote:
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.

François

----------------------------------------------------------
[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 15:52:23 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:47 GMT