Re: [webkit-dev] DOM tree traversal on detached nodes

[Dominic Cooney]

On Thu, Jun 7, 2012 at 10:27 AM, Darin Adler  wrote:

> On Jun 6, 2012, at 6:14 PM, Kentaro Hara  wrote:
>
> IMHO, (a) would be the best semantics.
>
>
> I agree, and I think that the specification actually does require this.
>
> The real issue here is how to fix this bug efficiently. I believe that
> Geoff Garen has been contemplating this and also has a proposal for how to
> do it.
>

I’d love to see that proposal. Is it written up anywhere?

Regarding efficiency: what are the constraints?


> -- Darin
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Standard Compliance as a Project Goal (Was WebKit branch to support multiple VMs)

[Dominic Cooney]

First: Oliver and webkit-dev, sorry for the above email; I wrote it in
haste and am now repenting it at leisure.

Ryosuke—you’re right; given that the WebKit project goals page has ten
high-level goals, of course activity is guided by some trade-off between
them.

Dominic

On Thu, Dec 8, 2011 at 3:00 AM, Ryosuke Niwa  wrote:

> Starting new thread...
>
> On Wed, Dec 7, 2011 at 1:13 AM, Dominic Cooney wrote:
>>
>> On Wed, Dec 7, 2011 at 4:53 PM, Oliver Hunt  wrote:
>>>
>>> On Dec 6, 2011, at 11:49 PM, Dominic Cooney wrote:
>>>
>>> On Wed, Dec 7, 2011 at 1:44 AM, Oliver Hunt  wrote:
>>>
>>>>
>>>> On Dec 6, 2011, at 2:55 AM, Anton Muhin wrote:
>>>>
>>>> > Good day, everyone!
>>>> >
>>>> > I am sorry if it didn't sound clear enough in our original message,
>>>> > but we're not proposing a new language support, but we're proposing a
>>>> > patch which allows others runtimes to run along with JS in the
>>>> > browser.
>>>> >
>>>> > Of course, we're doing this because of our work on Dart, but our
>>>> > intent was to solicit a feedback from the WebKit community if there is
>>>> > any interest in supporting runtimes additional to JS (and not JS +
>>>> > Dart) in the first place.
>>>> As I have already said, we already support multiple bindings being in
>>>> use at the same time.
>>>
>>>
>>> Those bindings are different because the code that uses them is not
>>> activated from web pages. Looking at the specific posted patches, those
>>> changes seem necessary to support activating a different language from a
>>> page eg 

Re: [webkit-dev] WebKit branch to support multiple VMs (e.g., Dart)

[Dominic Cooney]

On Wed, Dec 7, 2011 at 4:53 PM, Oliver Hunt  wrote:

>
> On Dec 6, 2011, at 11:49 PM, Dominic Cooney wrote:
>
>
>
> On Wed, Dec 7, 2011 at 1:44 AM, Oliver Hunt  wrote:
>
>>
>> On Dec 6, 2011, at 2:55 AM, Anton Muhin wrote:
>>
>> > Good day, everyone!
>> >
>> > I am sorry if it didn't sound clear enough in our original message,
>> > but we're not proposing a new language support, but we're proposing a
>> > patch which allows others runtimes to run along with JS in the
>> > browser.
>> >
>> > Of course, we're doing this because of our work on Dart, but our
>> > intent was to solicit a feedback from the WebKit community if there is
>> > any interest in supporting runtimes additional to JS (and not JS +
>> > Dart) in the first place.
>> As I have already said, we already support multiple bindings being in use
>> at the same time.
>
>
> Those bindings are different because the code that uses them is not
> activated from web pages. Looking at the specific posted patches, those
> changes seem necessary to support activating a different language from a
> page eg 

Re: [webkit-dev] WebKit branch to support multiple VMs (e.g., Dart)

[Dominic Cooney]

On Wed, Dec 7, 2011 at 1:44 AM, Oliver Hunt  wrote:

>
> On Dec 6, 2011, at 2:55 AM, Anton Muhin wrote:
>
> > Good day, everyone!
> >
> > I am sorry if it didn't sound clear enough in our original message,
> > but we're not proposing a new language support, but we're proposing a
> > patch which allows others runtimes to run along with JS in the
> > browser.
> >
> > Of course, we're doing this because of our work on Dart, but our
> > intent was to solicit a feedback from the WebKit community if there is
> > any interest in supporting runtimes additional to JS (and not JS +
> > Dart) in the first place.
> As I have already said, we already support multiple bindings being in use
> at the same time.


Those bindings are different because the code that uses them is not
activated from web pages. Looking at the specific posted patches, those
changes seem necessary to support activating a different language from a
page eg 

[webkit-dev] -webkit-inline-box and visible descendants

[Dominic Cooney]

Hi webkittens,

Is there a spec for -webkit-inline-box?

I am investigating an assertion failure I can tickle using
-webkit-inline-box. But to fix this, I first need to understand what the
intended behavior is. If I have this markup:



#a {
  display: -webkit-inline-box;
  visibility: collapse;
}

#b {
  visibility: visible;
}



foo



This displays "foo"--pretty unsurprising. Same result as if #a had display:
inline-block, incidentally.

However if I wrap #b in another div, nothing is displayed. Plausible because
the new div inherits visibility: collapse from #a. But is this
intended/correct? Because it breaks the analogy with display: inline-block,
which still displays "foo."

Any advice appreciated!

Dominic
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Replacing DOM Mutation Events

[Dominic Cooney]

This looks awesome.

Do you have a link to Jonas‘ latest proposal? Because the original one
you linked to 

seems to be different to your patch (eg in API names, etc.) The
asymmetry between addMutationListener, which can incrementally
register for specific types, and removeMutationListener, which is a
blunt instrument, is curious… I would like to read the specific
proposal.

It would be nice if there was an open source test suite that is easily
accessible to UA implementors to ensure implementations are
consistent.

Dominic

On Wed, Aug 17, 2011 at 11:07 AM, Adam Klein  wrote:
> Greetings webkit-dev,
>
> It's generally agreed upon in the web community, and in WebKit
> specifically, that DOM Mutation Events are a bad thing. See, e.g.,
> discussion on https://bugs.webkit.org/show_bug.cgi?id=8191 (relating
> to DOMAttrModified, and why WebKit does not wish to implement it) and
> https://lists.webkit.org/pipermail/webkit-dev/2010-August/013805.html
> (a discussion of replacing DOM mutations with something better, or
> removing them entirely).
>
> In late June, Jonas Sicking and Olli Pettay from Mozilla put forward
> proposals on public-webapps
> (http://lists.w3.org/Archives/Public/public-webapps/2011AprJun/1318.html)
> to replace mutation events with a different API, one that avoids the
> problems associated with the existing spec.
>
> Rafael Weinstein has helpfully summarized the public-webapps thread
> (which is now upwards of 200 messages long) in
> http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/0779.html,
> and discussion is ongoing in
> http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/0780.html.
> Any WebKit folks interested in the future of mutation events in the
> DOM are invited to join that discussion, and their input would be much
> appreciated.
>
> I've also put together a partial implementation of Jonas' most recent
> proposal and uploaded my
> work-in-progress patch to
> https://bugs.webkit.org/show_bug.cgi?id=66079. Note that this is very
> early work, and if I were submitting it for review it would be in much
> smaller chunks, but I welcome any comments or questions on the code
> as-is.
>
> - Adam
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] JS bindings: Adding EventTarget to the prototype chain

[Dominic Cooney]

Thread necromancy! To summarize the original post: Currently WebKit’s JS
binding implements EventTarget as a mixin—all event targets have
addEventListener, removeEventListener and dispatchEvent methods. I propose
WebKit put EventTarget on the prototype chain.

There were two basic questions in response: (1) Why? and (2) Where are the
specs going?

(1) Why? To summarize the rationale from off-list replies, spec mailing list
threads, and webapps bug threads:

Making event targets inherit from EventTarget simplifies hooking that
functionality from a single choke-point. Otherwise, the web developer has to
track down all those separate objects hook each one. Why is EventTarget
special? What about other mixins? At the TC39 meeting in November, during a
discussion about removing multiple inheritance, EventTarget was brought up
as the mixin what would probably want to have global hooking done to it the
most.

(2) Where are the specs going?

The momentum for specifying EventTarget as an interface is building. In my
original post I noted that many specs (DOM Core, Notifications, Indexed DB,
SVG, XHR) already specified EventTarget as an interface; now the specs Hixie
edits (HTML5, Web RTC, Workers, Web Sockets) and FileReader do too.

Furthermore, there’s a comment from Jonas Sicking <
http://www.w3.org/Bugs/Public/show_bug.cgi?id=12574#c3> indicating that
Firefox is going to implement EventTarget this way, and from Travis
Leithead <http://www.w3.org/Bugs/Public/show_bug.cgi?id=12574#c15> endorsing
implementing EventTarget this way.

Which by my rough reckoning of specs implemented by WebKit, leaves just
FileWriter and Web Audio. Both of those specs are in a funny place where
they don’t specify EventTarget at all, but are event targets in WebKit. I
will follow up with Eric Urhane and Chris Rogers about these.

As I mentioned in my original post, the performance impact of this change is
minimal. So now that the specs are lined up, are there any objections to
making this change? If not I am going to work on reworking the prototype I
used to measure performance into a proper patch.

Dominic

On Fri, Jun 10, 2011 at 7:53 AM, Maciej Stachowiak  wrote:

>
> I don't have a personal opinion on which way is technically better myself.
> But I think the key is getting our code aligned with where standards are
> going, wether by changing he code or the standards. EventTarget in the
> prototype chain seems neither especially awesome nor especially terrible to
> me, it is not really clear to me why editor's drafts of the listed specs
> decided to change.
>
> Cheers,
> Maciej
>
>
>
> On Jun 9, 2011, at 1:14 PM, Sam Weinig wrote:
>
> I don't think we should do this.  EventTarget is really just an abstract
> interface, and changing its implementation globally is of limited utility.
>
> -Sam
>
> On Jun 8, 2011, at 5:54 PM, Dominic Cooney wrote:
>
> [If you don't care about JSC or V8 bindings you can safely ignore
> this.]
>
> TL;DR I want to change the JavaScript bindings to put EventTarget on
> the prototype chain so it is easier to work with event targets from
> JavaScript. What do you think?
>
> Here is the prototype chain for a button today:
>
> HTMLButtonElement-HTMLElement-Element-Node-Object
> (add/removeEventListener and dispatchEvent are on Node.)
>
> Here is how I think we should make it look:
>
> HTMLButtonElement-HTMLElement-Element-Node-EventTarget-Object
> (addEventListener etc. are on EventTarget.)
>
> Here’s why I think we should do this:
>
> - Specs are moving towards specifying EventTarget as living on the
> prototype chain. DOM Core*, Notifications, Indexed DB, SVG and XHR
> already do it this way. (* Editor’s draft.)
>
> - Frameworks that want to hook add/removeEventListener will be able to
> do it in one place: on EventTarget.prototype. In WebKit today they
> have to hook the prototypes of window, Node, XMLHttpRequest, etc.
> individually (Because WebKit implements EventTarget as a mixin
> everywhere, there are 20+ different kinds of event targets to hook if
> you want to be comprehensive.) If we make this change, it gets easier
> to tell if a given object is an EventTarget; just do
> EventTarget.prototype.isPrototypeOf(something).
>
> - It will modestly simplify WebKit’s IDLs and bindings. Instead of
> declaring addEventListener in two dozen places in IDLs, it will be in
> one place; instead of calling visitJSEventListeners in dozens of
> places for JSC GC, it will be called in one place; instead of assuming
> that EventTarget parameters are all Node* under the covers for V8 code
> generation, we can treat EventTargets uniformly; instead of
> redundantly specifying EventTarget on Document and Node inheritance
> will do what you want; etc.
>
> Will doing this break the web? I don’t think so:

Re: [webkit-dev] Shadow DOM API (first iteration) ready for landing

[Dominic Cooney]

On Wed, Jun 29, 2011 at 7:35 PM, Maciej Stachowiak  wrote:

>
> On Jun 28, 2011, at 11:33 PM, Dominic Cooney wrote:
>
> On Wed, Jun 29, 2011 at 1:01 PM, Geoffrey Garen  wrote:
>
>
> On Jun 28, 2011, at 5:15 PM, Dimitri Glazkov wrote:
>
>
> On Tue, Jun 28, 2011 at 4:49 PM, Geoffrey Garen  wrote:
>
> Hi Dmitri.
>
>
> Since this is an experimental API, here are the actual API names we want to
> use:
>
>
> Element.webkitShadow
>
> Element.webkitPseudo
>
> document.webkitCreateShadow()
>
> window.WebKitShadowRootConstructor
>
> window.WebKitTreeScopeConstructor
>
>
>
> Even though we've been using "shadow" as a term in our internal
> development, I think it makes a bad API name, since it's vague to its
> purpose, and it conflicts with the existing meaning of "shadow" on the web,
> which is a color radiating around a visual element.
>
>
> I sympathize and agree that there's a naming collision, but I think
>
> the train has left the station on this one. "Shadow tree" and "shadow
>
> content" are terms that have been used pretty much universally to
>
> describe this construct, from XBL/XUL and XBL2 to SVG. I don't think
>
> we need to invent a new name for it.
>
>
> Fair enough.
>
>
> How about using "shadow tree" or "shadow content" consistently instead of
> just "shadow"? I can imagine "webkitShadow" meaning a lot of different
> things. "webkitShadowTree" or "webkitShadowContent" seems clearer.
>
>
> Element.webkitShadowTree
>
>
> I agree that just "shadow" could be confused with CSS shadows,
> although those are boxShadow and textShadow, so maybe just shadow is
> OK from a grepping point of view.
>
> shadow*Tree* doesn’t feel quite right to me; consider
> shadowTree.firstChild? An element has a firstChild; a tree has lots of
> nodes.
>
> Element.webkitPseudo // not sure what this is -- showing my ignorance
>
> document.webkitCreateShadowTree()
>
>
> "…Tree" could be confusing because the object being created is just
> the container; it starts out empty. To me, "tree" and "content" refer
> to the whole shadow subtree, and the thing being created here is more
> specific.
>
>
> Calling it "shadow tree" or "shadow content" may be imprecise, but surely
> calling it "shadow" is outright inaccurate. Consider how you'd complete this
> sentence:
>
> I'd use the Element.webkitShadow API to get the __ for that element.
>
> I think I'd fill in that blank with "shadow tree" or "shadow DOM". I
> certainly wouldn't fill it in with "shadow". It sounds like your discussion
> leans in the direction of "shadow container" or maybe "shadow root". In fact
> the interface is called ShadowRoot so perhaps Element.webkitShadowRoot makes
> sense.
>

I think webkitShadowRoot makes sense—it is precise, the parallelism with the
constructor name makes sense, and the reflexive shadowHost/shadowRoot is
nice.


> Further question: are these APIs going to be part of whatever the XBL2 spec
> turns into? I can't find them in the latest Editor's draft:
> http://dev.w3.org/2006/xbl2/Overview.html
>
> In fact, XBL2 itself maintains the invariant that the shadow dom cannot be
> directly observed from the outside at all.
>
> Is there a record of the rationale for this rather different direction?
>  Are Mozilla and other likely future implementors (Opera, Microsoft) on
> board with this change of direction? The aforelinked document (<
> http://dglazkov.github.com/component-model/dom.html>) doesn't really
> explain the reasons . I also found a list of use cases: <
> http://wiki.whatwg.org/wiki/Component_Model_Use_Cases>. But there's not
> really an explanation of how this proposal meets the use cases, and from
> cursory examination it seems to blatantly violate one of them in a way that
> XBL2 did not: <
> http://wiki.whatwg.org/wiki/Component_Model_Use_Cases#Using_Shadow_DOM_Boundary_for_Isolation
> >
>

These are good questions; Dimitri is a better person to answer them than me.
On the security and isolation use case:

I take the point about exposing shadowRoot running counter to using shadow
DOM as a security boundary. I’m skeptical about that particular use case. I
think isolation should be supported by something that puts less emphasis on
presentation and is more closely related to the isolation boundary web pages
have today (ie iframes.) Easier isolation is appealing, but feels like a
pork-barrel amendment to XBL use cases. I have been and am going to keep
arguing against it in other venues.


> I'd like to see all of this explained better before putting this
> experimental API in the tree. If we are going to invent a new thing instead
> of implementing XBL2 or working with the relevant standards groups to
> improve XBL2, I think everyone should understand the reasoning for doing so.
>

Dominic

Regards,
> Maciej
>
>
>
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Shadow DOM API (first iteration) ready for landing

[Dominic Cooney]

On Wed, Jun 29, 2011 at 1:01 PM, Geoffrey Garen  wrote:
>
> On Jun 28, 2011, at 5:15 PM, Dimitri Glazkov wrote:
>
>> On Tue, Jun 28, 2011 at 4:49 PM, Geoffrey Garen  wrote:
>>> Hi Dmitri.
>>>
 Since this is an experimental API, here are the actual API names we want 
 to use:

 Element.webkitShadow
 Element.webkitPseudo
 document.webkitCreateShadow()
 window.WebKitShadowRootConstructor
 window.WebKitTreeScopeConstructor
>>>
>
>>> Even though we've been using "shadow" as a term in our internal 
>>> development, I think it makes a bad API name, since it's vague to its 
>>> purpose, and it conflicts with the existing meaning of "shadow" on the web, 
>>> which is a color radiating around a visual element.
>>
>> I sympathize and agree that there's a naming collision, but I think
>> the train has left the station on this one. "Shadow tree" and "shadow
>> content" are terms that have been used pretty much universally to
>> describe this construct, from XBL/XUL and XBL2 to SVG. I don't think
>> we need to invent a new name for it.
>
> Fair enough.
>
> How about using "shadow tree" or "shadow content" consistently instead of 
> just "shadow"? I can imagine "webkitShadow" meaning a lot of different 
> things. "webkitShadowTree" or "webkitShadowContent" seems clearer.
>
> Element.webkitShadowTree

I agree that just "shadow" could be confused with CSS shadows,
although those are boxShadow and textShadow, so maybe just shadow is
OK from a grepping point of view.

shadow*Tree* doesn’t feel quite right to me; consider
shadowTree.firstChild? An element has a firstChild; a tree has lots of
nodes.

> Element.webkitPseudo // not sure what this is -- showing my ignorance
> document.webkitCreateShadowTree()

"…Tree" could be confusing because the object being created is just
the container; it starts out empty. To me, "tree" and "content" refer
to the whole shadow subtree, and the thing being created here is more
specific.

> window.WebKitShadowTreeConstructor // all trees begin at a root, right?
> window.WebKitShadowTreeScopeConstructor // assuming this can only be used 
> inside the shadow tree

For uniformity we were going to also make documents tree scopes. This
makes things simpler for script because every element, text node, etc.
will be in a tree scope (a document or a shadow root.)

Dominic

> Geoff
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

[webkit-dev] JS bindings: Adding EventTarget to the prototype chain

[Dominic Cooney]

[If you don't care about JSC or V8 bindings you can safely ignore
this.]

TL;DR I want to change the JavaScript bindings to put EventTarget on
the prototype chain so it is easier to work with event targets from
JavaScript. What do you think?

Here is the prototype chain for a button today:

HTMLButtonElement-HTMLElement-Element-Node-Object
(add/removeEventListener and dispatchEvent are on Node.)

Here is how I think we should make it look:

HTMLButtonElement-HTMLElement-Element-Node-EventTarget-Object
(addEventListener etc. are on EventTarget.)

Here’s why I think we should do this:

- Specs are moving towards specifying EventTarget as living on the
prototype chain. DOM Core*, Notifications, Indexed DB, SVG and XHR
already do it this way. (* Editor’s draft.)

- Frameworks that want to hook add/removeEventListener will be able to
do it in one place: on EventTarget.prototype. In WebKit today they
have to hook the prototypes of window, Node, XMLHttpRequest, etc.
individually (Because WebKit implements EventTarget as a mixin
everywhere, there are 20+ different kinds of event targets to hook if
you want to be comprehensive.) If we make this change, it gets easier
to tell if a given object is an EventTarget; just do
EventTarget.prototype.isPrototypeOf(something).

- It will modestly simplify WebKit’s IDLs and bindings. Instead of
declaring addEventListener in two dozen places in IDLs, it will be in
one place; instead of calling visitJSEventListeners in dozens of
places for JSC GC, it will be called in one place; instead of assuming
that EventTarget parameters are all Node* under the covers for V8 code
generation, we can treat EventTargets uniformly; instead of
redundantly specifying EventTarget on Document and Node inheritance
will do what you want; etc.

Will doing this break the web? I don’t think so:

Anyone who calls or hooks addEventListener, etc. will continue to
work, just their foo.addEventListener might be resolved at one level
higher up the prototype chain than it is today. To really observe the
different placement of addEventListener, etc. minutely you need to
access __proto__ and hasOwnProperty. Other browsers are already differ
from WebKit in this regard, too: For example, Firefox reports
addEventListener is an own property on *every* step in the prototype
chain of DOM objects (until Object.)

Scripts that squirrel up the prototype chain themselves will see one
more link (EventTarget’s) but it is towards the top of the chain, past
most prototypes they care about (every prototype except Object.)

I tried changing half of the EventTargets in WebKit to put EventTarget
in the prototype chain, including Node and XHR (but not window) and
used it to surf the web for a few days. I didn’t notice anything break
:)

There is also the possibility that this could hurt performance,
because accessing addEventListener, etc. will have to search more
prototypes (usually just one more.) Accessing the properties of Object
on an event target via the prototype chain will have to squirrel
through one more prototype (EventTarget’s.) So I prototyped this
change in the JSC bindings and put EventTarget in the prototype chain
of a number of event targets in WebKit, including Node. Here are the
results for Dromaeo’s dom and jslib tests:



(141811 on the left is the status quo.)

I expect the Prototype and jQuery events benchmarks are of particular
interest, and the result looks particularly bad for Prototype (~3%
slowdown). So I reran  half a dozen times,
and couldn’t produce the poor result for Prototype; on average the
prototype was 1.0% slower for Prototype and 0.5% slower for jQuery. I
think Dromaeo is too noisy for measuring something as fine as this.

So I wrote three microbenchmarks:

1. Add/remove click listener on a button.

2. Add/remove progress listener on an XHR.

3. Test property presence with 'in':

if ('dispatchEvent' in target)
 n++;
// return n outside of loop

where target is an XMLHttpRequest and n is a local var n = 0.

Here are the results. A brief note on methodology: release build
running in Mac Safari, JSC, averaging 500 samples with 1,000,000
iterations of the inner loop per sample.

1. Add/remove on button
Before (ms): min=409, median=434, mean=434.4, max=472
After (ms): min=410, median=453.5, mean=452.4, max=497 (mean is 1.04x)

2. Add/remove on XHR
Before (ms): min=286, median=298, mean=298.6, max=315
After (ms): min=287, median=300.5, mean=300.7, max=320 (mean is 1.01x)

3. 'dispatchEvent' in XHR
Before (ms): min=85, median=88, mean=87.7, max=91
After (ms): min=89, median=91, mean=91.0, max=95 (mean is 1.04x)

So this shows that, yes, this is not free, but it is low-single
digits. Since adding and removing event listeners is a relatively
infrequent operation, I think this is OK. I want to emphasize that the
change I’m proposing has no impact on native event *dispatch*, which
is obviously a lot more performance-sensitive than adding a