headers
Andrew Fedoniouk | 1 Aug 2006 04:32
Favicon

Re: What should document.write() do when called from setTimeout or event handlers?


----- Original Message ----- 
From: "Ian Hickson" <ian@...>
To: <whatwg@...>
Sent: Monday, July 31, 2006 3:34 PM
Subject: [whatwg] What should document.write() do when called from 
setTimeout or event handlers?

>
> I'm trying to spec document.write() and I've run into a difficult edge
> case.
>
> Imagine the server sees this:
>
>   <!DOCTYPE HTML>
>   <html>
>    <head>
>     function test() {
>       document.write('TEST');
>     }
>     setTimeout(test, 1000);
>    </head>
>    <body>
>     <p><img src="test.png" alt="" onload="test()"></p>
>
> ...and then time passes. The image loads, the timeout fires.
>
> Then once the image has loaded and the timer has fired:
>
>    </body>
(Continue reading)

Permalink | Reply | 2 comments |
headers
Ian Hickson | 1 Aug 2006 07:38
Picon

Re: What should document.write() do when called from setTimeout or event handlers?

On Mon, 31 Jul 2006, Andrew Fedoniouk wrote:
> 
> From implementation point of view: all events shall be disabled
> until "original DOM complete" state (</html> parsed and processed).
> Precisely - events shall be postponed (probably some of them may just
> be discarded). First event that shall be fired is window.onload (?)

Unfortunately that would break existing pages, so that's not really an 
option.

> Normaly when document.write appears in the <script> section
> body of the script has been loaded in full so insertion point for the
> write is known - end of the script block.
> document.write in other circumstances (event handlers) shall use
> end of the body element (?) as an append point.

I assume you mean this in addition to the stopping of events you mention 
above. If you don't, then the problem is that document.write() doesn't add 
to the _document_, it adds to the tokeniser's input stream, and the 
tokeniser could be half-way through parsing another token at the time.

--

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Permalink | Reply | 0 comments |
headers
Robert Græsdal | 1 Aug 2006 10:56

Events for added nodes while page is loading

It'd be nice to have an event that'd tell my script when a new dom node  
have been added to the DOM tree /while it is loading/. Some documents just  
take quite a while to load, so it'd be nice to be able to modify nodes as  
they were added to the DOM tree.

I figure we'd need events that fired when the node had been added and  
closed (meaning that all child nodes have been added and we are about to  
start on the sibling). For instance, if you had the code:

<html>
<head><title>Test</title></head>
<body>
<p>This is a paragraph</p>
</body>
</html>

You'd have the events fired as such (+ means an add event, / means a  
"close" event. Ignoring whitespace-only text nodes):
+html
+head
+title
+#Test
/title
/head
+body
+p
+#This is a paragraph
/p
/body
/html
(Continue reading)

Permalink | Reply | 3 comments |
headers
Alexey Feldgendler | 1 Aug 2006 11:13
Picon
Gravatar

Re: Events for added nodes while page is loading

On Tue, 01 Aug 2006 15:56:08 +0700, Robert Græsdal <mail@...> wrote:

> It'd be nice to have an event that'd tell my script when a new dom node
> have been added to the DOM tree /while it is loading/. Some documents just
> take quite a while to load, so it'd be nice to be able to modify nodes as
> they were added to the DOM tree.

Yes, this would help a lot when writing client-side scripts which modify pages as they are loaded, removing
unwanted content such as Flash. Some browsers (Opera) have a mechanism like "User JS" to register a script
which runs before every page starts loading. It can register event listeners, but currently there is no
way for such script to e.g. prevent loading of Flash. It can only remove all Flash objects in
document.onload handler, but by that time some Flash objects might have already started playing.

> If one relied on events not being retroactive (in that they only fire
> after the event has been registered, and you're not told about those
> already added), I am realizing one would probably never get to register
> the root node's creation, and for html, neither would the head's opening
> event. I don't think that'd be a problem, but... comments?

With mechanisms such as "User JS", a script can register so early as to get the event for creation of the root node.

--

-- 
Alexey Feldgendler <alexey@...>
[ICQ: 115226275] http://feldgendler.livejournal.com
Permalink | Reply | 0 comments |
headers
Alexey Feldgendler | 1 Aug 2006 11:31
Picon
Gravatar

Re: What should document.write() do when called from setTimeout or event handlers?

On Tue, 01 Aug 2006 09:32:31 +0700, Andrew Fedoniouk
<news@...> wrote:

> (That is what I never understand : why script is allowed to do anything
> during load time. Script should start executing when DOM is complete,
> when, e.g. getElementById makes real sense.)

Document loading can take a lot of time, especially when external images and objects are used on the page.
The user can start interacting with the partially rendered page before it has completely loaded.

--

-- 
Alexey Feldgendler <alexey@...>
[ICQ: 115226275] http://feldgendler.livejournal.com
Permalink | Reply | 0 comments |
headers
Alexey Feldgendler | 1 Aug 2006 11:32
Picon
Gravatar

Re: What should document.write() do when called from setTimeout or event handlers?

On Tue, 01 Aug 2006 05:34:55 +0700, Ian Hickson <ian@...> wrote:

> IE seems to make those calls to document.write() simply blow away the
> document, as if the document was closed. Opera seems to do the same.

I think this is the best thing to do. Easy to implement and well-defined.

--

-- 
Alexey Feldgendler <alexey@...>
[ICQ: 115226275] http://feldgendler.livejournal.com
Permalink | Reply | 4 comments |
headers
Stewart Brodie | 1 Aug 2006 12:15

Re: Events for added nodes while page is loading

Robert Græsdal <mail@...> wrote:

> It'd be nice to have an event that'd tell my script when a new dom node  
> have been added to the DOM tree /while it is loading/. Some documents just

> take quite a while to load, so it'd be nice to be able to modify nodes as 

> they were added to the DOM tree.
> 
> I figure we'd need events that fired when the node had been added and  
> closed (meaning that all child nodes have been added and we are about to  
> start on the sibling).

Well DOMNodeInserted(IntoDocument) almost (see below) fits the bill for the
first one.  The latter one is much trickier.  Like you, I also discovered I
needed to know about close tags marking that the parser had finished dealing
with the child nodes in order to handle things that cannot start until their
content is fully parsed, like launching plugins for OBJECT tags (you can't
actually start it up until you've seen all the PARAM elements).  My tree
builder issues a custom event for this when it considers a node's content
complete.  Obviously, I'm looking at this from the browser implementation
point of view, rather than the page author's script's point of view, but
both want the same information.

However, there is still an additional complication of how to handle somebody
using the DOM Node interface to attach entire subtrees - in this case, you
just need to know that the object's content is already complete (because the
child nodes will already be there, you just won't have seen the events yet).
My solution for this was to have an additional property on the
DOMNodeInserted(IntoDocument) events indicating that the tree builder was
(Continue reading)

Permalink | Reply | 0 comments |
headers
Stewart Brodie | 1 Aug 2006 15:37

Re: What should document.write() do when called from setTimeout or event handlers?

Ian Hickson <ian@...> wrote:

> 
> I'm trying to spec document.write() and I've run into a difficult edge 
> case.
> 
> Imagine the server sees this:
> 
>    <!DOCTYPE HTML>
>    <html>
>     <head>
>      function test() {
>        document.write('TEST');
>      }
>      setTimeout(test, 1000);
>     </head>
>     <body>
>      <p><img src="test.png" alt="" onload="test()"></p>
> 
> ...and then time passes. The image loads, the timeout fires.
> 
> Then once the image has loaded and the timer has fired:
> 
>     </body>
>    </html>
> 
> ...and the connection is closed.
> 
> What should happen?
(Continue reading)

Permalink | Reply | 2 comments |
headers
Alexey Feldgendler | 1 Aug 2006 16:32
Picon
Gravatar

Re: What should document.write() do when called from setTimeout or event handlers?

On Tue, 01 Aug 2006 20:37:17 +0700, Stewart Brodie  
<stewart.brodie@...> wrote:

>> Mozilla seems to make the document.write() calls insert text into the
>> parser, as if they'd been called inline, with the result that the  
>> inserted text could appear pretty much anywhere. (It's actually a bit  
>> more
>> complex than that -- it avoids inserting into tokens -- but that's a  
>> detail.)

Mozilla tokenizes text in blocks as it arrives from the network socket.  
document.write() in the described situation seems to insert the text after  
the already tokenized portion. This means that the observed behavior will  
depend on the network conditions.

> I think we can do without Heisenberg-like effects from Mozilla :-)

Indeed. :-)

--

-- 
Alexey Feldgendler <alexey@...>
[ICQ: 115226275] http://feldgendler.livejournal.com
Permalink | Reply | 0 comments |
headers
Sven Drieling | 2 Aug 2006 15:25
Picon

[canvas] Multiple closePath() after beginPath()?

Hello,

is it allowed to use multiple closePath() calls after beginPath()? This
works with Opera 9.00 to draw two triangles but the paired method names
beginPath() and closePath() makes the impression that only
one closePath() could follow one beginPath() call. Maybe a closeSubpath()
method?

ctx.beginPath();

ctx.moveTo( 60,  50);
ctx.lineTo(110,  110);
ctx.lineTo( 10,  110);
ctx.closePath();

ctx.moveTo(180,  50);
ctx.lineTo(230, 110);
ctx.lineTo(130, 110);
ctx.closePath();

ctx.stroke();

 
tschuess
      [|8:)
Permalink | Reply | 1 comment |

Gmane