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

On Dec 28, 2011 7:39 PM, "Tab Atkins Jr." <jackalmage@gmail.com> wrote:
>
> On Wed, Dec 28, 2011 at 4:02 PM, Brian Kardell <bkardell@gmail.com> wrote:
> > That only covers images, I think the point made and reiterated
throughout
> > was that this would be a nice feature for any external resource, so
while
> > that is a significant step forward from where we are today, it seems yes
> > there are numerous cases that this would not cover...
>
> Yes, another use-case presented was displaying an error message based
> on script-loading status.  This is complex in different ways, though.
> For example, XHRs are used in the same context as <script>-based
> loading, and would benefit in the same way (perhaps EventSources as
> well).
Well.... Similar, but not the same... They are different things by design.
I can see how being able to attach xhr to an element could be useful, but
there is not always even a correlation that you can make like that... In
fact, Xhr could have no correlation with the DOM or N correlations...  Is
it so bad that they are different in this way?  I don't think you need to
extend this to xhr for it to be really useful.

> There's no DOM element associated with an XHR, though, so you
> can't just use a pseudoclass on an element to indicate this.  One
> possible approach around this is to somehow associate loads with an
> identifier and then use the ident in a pseudoclass, so that arbitrary
> data loads can be hooked on.
>
> On the other hand, hooking the error events in JS and updating, say,
> an attribute on the body (for use in targetting selectors) is pretty
> easy, works for all the various data-loading mechanisms, and can be
> done today.
Depends on the definition... If you have subject too, you would have
something like a nice simple CSS mechanism for styling blocks based on when
resources inside were loaded or how to bail in a UI friendlier way if
anything (or even certain things) in it fails to download and it would be a
universally understood mechanism..   Doing that in script today would
actually be prohibitively snarly and there is really nothing even remotely
universal about the approaches to any one part of it now...

> Are there ways we can make this easier, and would it be
> worthwhile to expend the effort (in speccing, testing, and
> implementing) to do so?

Yeah....I don't know.  That's the real question :-)  Interesting enough to
spend some discussion time to figure that much out at least though...no?

> ~TJ