Re: [progress-events] Loading, Interactive and Error states for downloaded resources -- fallback content

CSS specifications have to define guidelines for their pseudoclasses, even 
if they relies on DOM/UA to know when an element is, for example, 
'interactive' or not. It's up to the HTML specification to define how 
'loading', 'interactive' or 'error' translate for the elements they define. 
But the guidelines are here to provide information about the expected 
result.

CSS Selectors Level 3 put predecence on this behavior with definitions like 
:
• The :hover pseudo-class applies while the user designates an element with 
a pointing device, but does not necessarily activate it. For example, a 
visual user agent could apply this pseudo-class when the cursor (mouse 
pointer) hovers over a box generated by the element. User agents not that do 
not support interactive media do not have to support this pseudo-class. Some 
conforming user agents that support interactive media may not be able to 
support this pseudo-class (e.g., a pen device that does not detect 
hovering).

You can find a similar pattern used in my specification :
• The :interactive pseudo-class applies to any element which can load one or 
more external resources to use in its intrinsic content and which have 
retreived enough data to work approximately as if the full resource has been 
downloaded. This usually means that the user has the same level of 
interaction as if the download was complete, but that some information may 
be less accurate or unavailable to him. The level of approximation accepted 
is at the discretion of the element's own specification.

I don't understand how we can do things otherwhise. CSS cannot define 
pseudo-classes like ":loading" and say "The :loading pseudo-class applies to 
any element which has been defined by its specification to apply the 
:loading pseudo-class" (even if things are a little like that) because it 
would means that the HTML specification would be requierd to reference CSS 
specifications normatively.

-----------------------------

I've read the HTML spec about resource fetching, and it seems possible to 
slightly modify that algorithm to allow dynamic 'loading state' 
pseudo-classes. I'll try to work on it someday.

-----------------------------

Regards,
François





-----Message d'origine----- 
From: Anne van Kesteren
Sent: Monday, February 20, 2012 4:41 PM
To: DOM WG ; François REMY
Subject: Re: [progress-events] Loading, Interactive and Error states for 
downloaded resources -- fallback content

On Sun, 19 Feb 2012 18:27:35 +0100, François REMY
<fremycompany_pub@yahoo.fr> wrote:
> I indeed started a CSS draft that doesn't reference the features 
> described here. I just feel (and I wasn't alone) that DOM and CSS should 
> keep parity here if we want to implement that feature. It's not possible 
> to define such pseudo-classes if you don't define progress events in the 
> DOM, whatever they are, because we need an event to trigger pseudo-class 
> "rematching".

Since when is that the case? It might not be a bad idea, but CSS is
typically defined independently of pretty much anything else.


> In fact, what we need is some way to "know" how far the download process 
> is gone for any element which can trigger a download. I may want, in the 
> future, to simplify that proposal to only include really needed 
> components, but I feel that many of what I propose is requierd.

As I mentioned, you should integrate with http://www.whatwg.org/html#fetch
most likely.


> Anyway, if you want to see my "contributor draft", it's located here : 
> http://fremycompany.com/TR/2012/ED-css-content-state/

It's probably best to let specifications such as HTML define when the
pseudo-classes apply instead of the other way around.


-- 
Anne van Kesteren
http://annevankesteren.nl/

Received on Tuesday, 21 February 2012 13:45:39 UTC