On Mon, May 6, 2013 at 2:17 PM, David Bruant bruan...@gmail.com wrote:
Le 06/05/2013 21:35, James Burke a écrit :
Just going on my experience (admittedly a limited data set): anything
that actually binds to document load really wants to know when all
resources loaded (images/iframes) and page
On Tue, May 7, 2013 at 3:12 PM, Bjoern Hoehrmann derhoe...@gmx.net wrote:
* James Burke wrote:
I just joined the mailing list, so I apologize for not continuing the
existing thread started here:
http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2013-April/039422.html
Disclaimer: I submitted
* James Burke wrote:
I just joined the mailing list, so I apologize for not continuing the
existing thread started here:
http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2013-April/039422.html
Disclaimer: I submitted the Mozilla Bugzilla ticket for some kind of
capability in this area.
I just joined the mailing list, so I apologize for not continuing the
existing thread started here:
http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2013-April/039422.html
Disclaimer: I submitted the Mozilla Bugzilla ticket for some kind of
capability in this area.
Summarizing previous
Le 06/05/2013 21:35, James Burke a écrit :
In my experience as a JS library provider (first with dojo and more
recently with requirejs), JS scripts heavily favor binding to
DOMContentLoaded over document load to do work. DOMContentLoaded is
also what jQuery's ready() uses, which I expect is what
Le 30/04/2013 01:55, Glenn Maynard a écrit :
I want it to be self-contained within the code that's actually
using the feature, not messing about with document-global attributes.
= The self-contained keyword makes me think that you really
want Caja or some lighter version of it.
On Tue, Apr 30, 2013 at 11:55 AM, Glenn Maynard gl...@zewt.org wrote:
On Sun, Apr 28, 2013 at 10:26 PM, Robert O'Callahan
rob...@ocallahan.orgwrote:
If it doesn't get used, why would they need to invest time implementing
it?
Putting a feature in the HTML spec (or related specs) is
On 04/29/2013 05:26 AM, Robert O'Callahan wrote:
On Mon, Apr 29, 2013 at 3:11 PM, Glenn Maynard gl...@zewt.org wrote:
On Sun, Apr 28, 2013 at 9:11 PM, Robert O'Callahan rob...@ocallahan.orgwrote:
It would be easy for us to add some Firefox-only or FirefoxOS-only API
here, but that seems
On 04/29/2013 11:42 AM, Robert O'Callahan wrote:
On Mon, Apr 29, 2013 at 8:56 PM, James Graham jgra...@opera.com
mailto:jgra...@opera.com wrote:
On 04/29/2013 05:26 AM, Robert O'Callahan wrote:
Also, this is a feature where it's trivial for applications to
gracefully
On Mon, Apr 29, 2013 at 10:50 PM, James Graham jgra...@opera.com wrote:
I mean, let's say you delay the load event until after some data has
loaded over a web socket. If you try to use that data from the load event
handler it can fail in a racy way in UAs that don't support delaying the
load
On 24 April 2013 12:51, Robert O'Callahan rob...@ocallahan.org wrote:
Context: https://bugzilla.mozilla.org/show_bug.cgi?id=863499
Proposal:
Give Web applications APIs to explicitly delay the document load event. In
particular, add a method document.delayLoadEvent() that causes the
document
Le 29/04/2013 01:08, Glenn Maynard a écrit :
On Sun, Apr 28, 2013 at 5:39 PM, David Bruant bruan...@gmail.com
mailto:bruan...@gmail.com wrote:
Le 29/04/2013 00:14, Robert O'Callahan a écrit :
We don't want to require people to do everything in Caja just
to support
On 4/29/13 6:50 AM, James Graham wrote:
So far we have kept the model where the load event is auomatically
managed by the UA, rather than giving the developer direct control of it.
Developers already have direct control over the load event to the extent
being proposed, as far as I can tell.
On Mon, Apr 29, 2013 at 9:51 AM, Boris Zbarsky bzbar...@mit.edu wrote:
On 4/29/13 6:50 AM, James Graham wrote:
So far we have kept the model where the load event is auomatically
managed by the UA, rather than giving the developer direct control of it.
Developers already have direct control
Le 29/04/2013 14:44, David Bruant a écrit :
I'm no Caja expert, but this light-Caja might be as simple as picking
a few Caja libraries and wiring them a bit differently. I'll ask the
Caja mailing-list.
Which I did and the answers are very interesting:
On 04/29/2013 03:51 PM, Boris Zbarsky wrote:
On 4/29/13 6:50 AM, James Graham wrote:
So far we have kept the model where the load event is auomatically
managed by the UA, rather than giving the developer direct control of it.
Developers already have direct control over the load event to the
I think that there would be many uses for a mechanism that allows
developers to take part in letting the UA known when it is ready. For
example, we would use then when analyzing extension code server-side.
Another example would be systems that take screenshots of web pages for use
in browser start
On Sun, Apr 28, 2013 at 10:26 PM, Robert O'Callahan
rob...@ocallahan.orgwrote:
If it doesn't get used, why would they need to invest time implementing
it?
Putting a feature in the HTML spec (or related specs) is asking all
browsers to implement it. If we don't expect anyone but Firefox to
James Graham jgra...@opera.com schrieb am Mon, 29 Apr 2013 12:50:34
+0200:
[…]
I mean, let's say you delay the load event until after some data has
loaded over a web socket. If you try to use that data from the load
event handler it can fail in a racy way in UAs that don't support
On Thu, Apr 25, 2013 at 12:57 AM, Glenn Maynard gl...@zewt.org wrote:
This seems a bit heavy-handed. For these use cases, it doesn't seem like
you need to delay the whole onload event, which would have tons of
side-effects on the page. You could just tell the browser that you're
still doing
On Fri, Apr 26, 2013 at 12:23 PM, Tab Atkins Jr. jackalm...@gmail.comwrote:
(Perhaps this means we need something that can take a Future, and
delays the document load until that future resolves? For legacy, it
can take other objects like IDBTransaction, and work analogously.)
It needs to
Le 24/04/2013 13:51, Robert O'Callahan a écrit :
Context: https://bugzilla.mozilla.org/show_bug.cgi?id=863499
Use-cases:
1) User-agents provide thumbnails of Web pages (e.g. desktop Firefox,
FirefoxOS and Safari do this). We want to avoid taking a thumbnail while
the application is incompletely
On Sun, Apr 28, 2013 at 12:28 PM, David Bruant bruan...@gmail.com wrote:
Also, I don't see how nested calls to delayLoadEvent help any of your 2
use cases.
Because multiple pieces of code on the page may need to do this
independently. For example, you may have widgets on the page that need
Le 24/04/2013 15:24, Bjoern Hoehrmann a écrit :
(...) there may be all sorts of things hooked to happen right after
the load event, and you do not want to delay them for some browser
thumbnail feature. If web pages should have the ability to say I
would like to inform you when the right time
Le 28/04/2013 19:47, Glenn Maynard a écrit :
On Sun, Apr 28, 2013 at 12:28 PM, David Bruant bruan...@gmail.com
mailto:bruan...@gmail.com wrote:
Also, I don't see how nested calls to delayLoadEvent help any of
your 2 use cases.
Because multiple pieces of code on the page may need to
Le 24/04/2013 15:24, Bjoern Hoehrmann a écrit :
If web pages should have the ability to say I would like to inform
you when the right time for snapshots has come ... okay, now I'm
ready, then there should be an explicit API for that.
In the Firefox bug, roc suggested [1]:
let the app specify
On Sun, Apr 28, 2013 at 1:00 PM, David Bruant bruan...@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
On Mon, Apr 29, 2013 at 5:47 AM, Glenn Maynard gl...@zewt.org wrote:
I have to wonder whether authors would really use this, though, regardless
of what the API looks like.
We have FirefoxOS app developers who want to use it. This feature request
came from them.
Rob
--
q“qIqfq qyqoquq
Le 28/04/2013 23:08, Glenn Maynard a écrit :
On Sun, Apr 28, 2013 at 1:00 PM, David Bruant bruan...@gmail.com
mailto:bruan...@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
We don't want to require people to do everything in Caja just to support
composition of independent scripts.
AFAICT we generally try to design Web APIs to support composition of
independent scripts whenever that is easy to do. We can do it easily here
using either my or Glenn's proposal.
Rob
--
Le 29/04/2013 00:14, Robert O'Callahan a écrit :
We don't want to require people to do everything in Caja just to
support composition of independent scripts.
There are certainly more lightweight solutions than Caja to achieve the
same thing.
AFAICT we generally try to design Web APIs to
On Sun, Apr 28, 2013 at 5:39 PM, David Bruant bruan...@gmail.com wrote:
Le 29/04/2013 00:14, Robert O'Callahan a écrit :
We don't want to require people to do everything in Caja just to support
composition of independent scripts.
There are certainly more lightweight solutions than Caja to
On Mon, Apr 29, 2013 at 11:08 AM, Glenn Maynard gl...@zewt.org wrote:
On Sun, Apr 28, 2013 at 5:08 PM, Robert O'Callahan
rob...@ocallahan.orgwrote:
On Mon, Apr 29, 2013 at 5:47 AM, Glenn Maynard gl...@zewt.org wrote:
I have to wonder whether authors would really use this, though,
On Sun, Apr 28, 2013 at 9:11 PM, Robert O'Callahan rob...@ocallahan.orgwrote:
I don't think there's anything FirefoxOS-specific about their use case. As
I said in my first email, many browsers implement some kind of thumbnail
capability. I'm not very good at predicting whether or not something
On Mon, Apr 29, 2013 at 3:11 PM, Glenn Maynard gl...@zewt.org wrote:
On Sun, Apr 28, 2013 at 9:11 PM, Robert O'Callahan
rob...@ocallahan.orgwrote:
It would be easy for us to add some Firefox-only or FirefoxOS-only API
here, but that seems anti-standards. I'd rather unnecessarily standardize
* Glenn Maynard wrote:
This seems a bit heavy-handed. For these use cases, it doesn't seem like
you need to delay the whole onload event, which would have tons of
side-effects on the page. You could just tell the browser that you're
still doing things, without it having other script-visible
On Thu, Apr 25, 2013 at 5:15 PM, Bjoern Hoehrmann derhoe...@gmx.net wrote:
* Glenn Maynard wrote:
This seems a bit heavy-handed. For these use cases, it doesn't seem like
you need to delay the whole onload event, which would have tons of
side-effects on the page. You could just tell the browser
Context: https://bugzilla.mozilla.org/show_bug.cgi?id=863499
Use-cases:
1) User-agents provide thumbnails of Web pages (e.g. desktop Firefox,
FirefoxOS and Safari do this). We want to avoid taking a thumbnail while
the application is incompletely loaded. The firing of the document load
event is
On Wed, Apr 24, 2013 at 6:51 AM, Robert O'Callahan rob...@ocallahan.orgwrote:
Proposal:
Give Web applications APIs to explicitly delay the document load event. In
particular, add a method document.delayLoadEvent() that causes the
document load event to be delayed until a corresponding
* Robert O'Callahan wrote:
1) User-agents provide thumbnails of Web pages (e.g. desktop Firefox,
FirefoxOS and Safari do this). We want to avoid taking a thumbnail while
the application is incompletely loaded. The firing of the document load
event is not currently a reliable indicator since the
40 matches
Mail list logo
