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

Sure... if we had :has()  (pretty please? :)) and it were capable enough to
allow that...  Or something along those lines - that's the general idea...
States are kinda funny in CSS - some are exclusive to the element and in
others you are in that state if any of your children is in that state and
so on - so it sort of depends on how that is defined too.  It definitely
seems useful - I don't know how many times I see people writing variants on
the same code "throw a throbber in right here that says "loading" until
it's really ready..."  Allowing you to tap into that somehow could create
some interesting new patterns and ideas.


On Wed, Dec 28, 2011 at 10:51 AM, François REMY
<fremycompany_pub@yahoo.fr>wrote:

> 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<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)
>
>
>
>