W3C home > Mailing lists > Public > www-dom@w3.org > January to March 2012

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

From: Dimitri Glazkov <dglazkov@chromium.org>
Date: Fri, 3 Feb 2012 09:34:34 -0800
Message-ID: <CADh5Ky2qOa9uYzne9t+ruBOSMRAydSs+cX8gLECOkwvpb6JEcw@mail.gmail.com>
To: François REMY <fremycompany_pub@yahoo.fr>
Cc: DOM WG <www-dom@w3.org>, Alex Mogilevsky <alexmog@microsoft.com>, Lea Verou <leaverou@gmail.com>
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 17:35:11 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 22 June 2012 06:14:09 GMT