Intent-to-Ship: Moving DOM attributes to prototype chains

[Kentaro Hara]

TL;DR: Performance had been the show-stopper for shipping the feature, but the performance issues are getting resolved. Now I think we're ready to ship the feature.

 

Primary eng (and PM) emails

har...@chromium.org, yukis...@chromium.org, joc...@chromium.org, dca...@chromium.org

Spec

Web IDL: https://heycam.github.io/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 spec. Per the spec, we should move DOM attributes from DOM objects to JavaScript prototype chains and expose JavaScript getters/setters. 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 the design document (*1) for more details.

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 programming. For example, it will enable developers to implement Polyfill and JavaScript libraries that override default DOM attribute behaviors. Another important use case would be custom elements, because with custom elements, developers want to customize DOM attribute behavior of existing elements by hooking their JavaScript getters/setters.

Compatibility Risk

Low. IE and Firefox already implemented the new behavior more than two years ago. Safari has not yet implemented the new behavior.

To reduce the compatibility risk as much as possible, we're planning to make the change in the following steps:

Step 1: Move popular DOM attributes used in Dromaeo (CL: *2)

Step 2: Move most DOM attributes (CL: *3)

Step 3: Move all the remaining DOM attributes

I have landed the CL for Step 1 multiple times and kept it on trunk for a couple of days, but I didn't receive any behavioral bugs.

Ongoing technical constraints

- Performance regression in micro-benchmarks. The V8 team has landed a bunch of optimizations and the performance is now getting to a good shape. This sheet (*4) describes the performance impacts of moving DOM attributes to prototype chains. The summary is as follows:

- Page cycler and Speedometer: No improvement or regression.

- blink_perf benchmarks other than the below: No significant improvement or regression.

- dom-attribute-on-prototype-chain.html (a crazy benchmark that will be affected by this change the most): -17%.

- Dromaeo/domtraverse: -12%.

- Dromaeo/jslibstyleprototype: -4%.

- Dromaeo/jslibtraversejquery: -3%. Note that this benchmark was made 12% faster recently (*5).

- Dromaeo/jslibtraverseprototype: -3%. Note that this benchmark was made 60% faster recently (*6).

- Overall, only a couple of micro-benchmarks will regress by this change. Also the V8 team is actively working on more optimizations, just like they recently made a significant improvement on Dromaeo/jslibtraversejquery and Dromaeo/jslibtraverseprototype as described above. Therefore, I think that now is a timing to consider shipping the change. I think that the advantage of shipping the change now would be larger than the advantage of sticking to the no regression policy for micro benchmarks, to move the Web forward.

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

Yes. This change is platform-independent.

(*1) https://docs.google.com/a/google.com/document/d/1yeHTCHhulVIlrKyx9_gCguAhLfcefVOa9uxxfW2LVG0/edit#

(*2) https://codereview.chromium.org/158713002/

(*3) https://codereview.chromium.org/447523003/
(*4) https://docs.google.com/a/google.com/spreadsheets/d/1Q6h2A11a2R4Q_MRuv_diyZCNzQBFExziXkV2MwChw48/edit#gid=622133744

(*5) https://chromeperf.appspot.com/report?masters=ChromiumPerf&bots=linux-release&tests=dromaeo.jslibtraversejquery%2Fjslib&checked=all&start_rev=311769&end_rev=315740

(*6) https://chromeperf.appspot.com/report?masters=ChromiumPerf&bots=linux-release&tests=dromaeo.jslibtraverseprototype%2Fjslib&checked=all&start_rev=311769&end_rev=315740

--

Kentaro Hara, Tokyo, Japan

[Jochen Eisinger]

LGTM

(Note that we had prior intent to ship threads for this features, but had to back out because of performance and correctness issues. With the latest round of performance optimizations Dan landed that shouldn't be an issue anymore)

[Boris Zbarsky]

On 2/11/15 3:17 AM, Kentaro Hara wrote:
> TL;DR: Performance had been the show-stopper for shipping the feature,
> but the performance issues are getting resolved. Now I think we're ready
> to ship the feature.

This is great news!

One thing to watch out for compat wise (and I'm pretty sure you're aware
of it already, but just in case you aren't...) is that the getter/setter
pairs for the Window interface need to live on the actual window object,
not Window.prototype.

Thank you again for persevering with this,
Boris

[Dimitri Glazkov]

LGTM2.

:DG<

[Erik Arvidsson]

+1

Thanks for going the distance with this. I know it has been a multi year effort.

--
erik

[PhistucK]

Can you, please, provide an example of such getter and setter pair and the specification text that mandates this?

☆PhistucK

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

[Philip Jägenstedt]

LGTM3, this is great!

> To unsubscribe from this group and stop receiving emails from it, send an

> email to blink-dev+...@chromium.org.

[Boris Zbarsky]

On 2/11/15 12:53 PM, PhistucK wrote:
> Can you, please, provide an example of such getter and setter pair and
> the specification text that mandates this?

Say the "indexedDB" property on Window.

The relevant spec text is at
http://heycam.github.io/webidl/#es-attributes under "The location of the
property is determined as follows:". Note that Window is [PrimaryGlobal].

-Boris

[PhistucK]

Hay

Oh... so it means it (indexedDB) is (or should be) located on the prototype (Window.prototype) as well as on the object (window), if I read it correctly ("Otherwise, if the interface is a consequential interface of a [Global]- or [PrimaryGlobal]-annotated interface, then the property exists on the single object that implements the [Global]- or [PrimaryGlobal]-annotated interface as well as on the consequential interface’s interface prototype object.").

It effectively means that overriding Window.prototype.indexedDB will not affect window.indexedDB, right?

Do you happen to know what is the purpose of this instruction? Was it just 'documenting the way the web is actually already implemented in browsers'?

I ask because Closure Compiler defines almost everything on the prototype (indexedDB example) and not on the object itself and if this has some actual consequences, Closure Compiler may need to change (though I strive for correctness anyway).

Thank you for taking the time to respond. :)

☆PhistucK

[Boris Zbarsky]

On 2/11/15 3:51 PM, PhistucK wrote:
> Oh... so it means it (indexedDB) is (or should be) located on the
> prototype (Window.prototype) as well as on the object (window)

No.

> if I read it correctly

I think you're reading it incorrectly.

> ("Otherwise, if the interface is a consequential
> interface of a [Global]- or [PrimaryGlobal]-annotated interface, then
> the property exists on the single object that implements the [Global]-
> or [PrimaryGlobal]-annotated interface as well as on the consequential
> interface’s interface prototype object.").

Right, so it should appear on the window object and also on the
IDBEnvironment interface prototype object. Of course in practice the
latter is not observable (because IDBEnvironment is [NoInterfaceObject]
and nothing actually has IDBEnvironment or anything inheriting from it
as its primary interface).

> It effectively means that overriding Window.prototype.indexedDB will not
> affect window.indexedDB, right?

That's correct.

> Do you happen to know what is the purpose of this instruction?

Yes, of course. The purpose was so that web pages that do this in
global scope:

var indexedDB =
window.webkitIndexedDB || window.mozIndexedDB ||
window.msIndexedDB || window.indexedDB;

don't break when you remove the prefixed version. As we discovered the
hard way in <https://bugzilla.mozilla.org/show_bug.cgi?id=770844>, fwiw.

There was a bunch of discussion about this on public-script-coord at the
time,

> Was it just 'documenting the way the web is actually already implemented in
> browsers'?

Actually, no. It was defining a behavior that's predictable and yet
doesn't lead to failures when code like the above is written.... That
behavior didn't match any of the UAs at the time, because all of them
were still shipping prefixed versions of everything. What's in the spec
was the best solution people managed to come up with.

> Thank you for taking the time to respond. :)

No problem.

-Boris

[PhistucK]

​Hay

Right, I missed the "consequential interface's interface prototype object". :)​

On Wed, Feb 11, 2015 at 11:06 PM, Boris Zbarsky <bzba...@mit.edu> wrote:

Yes, of course.  The purpose was so that web pages that do this in global scope:

  var indexedDB =
    window.webkitIndexedDB || window.mozIndexedDB ||
    window.msIndexedDB || window.indexedDB;

don't break when you remove the prefixed version.  As we discovered the hard way in <https://bugzilla.mozilla.org/show_bug.cgi?id=770844>, fwiw.

There was a bunch of discussion about this on public-script-coord at the time,

​How does locating it as window.indexedDB change anything?

After all, global variables (foo) are also set on window (window.foo)... Why does var localStorage = 0 (in the global context) not result in window.localStorage = 0?

☆PhistucK

[Boris Zbarsky]

On 2/11/15 4:31 PM, PhistucK wrote:
> ​How does locating it as window.indexedDB change anything?

Because then the var doesn't shadow it.

> After all, global variables (foo) are also set on window (window.foo)...

Yes.

> Why does var localStorage = 0 (in the global context) not result in
> window.localStorage = 0?

Because the property is readonly in the IDL, which means that in the ES
binding it's an accessor property with undefined as the setter.

-Boris

[PhistucK]

Hay

Oh, right, that makes sense. Read only attributes are not shadowed, of course. Sorry for wasting your time without thoroughly checking the interfaces and reading the entire text I quoted. :(

Have a nice day!

☆PhistucK

[Takayoshi Kochi]

Non-owner +1!

This is a great step for interoperability.

--

Takayoshi Kochi

[Chris Harrelson]

LGTM4

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

[Yuki Shiino]

We're going to commit a following CL which moves most of DOM attributes to prototype chains.

https://codereview.chromium.org/984523003/

Exceptions are:

- Indexed property

- Named property

- Constructor attribute

- Custom getter/setter

- Window's attributes

- WorkerGlobalScope's attributes

We're working on these attributes, and will move them, too.

Cheers,

Yuki Shiino

[Noel Gordon]

Any updates on perf?  I ask since Jochen@ noted earlier in this thread:

> (Note that we had prior intent to ship threads for this features, but had to back out because of performance and correctness issues. With the latest round of performance optimizations Dan landed that shouldn't be an issue anymore)

[Domenic Denicola]

From: yukis...@google.com [mailto:yukis...@google.com] On Behalf Of Yuki Shiino

> We're going to commit a following CL which moves most of DOM attributes to prototype chains. https://codereview.chromium.org/984523003/

\o/!!!

> Exceptions are:

I imagine you guys are already aware, but just in case:

A lot of these are actually pretty subtle according to Web IDL, and don't actually present as being on the prototype chain (or as being accessors). For example indexed and named properties present as own-data properties (so, Blink is pretty close to compliant already), and for window/other globals they actually must be own properties (although they should still be accessors, which they currently are not in Blink).

So, there may be less work left here than the list indicates!

[Yuki Shiino]

No major update on perf.  Dan already improved the performance very much as jochen@ wrote, and since then, there is no major update.

Cheers,

Yuki Shiino

[Kentaro Hara]

It seems you've succeeded in landing the change without breaking any tests in Blink & Chromium. Congrats!!

https://codereview.chromium.org/984523003/

[Patrick Meenan]

FWIW, the perf bots went pretty crazy when it landed and we're seeing regressions in the micro-benchmarks for anything that touches the DOM, layout and the page cyclers.  More may show up as the bisects from yesterdays alerts flwo through but so far they are being collected here: https://code.google.com/p/chromium/issues/detail?id=467549

[Philip Jägenstedt]

From the bug: "I know the bindings change was expected to cause a regression in a set of tests (particularly dromeo) but it looks like the impact was a lot larger and included a huge swath of tests (from page load times to layout tests)."

Does this mean we should expect regressions in page load time large enough to be perceptible by users? It looks like these perf tests group a bunch of sites or tests together, is there a worst case regression in load time for a real-world site that can be extracted from the data?

Philip

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

[Kentaro Hara]

As far as we experimented locally, there was no regression in page load times in telemetry benchmarks. We're investigating.

[Harald Alvestrand]

It seems that this change caused JSON.stringify to change its behavior when stringifying DOM objects.

Was this an intended consequence?

See, for instance:

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

[Kentaro Hara]

It seems that this change caused JSON.stringify to change its behavior when stringifying DOM objects.

Was this an intended consequence?
See, for instance:
https://code.google.com/p/chromium/issues/detail?id=467471

Yes, this is an intended consequence. The new behavior is correct with the spec and aligns with Firefox and IE.

See the comment #25 in the bug for a way to stringify DOM objects in the correct world.

[Peter Beverloo]

This also caught us by surprise with the Push API, but we also found that other browsers weren't doing this at all. https://crbug.com/467366

Note that interfaces can define a serializer which would enable this behavior, which I'm proposing to add for Push:

  https://github.com/w3c/push-api/issues/125

Thanks,

Peter

[Patrick Meenan]

The page load times themselves got ~3-5% slower on average but that's in a replay case where network isn't constrained at all.  It probably won't translate to an equivalent slowdown in the field but on fast connections for specific sites or with cached/offline content it should.  FWIW, performance changes don't necessarily need to be directly perceptible to drive behavior change.

The impacts to some of the layout tests concern me more than the overall page load time hit (I assume the PLT hit is caused by the layout and DOM traversal regressions).

Specifically these:

15% regression on the Shapes_MultipleShapes layout test

10% regression in several of the svg tests

[Kentaro Hara]

The page load times themselves got ~3-5% slower on average but that's in a replay case where network isn't constrained at all.  It probably won't translate to an equivalent slowdown in the field but on fast connections for specific sites or with cached/offline content it should.

The regressions in PLT are unexpected ones and the numbers are a bit too big. Personally, I don't think we should revert the change but at least we should have a plan to fix the regression. yukishiino@ is trying to reproduce the regression locally.

[Elliott Sprehn]

On Wed, Mar 18, 2015 at 6:36 AM, 'Patrick Meenan' via blink-dev <blin...@chromium.org> wrote:

...

The impacts to some of the layout tests concern me more than the overall page load time hit (I assume the PLT hit is caused by the layout and DOM traversal regressions).

Specifically these:

15% regression on the Shapes_MultipleShapes layout test

This perf test doesn't really do much binding work, it document write's a big string and then forces a layout.  Are we sure this is related?

- E

[Patrick Meenan]

The bisects quite reliably keep going back to the cl that changed the bindings. One more just came through that I didn't think could be related but there was a 25% regression on inserting iFrames. 

[Elliott Sprehn]

On Wed, Mar 18, 2015 at 5:59 PM, Patrick Meenan <pme...@google.com> wrote:

The bisects quite reliably keep going back to the cl that changed the bindings. One more just came through that I didn't think could be related but there was a 25% regression on inserting iFrames. 

Very suspicious, someone needs to dig into it with a profiler.

 

[Dimitri Glazkov]

I think that's what haraken said earlier: "yukishiino@ is trying to reproduce the regression locally."

:DG<

[Kentaro Hara]

I think that's what haraken said earlier: "yukishiino@ is trying to reproduce the regression locally."

Yes, we're investigating; so stay tuned for a while :)

[Rick Byers]

We're still planning on shipping this in Chrome 43, right?

Since this will have web developer impact (one example of many here), perhaps there should be an entry on chromestatus.com and/or an OWP launch tracking bug?  Eg. we need to make absolutely sure we don't forget to mention this in the Chrome 43 blog post.

I'm excited to see this stick!  Here's an example (from Majid) of something really valuable that this enables: a script that logs (or breaks in the debugger) on all calls that change scroll position (or any other DOM attribute).

Rick

[Paul Kinlan]

I'm working on the post for developers right now (will share more broadly shortly) with information on the impact of the change.  But yes it should also be in ChromeStatus if it is not.

P

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

--

Paul Kinlan

Staff Developer Advocate and Lead for Chrome and Web

Subscribe to my developer newsletter: http://www.refreshbox.co/newsletterInfo/oWesTmTrG6w

G+: http://plus.ly/paul.kinlan

t: +447730517944

tw: @Paul_Kinlan

LinkedIn: http://uk.linkedin.com/in/paulkinlan

Blog: http://paul.kinlan.me

[Alex Komoroske]

Yes, this should definitely have an entry in ChromeStatus.

[PhistucK]

This is a pretty big (and great) change that I think it deserves its own "coming soon to beta" post and not just one paragraph of the regular "beta features" post.

I am glad this is getting the proper attention!

☆PhistucK

[Yuki Shiino]

I've written a simple memo about what would happen and how web site developers can fix it.

https://docs.google.com/document/d/1OQSXtG_pas12y1PN04Idfchy_Ujrab8tiYNh-M95bho/edit

This is linked from https://www.chromestatus.com/feature/6052436003258368

Hope this help Blink guys better understand possible issues.

Cheers,

Yuki Shiino

[Paul Kinlan]

I also have a blog post (but on html5rocks) coming out soon.

[Harald Alvestrand]

I made a few suggestions on the memo (marked "anonymous") - the most important one being that we should encourage people to use "stringifier" in their WebIDL if they're writing WebIDL and it's appropriate.

[Anne van Kesteren]

On Mon, Apr 13, 2015 at 9:55 AM, 'Harald Alvestrand' via blink-dev
<blin...@chromium.org> wrote:
> I made a few suggestions on the memo (marked "anonymous") - the most
> important one being that we should encourage people to use "stringifier" in
> their WebIDL if they're writing WebIDL and it's appropriate.

If the intended audience is web developers, that does not seem like
advice they can use.


--
https://annevankesteren.nl/

[Harald Alvestrand]

OTOH, if the intended audience is blink-dev, it's advice they need to have.

 

--
https://annevankesteren.nl/

[Yuki Shiino]

Added a description about stringifier.  Thanks for the comments.

[Ryan Schoen]

Have we made any progress on the performance side of this? We should really either justify the performance impact or decide to do something about it, sooner rather than later.

[Dan Carney]

the v8 is still working on getting rid of prototype chain checks, which will make a big difference, but it's a big change and it'll take more time. it's unlikely that other bindings changes will improve things significantly until then.

[Paul Kinlan]

All, I have staged a version of our web developer guidance here: http://development.updaterocker.appspot.com/2015/04/DOM-attributes-now-on-the-prototype (some changes are still waiting to be deployed)

I am certainly open to feedback.  I haven't addressed performance issues in this post yet, but I am curious to work out how we message that we are slowing down Chrome for a version or two... (if that is the case).

[Rick Byers]

On Tue, Apr 14, 2015 at 6:07 AM, Paul Kinlan <paulk...@google.com> wrote:

All, I have staged a version of our web developer guidance here: http://development.updaterocker.appspot.com/2015/04/DOM-attributes-now-on-the-prototype (some changes are still waiting to be deployed)

This looks great to me Paul!  Couple questions:

1) I don't think the 'isSuperContentEditable' example is correct.  AFAIK you can add new attributes to the prototype chain of DOM objects no problem (a quick test on M42 shows your example works for me).  I thought the only problem was with the built-in attributes?  I.e. trying to define a new attributes that shadows ones of blink's built-in attributes.  Also minor nit: your example is missing ');' at the end to make the syntax valid.

2) Instead of showing the examples with lots of chained __proto__ calls (which is really discouraged style) perhaps we should just name the prototype precisely?  I.e. instead of:

Object.getOwnPropertyDescriptor(div.__proto__.__proto__.__proto__, "isContentEditable");

Use

Object.getOwnPropertyDescriptor(Element.prototype, "isContentEditable");

I am certainly open to feedback.  I haven't addressed performance issues in this post yet, but I am curious to work out how we message that we are slowing down Chrome for a version or two... (if that is the case).

I'm really anxious to see this fixed ASAP.  But if we haven't convinced ourselves the performance impact is OK by this point (beta release) perhaps we should defer another milestone? 

[Paul Kinlan]

re 1: it was supposed to hint at consistency with 

re2: Urgh, yes. Also it is HTMLElement

[Paul Kinlan]

Double Urgh, missed

re 1:  it was supposed to hint at consistency with having other attributes on the prototypes, it's not that it doesn't work.  Will sort.

[PhistucK]

I am not sure this was intended, but the post is live -

http://updates.html5rocks.com/2015/04/DOM-attributes-now-on-the-prototype

And it still says that you cannot define a getter on a prototype when you certainly can...

Thank you for writing the post! Perhaps the Chromium blog can link to it as well, without waiting for the beta post (but also mention it and link to it in the beta post, of course).

☆PhistucK

[Paul Kinlan]

>And it still says that you cannot define a getter on a prototype when you certainly can... 

Where does it say that? Happy to work on the phrasing as that is not what is intended.

[PhistucK]

Sorry, you imply that you had to define it on every instance -

"Prior to this change — for consistency with other DOM Attributes in Chrome — you would have had to create the new property on every instance, which for every HTMLDivElement on the page would be very inefficient."

Perhaps I am misunderstanding the sentence?

☆PhistucK

[Elliott Sprehn]

On Tue, Apr 14, 2015 at 6:29 AM, Rick Byers <rby...@chromium.org> wrote:

...

I am certainly open to feedback.  I haven't addressed performance issues in this post yet, but I am curious to work out how we message that we are slowing down Chrome for a version or two... (if that is the case).

I'm really anxious to see this fixed ASAP.  But if we haven't convinced ourselves the performance impact is OK by this point (beta release) perhaps we should defer another milestone? 

I think we're pretty convinced that this is the right thing to do. The needs of the many out weigh the needs of the few prototype checks.

[Jochen Eisinger]

On Tue, Apr 14, 2015 at 7:35 PM Elliott Sprehn <esp...@chromium.org> wrote:

On Tue, Apr 14, 2015 at 6:29 AM, Rick Byers <rby...@chromium.org> wrote:

...

I am certainly open to feedback.  I haven't addressed performance issues in this post yet, but I am curious to work out how we message that we are slowing down Chrome for a version or two... (if that is the case).

I'm really anxious to see this fixed ASAP.  But if we haven't convinced ourselves the performance impact is OK by this point (beta release) perhaps we should defer another milestone? 

I think we're pretty convinced that this is the right thing to do. The needs of the many out weigh the needs of the few prototype checks.

Also, past experience shows that only the code path we actually ship gets improved.

[Paul Kinlan]

Ah, I don't say it doesn't work, I say that developers choose not to put it on the prototype, the "for consistency with other DOM Attributes in Chrome" is the key here. You can define it on the prototype but your logic is different for hasOwnProperty so to keep things consistent you would avoid the prototype.

I'll try and clarify more.

P

[Rick Byers]

On Tue, Apr 14, 2015 at 1:39 PM, Jochen Eisinger <joc...@chromium.org> wrote:

On Tue, Apr 14, 2015 at 7:35 PM Elliott Sprehn <esp...@chromium.org> wrote:

On Tue, Apr 14, 2015 at 6:29 AM, Rick Byers <rby...@chromium.org> wrote:

...

I am certainly open to feedback.  I haven't addressed performance issues in this post yet, but I am curious to work out how we message that we are slowing down Chrome for a version or two... (if that is the case).

I'm really anxious to see this fixed ASAP.  But if we haven't convinced ourselves the performance impact is OK by this point (beta release) perhaps we should defer another milestone? 

I think we're pretty convinced that this is the right thing to do. The needs of the many out weigh the needs of the few prototype checks.

Excellent, glad to hear it!

[Jeremy Roman]

On Tue, Apr 14, 2015 at 1:18 PM, <thecm...@gmail.com> wrote:

This is awesome work! Glad to see this -- you'll make polyfill authors really happy :-)  Any chance we'll see something similar for methods like addEventListener/removeEventListener? I believe these are still defined on the instance in Blink.

I think they're defined on the prototype, aren't they?

> EventTarget.prototype.hasOwnProperty('addEventListener')

< true

> document.createElement('div').hasOwnProperty('addEventListener')

< false

[TAMURA, Kent]

Calling them "DOM attributes" is very confusing with DOM Attr.  I think "IDL attributes" is a better phrase.

Usually "DOM" means Document Object Model, which is a specification for Nodes and Events.  Calling all web-exposed objects "DOM" is not common.

On Tue, Apr 14, 2015 at 7:07 PM, 'Paul Kinlan' via blink-dev <blin...@chromium.org> wrote:

All, I have staged a version of our web developer guidance here: http://development.updaterocker.appspot.com/2015/04/DOM-attributes-now-on-the-prototype (some changes are still waiting to be deployed)

I am certainly open to feedback.  I haven't addressed performance issues in this post yet, but I am curious to work out how we message that we are slowing down Chrome for a version or two... (if that is the case).

--

TAMURA Kent
Software Engineer, Google

[Domenic Denicola]

I would suggest using “properties” (or perhaps “getters and setters”) since that is the JavaScript term. The idea of “attributes” meaning JavaScript properties seems to be something inherited from IDL’s CORBA days?

[Kentaro Hara]

In terms of the Web IDL spec, they are "attributes".

http://heycam.github.io/webidl/#idl-attributes

It is important to use the correct term in the spec, but it is also important to use a term web developers can easily understand. So I'm fine with "properties" as well.

[Elliott Sprehn]

On Tue, Apr 14, 2015 at 9:46 PM, Kentaro Hara <har...@chromium.org> wrote:

In terms of the Web IDL spec, they are "attributes".

http://heycam.github.io/webidl/#idl-attributes

It is important to use the correct term in the spec, but it is also important to use a term web developers can easily understand. So I'm fine with "properties" as well.

+1, authors talk about properties, browser engineers talk about attributes.

attribute means setAttribute to web authors.

[Paul Kinlan]

I am clarifying some of this now in the post.

[Simon Pieters]

On Tue, 14 Apr 2015 19:27:05 +0200, PhistucK <phis...@gmail.com> wrote:

> I am not sure this was intended, but the post is live -
> http://updates.html5rocks.com/2015/04/DOM-attributes-now-on-the-prototype

Paul, can you add links for "our (Chrome’s) issue tracker" and "WebKit
radar"?

> File an issue about the affected site on our (Chrome’s) issue tracker
> File an issue on WebKit radar and reference
> https://bugs.webkit.org/show_bug.cgi?id=49739

--
Simon Pieters
Opera Software