Re: Beacon API
On 02/20/2013 08:24 AM, Reitbauer, Alois wrote: My personal experience is different. We found that using img tags is not that reliable. Especially in Firefox we recently saw some problems. Img tags in general have the disadvantage that the amount of data that can be set is rather limited. While this obviously should be kept as small as possible, the information available via resource timing will increase the amount of data that gets sent. Is there a way we can integrate this into a W3C test suite to check how different browsers behave in this case Yes, tests for behaviour around navigation and unload should go in the HTML testsuite[1]. There are some guidelines for writing tests at [2], but they appear in need of an update to reflect the fact that we now use git[hub] rather than mercurial. If you have any questions, please ask, either on the public-html-testsuite list, or in the #whatwg channel on Freenode or on the #testing channel on the W3C IRC server. [1] https://github.com/w3c/html-testsuite/ [2] http://www.w3.org/html/wg/wiki/Testing/Authoring/
Re: [webcomponents]: Building HTML elements with custom elements
On Wed, Feb 20, 2013 at 3:01 AM, Scott Miles wrote:
> Perhaps one other COST of the localName issue is the question of
> document.createElement.
>
> document.createElement('x-button') creates , people
> complain because the tag names do not match.
> document.createElement('button').setAttribute('is', 'x-button'), doesn't
> work this way, "is" is not a standard attribute (according to me)
> document.createElement('button', 'x-button'), now I cannot encode my tag in
> a single variable (i.e. document.createElement(someTag))
> document.createElement('button/x-button'), I just made this up, but maybe it
> would work.
I think ideally we do none of these and just advocate using a
constructor. The setAttribute() variant can never work. The others
could work, but I don't see the point of enhancing an API we don't
envision using in the long run.)
--
http://annevankesteren.nl/
Re: [webcomponents]: Building HTML elements with custom elements
On Tue, Feb 19, 2013 at 11:52 PM, Dimitri Glazkov wrote: > 3) Since the elements could derive from other existing elements, the > localName should not be used for determining custom element's type > (https://www.w3.org/Bugs/Public/show_bug.cgi?id=20913) > > PROBLEM: The localName checks are everywhere, from C++ code to > extensions, to author code, and a lot of things will break if a custom > element that is, for example, an HTMLButtonElement does not have > localName of "button". Addressing this issue head on seems > intractable. These already cannot be just localName checks as that would mean an element named button in some vague namespace would run through the same code. I also fail to see exactly what the problem is here, an example would help. -- http://annevankesteren.nl/
Re: [editing] defaultParagraphSeparator
Sorry for the delayed response -- I've been busy with other things and
didn't have time to check my e-mail. Thanks a lot for the feedback
and questions!
On Mon, Feb 4, 2013 at 9:59 PM, Alex Mogilevsky wrote:
> There was a discussion here a while ago on desired default behavior for
> Enter in contenteditable and options for
> execCommand(“defaultParagraphSeparator”):
>
> http://lists.w3.org/Archives/Public/public-whatwg-archive/2011May/thread.html#msg171
>
> Did it ever get to consensus? Or is there new thinking on how that should
> work?
I don't remember if there was consensus. I wound up speccing
something based on IE/Opera's behavior ( by default).
Unfortunately, the complexity of editing and the level of detail I
write the spec in means that everyone other than me seems to have a
hard time understanding most of the spec (and so do I a lot of the
time . . .), but I can answer any questions people have about what I
thought was best and why.
On Tue, Feb 5, 2013 at 2:41 AM, Alex Mogilevsky wrote:
> * default styles (if 'p' is default, it adds default 1em margin before first
> line, which most people consider undesirable)
I initially thought this was a significant issue, but then I realized
the same issue exists anyway for lists and indent, and you can't get
around it for them. You have to have at least some CSS if you want it
to look nice -- particularly for indent, where the top/bottom margin
is rarely desirable (since it hijacks for indentation).
Also, the default margins for match recent versions of Word, IIRC.
Simon Pieters did point out that for e-mail, you can't add styles, so
this is a reason to support as well. But I do think that is
a better default. If IE and Opera would be willing to change to
and WebKit is not willing to match IE/Opera, I'd be in favor of
changing the default to for interop's sake. Otherwise I think
it should stay .
> * when should Enter insert a line break instead of block (e.g. when inside
> )?
This is specified in the "insertParagraph" command, which behaves the
same as hitting Enter:
https://dvcs.w3.org/hg/editing/raw-file/tip/editing.html#the-insertparagraph-command
The actual spec text might prove just a tad difficult to read, but the
note at the top explains some of the important parts. The spec
currently says a should be inserted instead of a new block
element for , , and . My notes ("View
comments" at the side in the normative text) explain the reasoning for
this exact list:
"""
IE9 and Chrome 13 dev just break up into multiple s.
Firefox 5.0a2 and Opera 11.10 insert a instead, treating it
differently from . The latter makes more sense. What might make the
most sense is to just insert an actual newline character, though,
since this is a pre after all . . .
IE9 and Chrome 13 dev also break up into multiple
es. Firefox 5.0a2 inserts instead. Opera 11.10 nests
s inside. I don't like Opera's behavior, because it means we nest
formatBlock candidates inside one another, so I'll go with Firefox.
listing and xmp work the same as pre in all browsers. For Firefox and
Opera, this results in trying to put a br inside an xmp, so I go with
IE/Chrome for xmp.
TODO: In cases where hitting enter in a header doesn't break out of
the header, we should probably follow this code path too, instead of
creating an adjoining header. No browser does this, though, so we
don't.
"""
For other elements, of course, you can use Shift-Enter (or platform
equivalent) to produce a instead, e.g., to produce a multi-line
list item.
> * can/should the default block be set per editable area and how?
This is bug 15522:
https://www.w3.org/Bugs/Public/show_bug.cgi?id=15522 I really wanted
this to be per-editing host only, with no document-wide flag, because
in my experience document-wide flags mean authors have to write
wrappers like
function myCommand(a, b, c) {
document.execCommand("usecss", false, true);
document.execCommand(a, b, c);
}
just in case something else sneakily changed the flag when they
weren't looking. But I decided not to block one on the other, so
currently the spec has no way to do it per-editing host.
> * why only 'p' and 'div'?
Because no implementation supports any other wrapper for the default
paragraph separator, and there's no obvious reason why it would be
useful. If people really wanted to allow as a default
line separator, we could add it to the spec easily enough.
(I considered adding as an option, like Firefox now, but it would
require an extra code path, which I don't think is worth it unless we
really have a good reason.)
Re: [webcomponents]: Building HTML elements with custom elements
On 2/20/13 7:26 AM, Anne van Kesteren wrote:
These already cannot be just localName checks
They often are in practice for extensions and web script.
For browser code or better-written extensions and web script they're
typically localName + namespaceURI checks.
I also fail to see exactly what the problem is here, an
example would help.
Here's a simple example.
Say you have a browser extension that hooks into the context menu code
and adds items to context menus for images that do something the user
wants. How does it detect images? Given that instanceof tends to be a
broken puppy when multiple globals are involved (though we're working on
finally getting that fixed), it would typically do things like (for a
well-written extension):
if ((isHTML(element) &&
(element.localName == "img" ||
(element.localName == "input" &&
element.type == "image"))) ||
(isSVG(element) && element.localName == "img")) {
// Add my context menu items
}
(maybe with some extra complexity for ).
Now if you create a custom element inheriting from HTMLImageElement but
not using "img" as the localName suddenly the extension won't show its
context menu items on that image and the user will be unhappy because
they can't do things with that image that they can do with all other images.
-Boris
Re: [editing] Is this the right list to discuss editing?
On Tue, Feb 19, 2013 at 11:26 AM, Ms2ger wrote: > FWIW, Aryeh is currently studying full time and doesn't follow web standards > discussions regularly. I do check them from time to time, though, and will check any personal e-mail I receive for the time being. In particular, I'm happy to answer any questions in public or private about the spec, particularly to help a new editor get the hang of it. It's giant and complicated and very hard to read -- which I suspect is an accurate description of implementations' source code as well! (At least I've heard terrible things about WebKit's implementation, and Gecko's I've seen. As specs get more precise, their complexity eventually matches that of implementations . . .)
Re: Custom elements ES6/ES5 syntax compromise, was: document.register and ES6
It seems that there's some additional reasoning that needs to go into
whether an element could be constructed as custom tag. Like in this
case, it should work both as a custom tag and as a type extension (the
"is" attr).
:DG<
On Tue, Feb 19, 2013 at 10:13 PM, Daniel Buchner wrote:
> Nope, you're 100% right, I saw header and thought HTMLHeadingElement for
> some reason - so this seems like a valid concern. What are the
> mitigation/solution options we can present to developers for this case?
>
>
> Daniel J. Buchner
> Product Manager, Developer Ecosystem
> Mozilla Corporation
>
>
> On Tue, Feb 19, 2013 at 9:17 PM, Scott Miles wrote:
>>
>> Perhaps I'm making a mistake, but there is no specific prototype for the
>> native header element. 'header', 'footer', 'section', e.g., are all
>> HTMLElement, so all I can do is
>>
>> FancyHeaderPrototype = Object.create(HTMLElement.prototype);
>>
>> Afaict, the 'headerness' cannot be expressed this way.
>>
>>
>> On Tue, Feb 19, 2013 at 8:34 PM, Daniel Buchner
>> wrote:
>>>
>>> Wait a sec, perhaps I've missed something, but in your example you never
>>> extend the actual native header element, was that on purpose? I was under
>>> the impression you still needed to inherit from it in the prototype
>>> creation/registration phase, is that not true?
>>>
>>> On Feb 19, 2013 8:26 PM, "Scott Miles" wrote:
Question: if I do
FancyHeaderPrototype = Object.create(HTMLElement.prototype);
document.register('fancy-header', {
prototype: FancyHeaderPrototype
...
In this case, I intend to extend "header". I expect my custom elements
to look like , but how does the system know what
localName to use? I believe the notion was that the localName would be
inferred from the prototype, but there are various semantic tags that share
prototypes, so it seems ambiguous in these cases.
S
Re: Custom elements ES6/ES5 syntax compromise, was: document.register and ES6
Since many of these cases are 'semantic' elements, whose only raison d'être
(afaik) is having a particular localName, I'm not sure how we get around
this without being able to specify an 'extends' option.
document.register('fancy-header', {
prototype: FancyHeaderPrototype,
extends: 'header'
...
On Wed, Feb 20, 2013 at 9:54 AM, Dimitri Glazkov wrote:
> It seems that there's some additional reasoning that needs to go into
> whether an element could be constructed as custom tag. Like in this
> case, it should work both as a custom tag and as a type extension (the
> "is" attr).
>
> :DG<
>
> On Tue, Feb 19, 2013 at 10:13 PM, Daniel Buchner
> wrote:
> > Nope, you're 100% right, I saw header and thought HTMLHeadingElement for
> > some reason - so this seems like a valid concern. What are the
> > mitigation/solution options we can present to developers for this case?
> >
> >
> > Daniel J. Buchner
> > Product Manager, Developer Ecosystem
> > Mozilla Corporation
> >
> >
> > On Tue, Feb 19, 2013 at 9:17 PM, Scott Miles wrote:
> >>
> >> Perhaps I'm making a mistake, but there is no specific prototype for the
> >> native header element. 'header', 'footer', 'section', e.g., are all
> >> HTMLElement, so all I can do is
> >>
> >> FancyHeaderPrototype = Object.create(HTMLElement.prototype);
> >>
> >> Afaict, the 'headerness' cannot be expressed this way.
> >>
> >>
> >> On Tue, Feb 19, 2013 at 8:34 PM, Daniel Buchner
> >> wrote:
> >>>
> >>> Wait a sec, perhaps I've missed something, but in your example you
> never
> >>> extend the actual native header element, was that on purpose? I was
> under
> >>> the impression you still needed to inherit from it in the prototype
> >>> creation/registration phase, is that not true?
> >>>
> >>> On Feb 19, 2013 8:26 PM, "Scott Miles" wrote:
>
> Question: if I do
>
> FancyHeaderPrototype = Object.create(HTMLElement.prototype);
> document.register('fancy-header', {
> prototype: FancyHeaderPrototype
> ...
>
> In this case, I intend to extend "header". I expect my custom elements
> to look like , but how does the system know
> what
> localName to use? I believe the notion was that the localName would be
> inferred from the prototype, but there are various semantic tags that
> share
> prototypes, so it seems ambiguous in these cases.
>
> S
>
Re: Custom elements ES6/ES5 syntax compromise, was: document.register and ES6
On Wed, Feb 20, 2013 at 9:58 AM, Scott Miles wrote:
> Since many of these cases are 'semantic' elements, whose only raison d'être
> (afaik) is having a particular localName, I'm not sure how we get around
> this without being able to specify an 'extends' option.
>
> document.register('fancy-header', {
> prototype: FancyHeaderPrototype,
> extends: 'header'
> ...
Can you help me understand why we need to do this? Since there is no
HTMLHeaderPrototype, we will never have an issue with forming the
wrong prototype chain. So should work just
as well as , and so would .
:DG<
Re: Custom elements ES6/ES5 syntax compromise, was: document.register and ES6
[I messed up and failed to reply-all a few messages back, see the quoted
text to pick up context]
>> semantic is only important in markup
Hrm, ok. I'll have to think about that.
At any rate, I'm concerned that developers will not be able to predict what
kind of node they will get from a constructor. We had a rule that you get
one kind of node for 'custom' elements and another for extensions of known
elements. But now it's more complicated.
Scott
On Wed, Feb 20, 2013 at 10:39 AM, Dimitri Glazkov wrote:
> On Wed, Feb 20, 2013 at 10:34 AM, Scott Miles wrote:
> > var FancyHeader = document.register('fancy-header', {prototype:
> > FancyHeaderPrototype});
> > document.appendChild(new FancyHeader());
> >
> > what I expect in my document:
> >
> >
> >
>
> But semantic is only important in markup? If you're building this
> imperatively, there's really no semantics anymore. You're in a DOM
> tree.
>
> Now, a valid question would be: what if I wanted to serialize this DOM
> tree in a certain way? I don't have an answer to that.
>
> :DG<
>
Re: exposing CANVAS or something like it to Web Workers
On Fri, Feb 8, 2013 at 9:14 AM, Travis Leithead wrote: >>> What would be the advantage? If you wanted to keep dom elements in sync >>> with the canvas you'd still have to post something from the worker back to >>> the main thread so the main thread would know to pop. > > > > Well, it's not a fleshed out proposal by any stretch, but you could imagine > that an event could be used to signal that new frames were ready from the > producer—then the main thread would know to pop. It sounds like this approach would require a bunch of new concepts -- a remote worker context, events signalled through it, etc. It would still be necessary to postMessage from the main thread back to the worker for flow control. Flow control is definitely necessary -- the producer can't just produce frames without any feedback about when they're actually consumed. We've had problems in Chrome's graphics pipeline in the past where lack of flow control led to slow and inconsistent frame rates. I'm excited about Gregg's proposal because it solves a lot of use cases that aren't currently addressed by CanvasProxy, using a couple of simple primitives that build upon others already in the platform (cross-document messaging and Transferables). How can we move forward so that user agents can experimentally implement these APIs? Ideally we'd prototype and experiment with them in some medium-sized applications before finalizing any specs in this area. Thanks, -Ken > From: Gregg Tavares [mailto:g...@google.com] > Sent: Friday, February 8, 2013 3:14 AM > To: Travis Leithead > Cc: Ian Hickson; Charles Pritchard; Web Applications Working Group WG > > > Subject: Re: exposing CANVAS or something like it to Web Workers > > > > > > > > On Thu, Feb 7, 2013 at 10:46 PM, Travis Leithead > wrote: > > Having thought about this before, I wonder why we don’t use a > producer/consumer model rather than a transfer of canvas ownership model? > > > > A completely orthogonal idea (just my rough 2c after reading Gregg’s > proposal), is to have an internal frame buffer accessible via a WorkerCanvas > API which supports some set of canvas 2d/3d APIs as appropriate, and can > “push” a completed frame onto a stack in the internal frame buffer. Thus the > worker can produce frames as fast as desired. > > > > On the document side, canvas gets a 3rd kind of context—a > WorkerRemoteContext, which just offers the “pop” API to pop a frame from the > internal frame buffer into the canvas. > > > > Then you just add some basic signaling events on both ends of the frame > buffer and you’re good (as far as synchronizing the worker with the > document). The producer (in the worker) is free to produce multiple frames > in advance (if desired), while the consumer is able to pop frames when > available. You could even have the framebuffer depth configurable. > > > > What would be the advantage? If you wanted to keep dom elements in sync with > the canvas you'd still have to post something from the worker back to the > main thread so the main thread would know to pop. > > > > > > > > From: Gregg Tavares [mailto:g...@google.com] > Sent: Thursday, February 7, 2013 2:25 PM > To: Ian Hickson > Cc: Charles Pritchard; Web Applications Working Group WG > Subject: Re: exposing CANVAS or something like it to Web Workers > > > > I put up a new proposal for canvas in workers > > > > http://wiki.whatwg.org/wiki/CanvasInWorkers > > > > Please take a look. > > > > This proposal comes from offline discussions with representatives from the > various browsers as well as input from the Google Maps team. I can post a > summary here if you'd like but it might be easier to read the wiki > > > > Looking forward to feedback. > > > > > > > > On Tue, Jan 8, 2013 at 10:50 AM, Ian Hickson wrote: > > On Wed, 2 Jan 2013, Gregg Tavares (社ç~T¨) wrote: >> >> Another issue as come up and that is one of being able >> to synchronize updates of a canvas in >> worker with changes in the main page. > > For 2D, the intended solution is to just ship the ImageBitamp from the > worker canvas to the main thread via a MessagePort and then render it on > the canvas at the appropriate time. > > I don't know how you would do it for WebGL. > > > >> Similarly, let's say you have 2 canvases and are rendering to both in a >> worker. Does >> >>context1.commit(); >>context2.commit(); >> >> guarantee you'll see both commits together? > > No, unfortunately not. There's no synchronisation between workers and the > main thread (by design, to prevent any possibility of deadlocks), and > there's not currently a batching API. > > However, if this becomes a common problem (which we can determine by > seeing if we get bugs complaining about different parts of apps/games > seeming to slide around or generally be slightly out of sync, or if we see > a lot of authors shunting multiple ImageBitmap objects across MessagePort > channels) we can always add an explicit batching API to make this kind of > thing easy. > > Note that in the
Re: exposing CANVAS or something like it to Web Workers
Chrome extensions have a background.html capability with a full dom; I've used those to prototype the concept. I've also used webkit's CSS fill (-webkit-canvas) in the mix. A good deal of experimentation can be done there, prior to hacking up C++. On Feb 20, 2013, at 11:43 AM, Kenneth Russell wrote: > On Fri, Feb 8, 2013 at 9:14 AM, Travis Leithead > wrote: What would be the advantage? If you wanted to keep dom elements in sync with the canvas you'd still have to post something from the worker back to the main thread so the main thread would know to pop. >> >> >> >> Well, it's not a fleshed out proposal by any stretch, but you could imagine >> that an event could be used to signal that new frames were ready from the >> producer—then the main thread would know to pop. > > It sounds like this approach would require a bunch of new concepts -- > a remote worker context, events signalled through it, etc. It would > still be necessary to postMessage from the main thread back to the > worker for flow control. Flow control is definitely necessary -- the > producer can't just produce frames without any feedback about when > they're actually consumed. We've had problems in Chrome's graphics > pipeline in the past where lack of flow control led to slow and > inconsistent frame rates. > > I'm excited about Gregg's proposal because it solves a lot of use > cases that aren't currently addressed by CanvasProxy, using a couple > of simple primitives that build upon others already in the platform > (cross-document messaging and Transferables). > > How can we move forward so that user agents can experimentally > implement these APIs? Ideally we'd prototype and experiment with them > in some medium-sized applications before finalizing any specs in this > area. > > Thanks, > > -Ken > > >> From: Gregg Tavares [mailto:g...@google.com] >> Sent: Friday, February 8, 2013 3:14 AM >> To: Travis Leithead >> Cc: Ian Hickson; Charles Pritchard; Web Applications Working Group WG >> >> >> Subject: Re: exposing CANVAS or something like it to Web Workers >> >> >> >> >> >> >> >> On Thu, Feb 7, 2013 at 10:46 PM, Travis Leithead >> wrote: >> >> Having thought about this before, I wonder why we don’t use a >> producer/consumer model rather than a transfer of canvas ownership model? >> >> >> >> A completely orthogonal idea (just my rough 2c after reading Gregg’s >> proposal), is to have an internal frame buffer accessible via a WorkerCanvas >> API which supports some set of canvas 2d/3d APIs as appropriate, and can >> “push” a completed frame onto a stack in the internal frame buffer. Thus the >> worker can produce frames as fast as desired. >> >> >> >> On the document side, canvas gets a 3rd kind of context—a >> WorkerRemoteContext, which just offers the “pop” API to pop a frame from the >> internal frame buffer into the canvas. >> >> >> >> Then you just add some basic signaling events on both ends of the frame >> buffer and you’re good (as far as synchronizing the worker with the >> document). The producer (in the worker) is free to produce multiple frames >> in advance (if desired), while the consumer is able to pop frames when >> available. You could even have the framebuffer depth configurable. >> >> >> >> What would be the advantage? If you wanted to keep dom elements in sync with >> the canvas you'd still have to post something from the worker back to the >> main thread so the main thread would know to pop. >> >> >> >> >> >> >> >> From: Gregg Tavares [mailto:g...@google.com] >> Sent: Thursday, February 7, 2013 2:25 PM >> To: Ian Hickson >> Cc: Charles Pritchard; Web Applications Working Group WG >> Subject: Re: exposing CANVAS or something like it to Web Workers >> >> >> >> I put up a new proposal for canvas in workers >> >> >> >> http://wiki.whatwg.org/wiki/CanvasInWorkers >> >> >> >> Please take a look. >> >> >> >> This proposal comes from offline discussions with representatives from the >> various browsers as well as input from the Google Maps team. I can post a >> summary here if you'd like but it might be easier to read the wiki >> >> >> >> Looking forward to feedback. >> >> >> >> >> >> >> >> On Tue, Jan 8, 2013 at 10:50 AM, Ian Hickson wrote: >> >> On Wed, 2 Jan 2013, Gregg Tavares (社ç~T¨) wrote: >>> >>> Another issue as come up and that is one of being able >>> to synchronize updates of a canvas in >>> worker with changes in the main page. >> >> For 2D, the intended solution is to just ship the ImageBitamp from the >> worker canvas to the main thread via a MessagePort and then render it on >> the canvas at the appropriate time. >> >> I don't know how you would do it for WebGL. >> >> >> >>> Similarly, let's say you have 2 canvases and are rendering to both in a >>> worker. Does >>> >>> context1.commit(); >>> context2.commit(); >>> >>> guarantee you'll see both commits together? >> >> No, unfortunately not. There's no synchronisati
[webcomponents]: Custom elements no longer automagically create shadow trees
Folks, As of https://dvcs.w3.org/hg/webcomponents/rev/505225bb4a7b, the custom elements spec no longer has the extra plumbing for automatically creating all shadow trees along its inheritance chain. This responsibility now falls to the developer of the custom element to do this correctly (for example, by calling the callback of the super-class). It's a trade-off between convenience and flexibility. When I spoke with developers of the frameworks that are experimenting with shadow DOM and custom elements, I found that there were already two different ways (both slightly incompatible with what was currently spec'd) of initializing the shadow trees. This told me that the spec had too much opinion and it needed to get out of the way. :DG<
Re: [webcomponents]: Custom elements no longer automagically create shadow trees
+1 S On Wed, Feb 20, 2013 at 4:04 PM, Dimitri Glazkov wrote: > Folks, > > As of https://dvcs.w3.org/hg/webcomponents/rev/505225bb4a7b, the > custom elements spec no longer has the extra plumbing for > automatically creating all shadow trees along its inheritance chain. > This responsibility now falls to the developer of the custom element > to do this correctly (for example, by calling the callback of the > super-class). > > It's a trade-off between convenience and flexibility. When I spoke > with developers of the frameworks that are experimenting with shadow > DOM and custom elements, I found that there were already two different > ways (both slightly incompatible with what was currently spec'd) of > initializing the shadow trees. This told me that the spec had too much > opinion and it needed to get out of the way. > > :DG< >
Re: [webcomponents]: Building HTML elements with custom elements
On Feb 19, 2013 3:54 PM, "Dimitri Glazkov" wrote: > 2) Custom element constructor runs at the time of parsing HTML, as the > tree is constructed. > > PROBLEM: Several implementers let me know that allowing to run JS > while parsing HTML is not something they can accommodate in a > reasonable timeframe. > > COMPROMISE: Turn constructor into a callback, which runs in a > microtask at some later time (like upon encountering ). > > COST: Constructing an element when building a tree != createElement. > Also, there's an observable difference between the callback and the > constructor. Since the constructor runs before element is inserted > into a tree, it will not have any children or the parent. At the time > the callback is invoked, the element will already be in the tree--and > thus have children and the parent. Another cost is that when these elements will exist and be reachable from script before their constructor runs. In particular they wont always have had their constructor callback run when the constructor callback of other elements in the same subtree runs. / Jonas
