- From: Lea Verou <leaverou@gmail.com>
- Date: Wed, 28 Dec 2011 16:20:10 +0200
- To: François REMY <fremycompany_pub@yahoo.fr>
- CC: www-style list <www-style@w3.org>
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(error) { 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:20:51 UTC