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

Thanks for your response.

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".

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.

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

Regards,
François



-----Message d'origine----- 
From: Anne van Kesteren
Sent: Monday, February 13, 2012 1:00 PM
To: DOM WG ; François REMY
Cc: Alex Mogilevsky ; Lea Verou
Subject: Re: [progress-events] Loading, Interactive and Error states for 
downloaded resources -- fallback content

On Fri, 03 Feb 2012 13:04:51 +0100, François REMY
<fremycompany_pub@yahoo.fr> wrote:
> Dear DOM Working Group,

We're called WebApps, fwiw.


I read through this a few times and while there may be use cases for some
more CSS pseudo-classes (though some seem problematic cross-origin, unless
CORS is in place), I'm not really convinced all the API bloat is needed.
You can easily define pseudo-classes without new APIs. If you need certain
hooks in the loading process I'd recommend filing bugs on the HTML
fetching algorithm with specific requests.

Some kind of evaluation of Mozilla's pseudo-classes for this would
probably also be good to make, to see what the problems were and how they
were addressed.


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

Received on Sunday, 19 February 2012 17:28:07 UTC