Re: [whatwg] API to delay the document load event
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 anti-standards. I'd rather unnecessarily standardize a feature that doesn't get broadly used, than propagate some Firefox-only feature that does get broadly used. If it's a feature that will only actually be used in FirefoxOS, then expecting other browser vendors to invest time implementing it wouldn't make sense. If it doesn't get used, why would they need to invest time implementing it? Also, this is a feature where it's trivial for applications to gracefully degrade on browsers that don't have the feature. I'm not sure that's true. I mean, it's *possible* but you have to be careful to never depend on anything that could happen after the natural load event in e.g. your load event handler. I can quite easily see people getting that wrong. In general this seems quite a scary design. The load event is rather intimately tied in to the lifecycle of the document, and encouraging people to arbitrarily delay it feels like a potential source of bugs and confusion. Is getting screenshots of pages for thumbnails really something that needs an author-facing API? In general the concept of fully loaded doesn't make any sense for a class of modern web applications, which might keep loading content or changing their presentation across their liefetime. Therefore it seems like simply taking one screenshot at page load and replacing it with one a little later after a timeout might be a good-enough solution.
Re: [whatwg] API to delay the document load event
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 degrade on browsers that don't have the feature. I'm not sure that's true. I mean, it's *possible* but you have to be careful to never depend on anything that could happen after the natural load event in e.g. your load event handler. I can quite easily see people getting that wrong. I'm not sure what you're getting at here. 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 event. This also seems like the kind of race that you are more likely to win on a local network, so it wouldn't necessarily be caught during development. In general this seems quite a scary design. The load event is rather intimately tied in to the lifecycle of the document, and encouraging people to arbitrarily delay it feels like a potential source of bugs and confusion. Adding new things that delay the load event has not been a source of bugs and confusion in my experience. Authors do it a lot and we've done it in specs too. 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. Is getting screenshots of pages for thumbnails really something that needs an author-facing API? In general the concept of fully loaded doesn't make any sense for a class of modern web applications, which might keep loading content or changing their presentation across their liefetime. Therefore it seems like simply taking one screenshot at page load and replacing it with one a little later after a timeout might be a good-enough solution. The problem is when you next load the application. You don't want to replace a good screenshot with a screenshot of the application saying Loading Then don't replace the screenshot with one taken at the load-event time if you already have one.
Re: [whatwg] API to delay the document load event
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 event. This also seems like the kind of race that you are more likely to win on a local network, so it wouldn't necessarily be caught during development. OK. That's a good argument for defining a new time of document completion instead of modifying the load event. Is getting screenshots of pages for thumbnails really something that needs an author-facing API? In general the concept of fully loaded doesn't make any sense for a class of modern web applications, which might keep loading content or changing their presentation across their liefetime. Therefore it seems like simply taking one screenshot at page load and replacing it with one a little later after a timeout might be a good-enough solution. The problem is when you next load the application. You don't want to replace a good screenshot with a screenshot of the application saying Loading Then don't replace the screenshot with one taken at the load-event time if you already have one. OK, but we want to take a new screenshot eventually, and we want to avoid taking it while the application is saying Loading Avoiding that requires some kind of signal from the application. Rob -- q“qIqfq qyqoquq qlqoqvqeq qtqhqoqsqeq qwqhqoq qlqoqvqeq qyqoquq,q qwqhqaqtq qcqrqeqdqiqtq qiqsq qtqhqaqtq qtqoq qyqoquq?q qEqvqeqnq qsqiqnqnqeqrqsq qlqoqvqeq qtqhqoqsqeq qwqhqoq qlqoqvqeq qtqhqeqmq.q qAqnqdq qiqfq qyqoquq qdqoq qgqoqoqdq qtqoq qtqhqoqsqeq qwqhqoq qaqrqeq qgqoqoqdq qtqoq qyqoquq,q qwqhqaqtq qcqrqeqdqiqtq qiqsq qtqhqaqtq qtqoq qyqoquq?q qEqvqeqnq qsqiqnqnqeqrqsq qdqoq qtqhqaqtq.q
Re: [whatwg] API to delay the document load event
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 load event to be delayed until a corresponding document.stopDelayingLoadEvent() method is called. Allow these to nest so that the document load event is delayed until at least as many calls to stopDelayingLoadEvent() have been made as there were calls to delayLoadEvent(). Is it only me that finds this potentially recursive? If the load event is too early to capture a thumbnail because there might be other tasks waiting for the load event before they contribute to the initial page rendering, then how does delaying the load event help? I think if a page continues its initial rendering after the load event has been fired, then that's the issue, why was the page created that way in the first place? All of my Chrome thumbnails under 'Most Visited' look fine. Also, do these thumbnail capture activities definitely work on the onload event? Can't they be more intelligent? (e.g. wait for DOM/network inactivity or a maximum of 30 seconds). If the page author really wanted control over this, why do they need something complicated like .delayLoadEvent() and .stopDelayingLoadEvent() and not just .captureThumbnail(), or something to put into a meta element more suited to the purpose of capturing/providing thumbnail images. -- Lee
Re: [whatwg] API to delay the document load event
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 composition of independent scripts.
There are certainly more lightweight solutions than Caja to
achieve the same thing.
Which is exactly the problem: you're saying there are multiple
solutions, which means incompatibility.
No, I meant more lightweight solutions than Caja to achieve the same
thing (sorry for the copy/paste, I don't know how to phrase it better),
so solutions that confine a widget in a div giving it the impression
it's on its own full page, so using all standard APIs. A level of
compatibility that's actually hard to match.
I'm currently building a product on top of Google Apps Script [1][2].
The pages served on the client side are cajoled (processed by a
deployed Caja before being sent to the browser) by Google. As a
developer, I'm just coding according to standards. No specific APIs for
the confined code. I haven't seen any difference besides
requestAnimationFrame and the performance object being missing, but
I believe this is only because they (people of Google App Script who
installed and deployed their configured Caja) don't keep up with the
latest browser trends and just forgot to whitelist them.
My point is that Caja offer confinement and the confined code has been
coded to standards, so I consider the problem of confining
standard-based code solved. Really, take a look at it.
Caja proves that confinment of malicious widgets within the same page is
possible (!). I believe a lighter version of Caja aiming at isolating
well-behaving widgets would be much lighter. Hopefully it wouldn't
require the whole server-side live rewriting infrastructure (which is
definitely something that shouldn't be required to run independent
scripts, I can only agree). Maybe assuming widgets give up a little bit
on how dynamic their JavaScript can be (maybe not even).
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.
What about starting with an API à la html@loading and if devs complain
it's too hard when there are independent scripts, then add a mechanism
like delayLoadEvent/stopDelayingLoadEvent? (I still believe delaying the
UA load event is a terrible idea. What will dev tools show? The actual
load event or the delayed one? And the argument about performanceTiming,
etc.). The more complex multi-call API can be later retrofitted, but
please wait for devs to ask for it.
Also, independent scripts loading on a page increase the probably of at
least one failing.
document.delayLoadEvent();
doX(function(){
doY();
document.stopDelayingLoadEvent();
})
First and foremost, let's hope the script that defines doY from your
automated build process didn't end up in a SyntaxError or you'll be told
soon enough that undefined is not a function
Then maybe doY calls JSON.parse to get info from your localStorage or
from the network. Too bad, you're parsing [Object object] because your
colleague wrote
localStorage.set('key', obj)
instead of
localStorage.set('key', JSON.stringify(obj))
doY throws, document.stopDelayingLoadEvent never gets called.
Maybe doY contains a call to JSON.stringify. Few people know but this
one can throw too if passed an object with a cycle. Oops,
document.stopDelayingLoadEvent never gets called.
And hundreds of ECMAScript/Web APIs
Recently, I was working on a WebDocumentary project with lots of
video. All was working fine on FF and Chrome. When testing on iPad,
some calls to video.play were throwing INVALID_STATE_ERR for no apparent
reason. Not even reliably. Maybe something due to loading speed. Maybe
QuickTime was in a bad mood (apparently, on iPad, the video elements
is an embedded QuickTime). Who knows? Anyway, if doY does this kind of
things, it will throw in some platforms and
document.stopDelayingLoadEvent never gets called.
There are thousands of ways a you can screw up or one browser can let
you down and one of your independent widget ends up not calling
document.stopDelayingLoadEvent.
As I explain below, when that happens, you cannot react at runtime.
If your scripts are that independent, how do you know if one
forgets to call document.stopDelayingLoadEvent()? This is a footgun.
The approach I've suggested makes tracking misuse easy; just stash a
stack trace when creating the object, and provide a console API to
print the stack trace for delays that haven't been finished, or if an
object gets collected without being finished.
That's a way to debug, not to react at runtime. If one of your
independent script forgets to call document.stopDelayingLoadEvent(), how
does the page
Re: [whatwg] API to delay the document load event
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. Consider this:
var blockers = [];
function blockOnload() {
var i = document.createElement(iframe);
document.documentElement.appendChild(i);
blockers.push(i.contentDocument);
i.contentDocument.open();
}
function unblockOnload() {
blockers.pop().close();
}
Of course expecting web developers to come up with this themselves and
have to redo all this boilerplate is not reasonable, not to mention the
pollutes-the-DOM and uses-way-too-much-memory aspect of it all.
-Boris
Re: [whatwg] API to delay the document load event
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 over the load event to the extent
being proposed, as far as I can tell. Consider this:
var blockers = [];
function blockOnload() {
var i = document.createElement(**iframe);
document.documentElement.**appendChild(i);
blockers.push(i.**contentDocument);
i.contentDocument.open();
}
function unblockOnload() {
blockers.pop().close();
}
Of course expecting web developers to come up with this themselves and
have to redo all this boilerplate is not reasonable, not to mention the
pollutes-the-DOM and uses-way-too-much-memory aspect of it all.
Possibly relevant: http://bugs.jquery.com/ticket/6781
Rick
-Boris
Re: [whatwg] API to delay the document load event
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: https://groups.google.com/d/msg/google-caja-discuss/tFhYLJ4abL4/1Mq34zXd_z0J https://groups.google.com/d/msg/google-caja-discuss/tFhYLJ4abL4/p0xUcsV99boJ I also read a bit more about the Caja API https://developers.google.com/caja/ and it's all fairly easy to use. As far as I'm concerned, I consider the independent standard-based widget loading problem solved through these solutions. Not just solved in theory. Solved in the sense that any dev can easily deploy them and that perf (both startup+runtime) is not too degraded in modern browsers. If someone believes otherwise, please speak up; otherwise, let's forget about independent widgets when designing platform APIs? David
Re: [whatwg] API to delay the document load event
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 extent
being proposed, as far as I can tell. Consider this:
var blockers = [];
function blockOnload() {
var i = document.createElement(iframe);
document.documentElement.appendChild(i);
blockers.push(i.contentDocument);
i.contentDocument.open();
}
function unblockOnload() {
blockers.pop().close();
}
Of course expecting web developers to come up with this themselves and
have to redo all this boilerplate is not reasonable, not to mention the
pollutes-the-DOM and uses-way-too-much-memory aspect of it all.
Yes, I wasn't clear that I was referring to what is encouraged through
having a documented API, rather than what is possible when one uses the
existing APIs in innovative ways.
[whatwg] Proposal: API to ask the user for a file
Hi, So far the only way to ask a user to select a file (e.g. to upload an attachment in a mail client) without showing the ugly file input UI is to create one of these elements, hide it somehow, and invoke the click method on it and listen for the changed event. This may or may not work depending on the browser and version and there's no way to know this other than doing extensive tests. Ideally this, rather common task, should have an official API instead of this hack. The minimum requirements would be to be able to provide a string for the dialog title, a string for the accepted mime types and a boolean to specify whether multiple files can be selected at once, the return value would be a FileList object [1]. This is essentially the same functionality offered by the existing file input element [2] with the only addition of a title for the dialog. A very simple way to provide this functionality would be to add a method to HTMLDocument like this: FileList openFileDialog(DOMString title, DOMString accept, boolean multiple); On success the method would return the list of selected files or null if the used pressed cancel on the dialog. If the user agent can't show the dialog for some reason the method should throw an exception so the developer has the opportunity to do something in this case. Of course there are other options to provide the same functionality, like creating an object to represent the dialog which would allow for asynchronous processing by using callbacks to notify the selected files. One specific request which comes from the project in which I'm currently working is to allow the use of this API from the callbacks of XMLHttpRequest and WebSocket to make possible to have the UI logic on the server, i.e. when the user clicks on a button a message is sent to the server, the business logic in the server defines the behaviour for the button pressed and sends a notification back to the client about what to do which results in this API being invoked. 1. http://dev.w3.org/2006/webapi/FileAPI/#dfn-filelist 2. http://www.whatwg.org/specs/web-apps/current-work/multipage/states-of-the-type-attribute.html#concept-input-type-file-selected Thank you. -- JC
Re: [whatwg] API to delay the document load event
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 pages, or search results.
- a
On Mon, Apr 29, 2013 at 6: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 over the load event to the extent
being proposed, as far as I can tell. Consider this:
var blockers = [];
function blockOnload() {
var i = document.createElement(**iframe);
document.documentElement.**appendChild(i);
blockers.push(i.**contentDocument);
i.contentDocument.open();
}
function unblockOnload() {
blockers.pop().close();
}
Of course expecting web developers to come up with this themselves and
have to redo all this boilerplate is not reasonable, not to mention the
pollutes-the-DOM and uses-way-too-much-memory aspect of it all.
-Boris
[whatwg] Deferred Javascript parsing
I have been reading about a technique described here ( http://googlecode.blogspot.de/2009/09/gmail-for-mobile-html5-series-reducing.html) for deferring the parsing of scripts until they are actually required. This can be a useful technique for allowing lazy-loading of script without AJAX. A common method used to achieve this (the method described in the linked article) is commenting-out blocks of code and then uncommenting it and running it via eval(), which is obviously not an ideal solution. Has there been any consideration given to an attribute to mark a script tag as do not parse or execute until it's been triggered? I've heard of this technique often enough that it's clear there's an audience for a feature of this nature. ~Benjamin
Re: [whatwg] Proposal: API to ask the user for a file
On Mon, 29 Apr 2013, JC wrote: So far the only way to ask a user to select a file (e.g. to upload an attachment in a mail client) without showing the ugly file input UI is to create one of these elements, hide it somehow, and invoke the click method on it and listen for the changed event. You can also just accept a drag-and-dropped file. Having the input type=file UI hidden is probably not supposed to be possible (though it's hard for us to stop it), because it means you can trick people into clicking the button and bringing up the dialog, which can, if you know what browser/OS they're using, let you in some cases trick them into uploading a particular file. (It's gotten harder with browsers going away from allowing arbitrary text input into that control, though, so this might no longer be that big a deal.) The minimum requirements would be to be able to provide a string for the dialog title, a string for the accepted mime types and a boolean to specify whether multiple files can be selected at once, the return value would be a FileList object [1]. This is essentially the same functionality offered by the existing file input element [2] with the only addition of a title for the dialog. We could maybe do this if browser vendors are comfortable with it... it's definitely something we want to be really careful about, though. For example, we don't want to set up a situation where a site can trigger a download of a sensitive file (e.g. bank account details) and then trick the user into uploading it by asking the user to Select the file you want to protect from uploading or For debugging purposes, select the newest file in this directory, which is a log file we just generated. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Deferred Javascript parsing
Le 29/04/2013 22:21, Benjamin Stürmer a écrit : I have been reading about a technique described here ( http://googlecode.blogspot.de/2009/09/gmail-for-mobile-html5-series-reducing.html) for deferring the parsing of scripts until they are actually required. This can be a useful technique for allowing lazy-loading of script without AJAX. A common method used to achieve this (the method described in the linked article) is commenting-out blocks of code and then uncommenting it and running it via eval(), which is obviously not an ideal solution. Has there been any consideration given to an attribute to mark a script tag as do not parse or execute until it's been triggered? I think if you put any invalid value in the type attribute of the script element, then, the element won't be parsed nor executed. If your script element has a given id, you can easily find the code (document.getElementById(id).textContent) and eval it. David
Re: [whatwg] Proposal: API to ask the user for a file
On Mon, Apr 29, 2013 at 1:41 PM, Ian Hickson i...@hixie.ch wrote: On Mon, 29 Apr 2013, JC wrote: So far the only way to ask a user to select a file (e.g. to upload an attachment in a mail client) without showing the ugly file input UI is to create one of these elements, hide it somehow, and invoke the click method on it and listen for the changed event. You can also just accept a drag-and-dropped file. Having the input type=file UI hidden is probably not supposed to be possible (though it's hard for us to stop it), because it means you can trick people into clicking the button and bringing up the dialog, which can, if you know what browser/OS they're using, let you in some cases trick them into uploading a particular file. (It's gotten harder with browsers going away from allowing arbitrary text input into that control, though, so this might no longer be that big a deal.) I think all modern browsers intentionally let webpages create custom UIs for input type=file by completely hiding the input and then rendering a custom UI using various div and span tags. When the custom UI is clicked the page calls myInputElement.click() in order to bring up the file picker UI. Gecko contains some anti-annoyance protections as to prevent the page from spawning file picker dialogs indefinitely. This is done by hooking up input type=file.click() to popup blocking infrastructure. So the API being requested here is actually available. But in a really ugly way through the HTMLInputElement interface. But I don't really buy the argument that we should supply a new one because the existing API isn't reliably available. If the current API is problematic because there is no way to check if it works, then I'd prefer to add a way to check if it works, rather than adding a whole new API. / Jonas
Re: [whatwg] Deferred Javascript parsing
On 4/29/13, David Bruant bruan...@gmail.com wrote: Le 29/04/2013 22:21, Benjamin Stürmer a écrit : I have been reading about a technique described here ( http://googlecode.blogspot.de/2009/09/gmail-for-mobile-html5-series-reducing.html) for deferring the parsing of scripts until they are actually required. This can be a useful technique for allowing lazy-loading of script without AJAX. A common method used to achieve this (the method described in the linked article) is commenting-out blocks of code and then uncommenting it and running it via eval(), which is obviously not an ideal solution. Obviously not. Nor will it work for external SCRIPT elements (not tags). Has there been any consideration given to an attribute to mark a script tag as do not parse or execute until it's been triggered? David Anderson proposed the 'execute' method. Great idea; no traction. Also http://lists.w3.org/Archives/Public/public-whatwg-archive/2011Feb/0245.html http://lists.w3.org/Archives/Public/public-whatwg-archive/2009Feb/0065.html A shame that the examples aren't up anymore (can't work for free on this). The replies on by Boris and Ian include some mistakes and distract about setTimeout, unfortunately. I think if you put any invalid value in the type attribute of the script element, then, the element won't be parsed nor executed. If your script element has a given id, you can easily find the code (document.getElementById(id).textContent) and eval it. Obviously not an ideal solution. -- Garrett Twitter: @xkit personx.tumblr.com
Re: [whatwg] API to delay the document load event
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
implement something, then it shouldn't be in there. If all you want is the
feature to have a specification, that's different--an API can have a
specification without it being inside the HTML spec, it can still be openly
reviewed here, etc.
(Not to argue one way or the other about whether it would be used or not--I
have only a mild intuition that it wouldn't be--only that the bar should be
cross-browser use.)
On Mon, Apr 29, 2013 at 3:56 AM, James Graham jgra...@opera.com wrote:
I'm not sure that's true. I mean, it's *possible* but you have to be
careful to never depend on anything that could happen after the natural
load event in e.g. your load event handler. I can quite easily see people
getting that wrong.
In general this seems quite a scary design. The load event is rather
intimately tied in to the lifecycle of the document, and encouraging people
to arbitrarily delay it feels like a potential source of bugs and confusion.
We've suggested firing a different event, leaving onload alone, so it's not
nearly so invasive.
On Mon, Apr 29, 2013 at 7:44 AM, David Bruant bruan...@gmail.com wrote:
What about starting with an API à la html@loading and if devs complain
it's too hard when there are independent scripts, then add a mechanism like
delayLoadEvent/stopDelayingLoadEvent? (I still believe delaying the UA load
event is a terrible idea. What will dev tools show? The actual load event
or the delayed one? And the argument about performanceTiming, etc.). The
more complex multi-call API can be later retrofitted, but please wait for
devs to ask for it.
We shouldn't expose one API with the expectation that we might have to add
a second API for the same thing. Then we're permanently stuck with two
separate, overlapping APIs, which is far more complex.
Also, independent scripts loading on a page increase the probably of at
least one failing.
document.delayLoadEvent();
doX(function(){
doY();
document.stopDelayingLoadEvent();
})
var delay = document.delayCompletion();
doX(function(){
try {
doY();
} finally {
delay.finished();
}
});
That's a way to debug, not to react at runtime. If one of your independent
script forgets to call document.stopDelayingLoadEvent(), how does the page
recover to guarantee that the load event will happen eventually anyway?
I'm much more concerned with APIs being debuggable than APIs letting people
hack around bugs. The delayCompletion() approach is the only one that is
trivially debuggable (you can figure out which DelayCompletion object was
never finalized, and where it was created); all of the others leave you
wondering which piece of code is messing about with the document attribute
or who called stopDelayingLoadEvent twice.
As a web developer, I can totally imagine a web browser forgetting to
fire load because of weird internal conditions like one
document.delayLoadEvent call was before DOMContentLoaded and another after.
My proposal isn't to touch onload at all, it's to fire some other
independent event. Its only relationship to onload is that onload is when
onfinishedloading gets run, if no delayCompletion objects are pending at
that time.
How are document.delayLoadEvent and document.stopDelayingLoadEvent any
less global than an attribute on html? That is *exactly* the same amount
of globalness. The risks and consequences of bugs and malicious behavior is
equivalent for both features.
Huh? That wasn't my proposal; I argued specifically against that. Please
see
http://lists.w3.org/Archives/Public/public-whatwg-archive/2013Apr/0111.html,
and look at the sample implementation I gave you earlier:
https://zewt.org/~glenn/finished-loading.html.
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.
Good web APIs don't require the use of wrapper libraries (or script
postprocessing tools--sorry, that's gross) to use in a clean,
self-contained way.
(Sorry for some heavy snipping, but let's slow down discussing what the API
should look like for a bit, so we don't drown out the discussions about use
cases, the need for this feature, where it should live, etc.)
--
Glenn Maynard
Re: [whatwg] API to delay the document load event
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 delaying the load event. This also seems like the kind of race that you are more likely to win on a local network, so it wouldn't necessarily be caught during development. With today's web applications one already has to set up a browser instance and run JavaScript until the DOM stops wobbling just to get the HTML the page displays on load. Every single API that makes it easier to build the DOM in JavaScript can and will be used to do so, and in the process, make life harder for everyone else trying to do something (parsing, screenshooting) with such web pages. The turing complete input language that shall not be named is already turning a document load into a halting problem often enough. I would prefer if developers would fix their web pages to not take ages to load. I fear that whatever band-aid the WG will come up with is going to set wrong incentives – making it easier to not send declarative markup and encourage people to violate the principle of least power. -- Nils Dagsson Moskopp // erlehmann http://dieweltistgarnichtso.net
