W3C home > Mailing lists > Public > www-style@w3.org > December 2011

Re: [css4-ui]/[css4-selectors] Pseudo-class for selecting broken images & other external resources

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Thu, 29 Dec 2011 07:52:32 -0800
Message-ID: <CAAWBYDDfjsCSNWjy=EioEULWJEWrY8P6JX6ijZuYmfnmgSR3Cg@mail.gmail.com>
To: Fran├žois REMY <fremycompany_pub@yahoo.fr>
Cc: Brian Kardell <bkardell@gmail.com>, www-style list <www-style@w3.org>, Lea Verou <leaverou@gmail.com>
On Thu, Dec 29, 2011 at 2:48 AM, Fran├žois REMY
<fremycompany_pub@yahoo.fr> wrote:
> Yes, a script can handle the case of an XHR request *it initiated*, and it
> has to. But sometimes, you just use an async SCRIPT tag to an external
> service that may fail to load for reasons you can't explain (too heavy load,
> http error, script disabled...). You have no control over that process.
> There's no "onerror" you can watch for. In the best case, there's an
> "onload".
> At this time, you can't know if the script is "still downloading" or "has
> been aborted". If the script fails to load, you would like to display an
> error message to the user. While the script is still downloading, you would
> like to display a "Loading" message, or hide the dynamic content placeholder
> until it has something to display. Do you really have to do this using a
> script? A script should be responsible of what it initiated, but there must
> be a way for a document to react on the download faillure of its own content
> without using a script, that could fail to load too.
> I feel like CSS is able to handle such cases perfectly and is more efficient
> to do this that any script you could use

If it's currently difficult to detect the state of an async script
load, it's probably best to fix that directly in JS, rather than just
patching it in CSS.  If it fails, you probably want to do more than
just display a message; you want to run some more JS.  Once you've
gotten the ability to run JS on failure, it's then trivial to do
something like add a class or attribute to <body> and then use that
for CSS.

> (BTW, if you rely on scripting to
> display error messages you takes the risk of failling to notice faillure if
> scripting was disabled).

That's what <noscript> is for.  As well, it seems wrong to conflate
the error condition of "JS is turned off" with "a <script> tag had a
load error".  These are two very different states, and you almost
certainly want to display a different error message in the two cases.

> Additionnaly, a "uninitialized/loading/loaded/error" state is applyable on
> many content types (IMG, VIDEO, SCRIPT, LINK...) and can be used to define
> fallback behaviors that are far more complex than just "another fallback
> content" as you proposed in your last mail. You could decide to hide a DIV
> containing an image that failled to load. You could decide to display a
> message while a video is still loading. You may want to show a message to
> the user if the video failled to load. You can probably do all this by
> script, but I feel like it's a job for the CSS engine, not for a script.

Those are some good use-cases that can't be addressed via image().
Displaying a message or a throbber while a video is loading seems
useful, though browsers already have some indicator that it's loading.
 As well, a <video> failing to load can probably be addressed fine in
many cases by showing/hiding a static message, rather than running

Received on Thursday, 29 December 2011 15:53:24 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:08 UTC