Intent to Implement and Ship: Moving DOM attributes to prototype chains

[Kentaro Hara]

Primary eng (and PM) emails

har...@chromium.org

Spec

Web IDL: http://dev.w3.org/2006/webapi/WebIDL/#es-attributes

Summary

Currently DOM attributes are defined on DOM objects. JavaScript getters/setters are not exposed on DOM attributes, like this:

  div = document.createElement(“div”);

  div.hasOwnProperty(“id”);  // true

  div.__proto__.__proto__.hasOwnProperty(“id”);  // false

  Object.getOwnPropertyDescriptor(div, “id”);  // Object {value: "", writable: true, enumerable: true, configurable: true}

  Object.getOwnPropertyDescriptor(div.__proto__.__proto__, “id”);  // undefined

However, the current behavior is wrong per the Web IDL spec. Per the spec, we should move DOM attributes from DOM objects to JavaScript prototype chains and expose JavaScript getters/setters on DOM attributes. Specifically, we are planning to change the behavior as follows:

  div = document.createElement(“div”);

  div.hasOwnProperty(“id”);  // false

  div.__proto__.__proto__.hasOwnProperty(“id”);  // true

  Object.getOwnPropertyDescriptor(div, “id”);  // undefined

  Object.getOwnPropertyDescriptor(div.__proto__.__proto__, “id”);  // Object {get: function, set: function, enumerable: false, configurable: false}

See this design document for more details: https://docs.google.com/a/google.com/document/d/1yeHTCHhulVIlrKyx9_gCguAhLfcefVOa9uxxfW2LVG0/edit#

Motivation

The change is necessary for correctness, cross-browser compatibility, and moving the Web forward:

- The new behavior is conformant with the Web IDL spec.

- The new behavior is already implemented in IE and Firefox.

- The new behavior enables developers to hook DOM attribute getters/setters. This will improve hackability of DOM operations. It will enable developers to implement Polyfill and JavaScript libraries that override default DOM attribute behaviors. In particular, Polyfill implementation will become much easier and faster.

- The new behavior makes it easy to port Blink’s C++ implementation into JavaScript and reduce complexity of Blink. For example, we are planning to move editing implementation (e.g., execCommand) from C++ to JavaScript. With the new behavior, we just need to hook DOM attribute getters/setters and implement the logic all in JavaScript.

- The new behavior is necessary for custom elements in the Web Components, which we are planning to ship in M33. In custom elements, developers can define customized DOM elements that inherit from existing DOM elements. Here developers want to override DOM attribute behavior of existing DOM elements by hooking their JavaScript getters/setters.

Compatibility Risk

Low. IE and Firefox already implemented the new behavior more than one year ago. On the other hand, Safari has not yet implemented the new behavior.

Ongoing technical constraints

- Performance regression. This change will regress several micro benchmarks by 10% or so. We have been working on this project for two years and are concluding that it would be hard to decrease the regression any more without crankshafting binding callbacks to V8 (See https://docs.google.com/a/google.com/document/d/1yeHTCHhulVIlrKyx9_gCguAhLfcefVOa9uxxfW2LVG0/edit# for more details). However, implementing the crankshafting will take three more quarters. Thus, the question here is whether we should wait for the optimization and then make the change, or we should make the change and then do the optimization. If we should stick to the no regression policy, we should wait for the optimization. However, in this specific case, I'm thinking that the advantage of making this change now would be larger than the advantage of sticking to the no regression policy for micro benchmarks. Thus I propose to make the change even though it will regress performance of micro benchmarks. We will fix the regression in upcoming quarters. I'd like to hear thoughts of other Blink people about the performance trade-off.

- It is hard to implement this feature behind a runtime flag because of the performance overhead to check the runtime flag in DOM attribute access. So I'm planning to implement and ship the feature at the same time.

Will this feature be supported on all five Blink platforms (Windows, Mac, Linux, Chrome OS and Android)?

Yes. This change is platform-independent.

--
Kentaro Hara, Tokyo, Japan

[Jochen Eisinger]

LGTM++

[Erik Arvidsson]

LGTM

[Dimitri Glazkov]

LGTM2.

[Christophe Dumez]

LGTM

LGTM2.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

--
Christophe DUMEZ

[TAMURA, Kent]

> This change will regress several micro benchmarks by 10% or so.

Is it only for micro benchmarks, or is it possible to affect practical web
applications?

--
TAMURA Kent
Software Engineer, Google

[Eric Seidel]

I'm supportive of this change. It would be interesting to know which
microbenchmarks we're talking about (at a high-level).

[Kentaro Hara]

Thanks all for comments! Let me follow up about micro-benchmark performance.

tkent:

> This change will regress several micro benchmarks by 10% or so.
Is it only for micro benchmarks, or is it possible to affect practical web
applications?

eric:

I'm supportive of this change.  It would be interesting to know which
microbenchmarks we're talking about (at a high-level).

In general, this will only regress performance of micro benchmarks whose performance are determined by pure overhead of binding callbacks.

For example, Dromaeo/dom-traverse is just traversing DOM trees. Since firstChild, parentNode etc are already perfectly optimized in Blink and they do almost nothing in Blink, the performance is determined by pure overhead of binding callbacks. Thus I'm observing 8.7% regression in Dromaeo/dom-traverse. Similarly, I'm observing regressions in pathological micro benchmarks in PerformanceTests/Bindings.

On the other hand, I'm not observing any regression in Dromaeo/dom-attr and Dromaeo/dom-modify, because they are also micro benchmarks but doing something non-trivial in Blink. Of course, I'm not observing any regression in RoboHornet.

These regressions will be completely gone (rather the performance will significantly improve) once we move binding callbacks to V8's JIT compiler. This optimization will take a couple of quarters, but we're planning to do it because the optimization is important to make bindings faster in general.

In practice, I'm currently planning to start moving 20 popular DOM attributes (used in Dromaeo) to prototype chains and see how perf bots look like and how the change affects page loading time in UMA. If we observe unacceptable regressions in Windows/Android bots etc, I will reconsider how to ship the feature.

[Eric Seidel]

LGTM.

[TAMURA, Kent]

ok, LGTM4.

[Kentaro Hara]

I will keep updating the status in this bug: 

https://code.google.com/p/chromium/issues/detail?id=43394

so please follow the bug if you're interested in further discussion about performance concerns.

Also I'm happy to discuss other general concerns in this thread.

Thanks!