- From: Ian Hickson <ian@hixie.ch>
- Date: Fri, 1 Jun 2007 22:01:15 +0000 (UTC)
- To: David Woolley <david@djwhome.demon.co.uk>
- Cc: www-html@w3.org
On Thu, 3 Aug 2006, David Woolley wrote: > > I think it is a reasonable expectation to be able to interact as soon as > an element appears. > > However, I would note that typical commercial designs actually frustrate > the appearence of the user interface elements by: > > a) having the start of the download filled up by a large scripting > library; The spec has async="" and defer="" attributes on <script> to help with this now. > b) using auto layout tables whose size depends on images, so that the > browser doesn't have enough information to render the page until it has > nearly all arrived (I think some browsers do a fix up, rather than > delaying), This is a CSS issue. > I'm also aware of cases where people have deliberately delayed the > enabling of HCI elements until all the scripting, etc. has loaded, > because it makes things more predictable that way. Certainly it is easier to write code when you don't have to worry about the case where half the code is missing. > When I've though about this in the past, I've concluded that the current > specifications are inadequate when there are multiple download streams. > E.g., if, as ought to be good practice, the scripting library is in a > .js file, does anything specify what happens if a function is called > before the parallel load of the scripting file completes (and the > declaration hasn't yet been seen)? The specs define this (you get an exception), but it isn't exactly clear to me what we can do to make this better in a way that authors would actually leverage. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Friday, 1 June 2007 22:01:39 UTC