- From: Jim Ley <jim@jibbering.com>
- Date: Sat, 29 Jul 2006 17:19:12 +0100
- To: www-html@w3.org
"Mark Birbeck" <mark.birbeck@x-port.net> wrote in message news:640dd5060607290834h63e1806ctc020b63f840be87a@mail.gmail.com... >The second is that we actually process the script >at the same time as loading the document in the XML processor. Let's widen the situation away from XHTML - to include XML Events, XML Events are a generic process, this means that an XML processor that wanted to use it would need to support them, these break the idea that what arrives onload is the same as arrives before unload, there's no seperation from XHTML/XML here. I'd also be concerned by your suggestion that an XHTML DOM need not exist until after a document has fired its onload - when we know than an XML DOM needs to be - the idea that an interface changes post load is worrying, and not something very implementable. >Given this 'architecture' or 'processing model', it means that any >executions of inline document.write() calls will take place after the >entire document has been loaded, and so will not be modifying the >*initial* document. This interpretation though knocks out an awful lot more than just document.write - it also knocks out the majority of user agents - including all the XHTML ones I had to hand - you've got my test case. Whilst the test case I posted does rely on one thing which is not currently standard, it is being standardised by the Web API working group, I hope you will raise this issue there if you feel the issue is relevant. (I would rely much more on document.write not working because the spec says it only works after a document.open rather than trying to argue the theory of XML models, which whilst I can see the argument, it has to many implications beyond document.write which are required on the web. >This means that the same document will *always* be >loaded into *any* XHTML viewer, and it is only once loaded that script >elements could be processed and make a difference. There is therefore >no need to support <noscript>, since during the initial loading >process there are no 'alternative routes'. As we can see from the previous testcase - or from any XML document using XML events, the above is not sustainable. Jim.
Received on Saturday, 29 July 2006 16:19:33 UTC