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