W3C home > Mailing lists > Public > whatwg@whatwg.org > April 2013

Re: [whatwg] API to delay the document load event

From: David Bruant <bruant.d@gmail.com>
Date: Mon, 29 Apr 2013 00:10:00 +0200
Message-ID: <517D9E38.3080700@gmail.com>
To: Glenn Maynard <glenn@zewt.org>
Cc: WHATWG <whatwg@whatwg.org>, Robert O'Callahan <robert@ocallahan.org>
Le 28/04/2013 23:08, Glenn Maynard a écrit :
> On Sun, Apr 28, 2013 at 1:00 PM, David Bruant <bruant.d@gmail.com 
> <mailto:bruant.d@gmail.com>> wrote:
>
>     Each widget needs some way to express that it's ready, but doesn't
>     necessarily need to express it to the document directly. A "widget
>     manager" can load the widgets, gather all widgets "ready" events
>     and trigger the UA "AppReady" event when the widgets are ready.
>
>
> You shouldn't have to roll your own API to do this, because then you 
> end up only being able to use code that uses the same solution as 
> everything else (or gives a hook, which is a needless complication).  
> Give everyone a consistent solution to begin with, and you avoid that 
> problem.
Not necessarily. I believe Caja [1] is capable of doing that (see below 
for explanations)

>
>     I don't think we should be promoted patterns where widget are
>     fully independent which is pretty much the equivalent of a script
>     injection (where anything can happen, like one forgetting to call
>     its delay.finished()).
>
>
> I think you're confusing widgets (more generally, code libraries) with 
> sourcing code from untrusted sites.  Obviously nobody should do that, 
> but it has nothing to do with this.
> On Sun, Apr 28, 2013 at 1:21 PM, David Bruant <bruant.d@gmail.com 
> <mailto:bruant.d@gmail.com>> wrote:
>
>     In the Firefox bug, roc suggested [1]:
>     "let the app specify <html loading>, and remove the attribute when
>     done. (...) use a mutation listener to detect its removal."
>     This is delightful; my new favorite idea on the topic. We don't
>     need anything more.
>
>
> As soon as two bits of code try to use this, each unaware of the 
> other, chaos will ensue as they stomp on the attribute set by the 
> other.  This is more or less a global variable.
Two pieces of code each unaware of the other making chaos because of 
accessing the same global state is a form of script injection. Some call 
it the mashup problem. The only way I know to solve this problem is to 
have a what I described as a "widget manager". Caja can be used for that 
[1].
Interestingly, Caja gives each widget the impression it lives on its own 
page (although they actually all cohabit in the same page without 
iframes!), with each its own load event. The "caja manager" (I don't 
know the real name) could gather the widgets delayed loads and delay 
until the latest widget has emitted "load". No need for all widgets to 
work under a custom API, they just use the standard one. This can work 
too if a new "AppReady" event is created, or if an html@loading 
attribute is added (the "caja manager" will listen to this new event or 
attribute removal in all the widgets and emit its own event or remove 
the global attribute when the widgets are done).

Anyway, I believe widgets "each unaware of the other" are a solved 
problem and do not require a dedicated API. I'm not a Caja expert, but 
the team behind it will probably be happy to answer any questions on the 
topic [2].

David

[1] https://developers.google.com/caja/
[2] https://groups.google.com/forum/?fromgroups#!forum/google-caja-discuss
Received on Sunday, 28 April 2013 22:10:29 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:57 UTC