- From: <bugzilla@jessica.w3.org>
- Date: Fri, 22 Feb 2013 10:32:09 +0000
- To: public-html-bugzilla@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=21074 --- Comment #8 from Lee Kowalkowski <lee.kowalkowski@googlemail.com> --- (In reply to comment #7) > Onload is also used as a proxy to determine when a page is ready from a > statistics gathering perspective. If gathering statistics isn't critical to the user, then using the onload event might be OK. If gathering statistics for a page hit where the user didn't wait for onload is desirable, then don't wait for the onload event to gather the statistics. Perhaps the fact that the user didn't wait for onload is a useful metric itself, perhaps the only useful statistic that can be gathered using the onload event, is the page load time. > There are also users who won't start > interacting with a page until the spinner stops spinning, which happens on > onload. I can't find any supporting evidence of the severity of this user phenomenon, no doubt there are some users with that habit, it's not an observation I've made very often, new users tend not to understand the spinner. I know that young children don't do this, as soon as what they want is visible, they will try to use it. I do remember it being necessary to wait until the page has finished loading when using some specific badly-implemented sites though (i.e. pages that don't even work properly if you interact with them too soon). Perhaps such users are doing this from such experience, applying the behaviour as a rule to use all sites by, kind of like superstition. For sure, the onload event is being used inappropriately on such sites. Perhaps what we need in the HTML5 reference is a warning on the onload event that it is probably not as useful as the author might expect, given inherent uncertainty with networks. > Regarding DOMContentLoaded, it still doesn't guarantee that scripts loaded > with the async attribute have finished downloading and executing, so you > cannot depend on any of the functionality they provide. You should probably not use the async attribute for functionality the user will depend on though, and you should probably not have inter-script dependencies loading asynchronously without building a mechanism to allow the dependency to be late (e.g. polling). The async attribute is best suited for non-critical scripts (e.g. scripts that will progressively enhance something that is already functional). -- You are receiving this mail because: You are the QA Contact for the bug.
Received on Friday, 22 February 2013 10:32:11 UTC