AW: Element Failure Mode

Hi Robert, 
I like the idea a lot.  The problem you describe is a big issue on some of our websites where many partner companies provide content.

Of particular interest, next to the alert mechanism itself, is the sort of threshold feature you describe.

This has particular relevance for contractual obligations between partner companies and could be use to track their performance (usually some degree of promise on performance is made, but this usually is not tracked on a per element basis).

Interesting thresholds would be
- response time
- total load time (time to last byte)
- amount of data transmitted
- size and proportion

-- Kai
Deutsche Telekom AG



> -----Ursprüngliche Nachricht-----
> Von: Robert Hansen [mailto:robert@fallingrocknetworks.com]
> Gesendet: Dienstag, 20. März 2012 09:13
> An: public-html@w3.org
> Betreff: Element Failure Mode
> 
> 
>  Hello, everyone - first time poster here, so please be gentle.
> :)
> I did talk to one guy on the IE team who suggested I post this here as
> it
> may make more sense as a change to HTTP, so here goes:
> 
>  One thing that has recently become a really big deal for UI
> integrity is the failure of external resources to load.  One of the
> primary
> reasons people use external resources is to limit the amount of
> development
> they have to do and/or to reduce their bandwidth needs.  However, when
> an
> external resource fails there is no practical way for them to be
> alerted to
> that fact without creating some pretty hacky JS that is usually
> resource
> specific.  As there could be half a dozen or more external resources on
> a
> modern widget-heavy webpage, that's a lot of dev work today that's not
> very
> portable.  Given that a huge percentage of sites are using external
> resources, I keep thinking it would be really helpful to have a
> fallback
> mechanism when external resources fail to load.  Here are some examples
> of
> what I was thinking:
> 
>  <link rel="stylesheet" type="text/css"
> href="http://remote.host/css.css" alternate="/css/css.css"
> alert="/alert.aspx?error=css_load_failure" >
>  <script type="text/javascript" src="http://remote.host/js.js"
> alternate="/js/js.js"
> alert="/alert.aspx?error=js_load_failure"></script>
>  <img src="http://remote.host/image/img.jpg"
> alternate="/img/img.jpg"
> alert="/alert.aspx?error=image_load_failure">
>  ...
> 
>  The "alternate" tag (or whatever you want to call it) defines the
> local resource that should be loaded if the remote resource fails to
> load.
> That way at least there is some fallback mechanism that is browser
> agnostic,
> and doesn't rely on additional hacky JavaScript.  I also had the idea
> that
> it should allow for an alert mechanism to alert webmasters that third
> party
> content failed to load which could have all kinds of adverse effects on
> the
> page load time, UI integrity and even site functionality, so they can
> take
> action.  Maybe another option would to be to provide a parameter for
> sending
> an alert when it takes more than a certain amount of time to load - so
> webmasters know when the 3rd party is responding too slowly?  For some
> reference please read the recent article
> http://www.troyhunt.com/2012/03/browsing-broken-web-software-

> developer.html
> where sites have all sorts of bizarre failure modes when external
> resources
> are unavailable.  Just because a webserver can reach the 3rd party
> doesn't
> mean the client can, so this could be a nice way to provide a sane and
> ubiquitous failure mode to web developers.
> 
>  Yes, this could leak some information across domains, but that is
> already possible due to onerror event handlers, detecting certain
> attributes
> in CSS and variables in JavaScript, so I don't think this adds much
> additional in the way of security problems, but it's worth thinking
> about
> anyway.  I would appreciate any thoughtful responses.  Thank you!
> 
> Robert Hansen, CISSP
> CEO, Falling Rock Networks
> Cell: (530) 521-2542
> FAX: (512) 628-6299

Received on Tuesday, 20 March 2012 08:36:26 UTC