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

Thanks for the links. I note that some of the proposed pseudo-classes 
inteserects the ones that were proposed at www-style, which is an 
interesting fact.

However, adding pseudo-classes per-element is a bad idea since it will lead 
to inconsistencies. It should be discussed at the CSS Working Group, anyway.

I think I'm going to start a CSS editor draft about it, in the hope an UA 
implementor will take it to a higher level.



-----Message d'origine----- 
From: Dimitri Glazkov
Sent: Friday, February 03, 2012 6:34 PM
To: François REMY
Cc: DOM WG ; Alex Mogilevsky ; Lea Verou
Subject: Re: [progress-events] Loading, Interactive and Error states for 
downloaded resources -- fallback content

Hello

I am not actively pursuing this at the moment, but perhaps there's
something useful to dig up from this thread:
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-April/thread.html#31315

There's some more discussion on the bug:
https://bugs.webkit.org/show_bug.cgi?id=71216

:DG<

On Fri, Feb 3, 2012 at 4:04 AM, François REMY <fremycompany_pub@yahoo.fr> 
wrote:
> Dear DOM Working Group,
>
> After some requests in the CSS Working Group (www-style) [1], I would like
> to see if it was possible to start a thread on a common Object Model for
> progress and load state on downloaded resources.
>
> The problem is the following: many of us would like to see an ":error" and 
> a
> ":loading" pseudo-classes introduced in CSS to match IMG, IFRAME, SCRIPT 
> or
> VIDEO tags based on their load state. However, it quickly appeared that 
> the
> CSS working group didn’t have the tools in hand to specify what the 
> ":error"
> and ":loading" pseudo classes should match. My first attempt was to use 
> the
> readyState property but the property can take a different set of values 
> (and
> even different return types) on each element so it’s not a suitable
> solution. Since readyState is killed by its legacy issues, let’s define
> something new that takes in consideration that problem.
>
> A resource may fails to load for many reasons, but the two most important
> issues are :
>   (1) failled to download to resource
>   (2) failled to interpret the resource (=unrecognized format).
>
> For the download part, I propose to reuse the HttpRequest model defined in
> XHR Level 2. It could work easily for any kind of download process.
>
> For the interpretation part, I propose the following model, based on a
> ResourceInterpreter. The ResourceInterpreter is specific to each media 
> type
> an has the following defintion :
>
> IResourceInterpreter := interface {
>
>   acceptedFormats: string
>       A value indicating the accepted resource MIME types (ie: “image/*”,
> “video/*” or “text/html, */*”)
>           Should at least contains all the mime types contained in the
> Accept header sent by the underlaying http request.
>       Read-only.
>
>   isInitialized : bool
>       Returns a value indicating that the current resource interperter has
> been initialized.
>       Read-only.
>
>   isInteractive : bool
>       Returns a value indicating that the current resource interpreter can
> return a partial response
>           eg: interlaced JPEG, partial VIDEO, SVG with undownloaded linked
> images...
>       Read-only.
>
>   isCompleted : bool
>       Returns a value indicating that the current resource interpreter can
> return a final response.
>           note: this includes cases where isBroken is set to true and 
> where
> the result is null.
>       Read-only.
>
>   isBroken : bool
>       Returns a value indicating that the current resource interpreter
> failled to interpret given data.
>       Read-only.
>
>   httpRequest : HttpRequest (=XMLHttpRequest Level 2+)
>       Returns the underlying HttpRequest of the element, or null if it
> hasn’t been initialized yet.
>           ResponseType should be set to ArrayBuffer. ReadyState should be
> LOADING (3) at least.
>       Read-only.
>
>   result: any
>       Any object that represents the transformed response. Can be the 
> parent
> IMG or VIDEO tag, if any.
>           Should return null if an error occured.
>       Read-only.
>
>   oninitialized : event
>   oninteractive : event
>   oncompleted : event
>   onbroken : event
> }
>
> Any element that can trigger an HTTP request should then implements the
> IResourceInterpreter interface.
>
> Then, the CSS WG would be allowed to define five new pseudo-classes :
>
>   :uninitialized -- matches any element implementing the
> IResourceInterpreter interface and having isInitialized set to false.
>   :loading -- matches any element implementing the IResourceInterpreter
> interface and having isInitialized set to true and isCompleted to false.
>   :interactive -- matches any element implementing the 
> IResourceInterpreter
> interface and having isInteractive set to true.
>   :loaded -- matches any element implementing the IResourceInterpreter
> interface and having isCompleted set to true and isBroken to false.
>   :error -- matches any element implementing the IResourceInterpreter
> interface and having isBroken to true.
>
> Use cases includes :
>
>   - show fallback content for ":error" IMG, AUDIO or VIDEO tags
>   - display a message asking the user to wait while there's a 
> "IMG:loading"
> match
>   - hide any ".galery img:loading" element, or show a fallback
>   - furnish a fallback content for ":loading" and ":error" IFRAME whose
> content is sent in a named flow (CSS3 Regions), by setting their "content"
> property. [2]
>
> That would also makes it possible for a script to get a binary
> representation of an image simply by using "var buffer =
> myImage.httpRequest.response;" (prevents the use of a new XMLHttpRequest
> object using the same URL).
>
> Best regards,
> François
>
>
> [1] refers to mails from Lea Verou, Matt Wilcox, Charles Pritchard, and
> myself (at least).
> [2] this problem currently has no solution, as acknowledged by Alex
> Mogilevsky, spec editor.
>

Received on Friday, 3 February 2012 18:11:01 UTC