this will change too ?
`NodeList.prototype.propertyIsEnumerable('length')`

WebIDL is full of inconsistencies compared with JS world and that, talking
about backward compatibility, shouldn't change.

Prototypal inheritance done the old JS way works perfectly and everything
is enumerable.
I rewrite the example you apparently ignored:

```js

var HTMLDivElement = new WebIDL({
  yourDefinitionAsObject() {
  },
  get properties() {
  },
  attributeName: 'value'
});

```

That is just fine as everything enumerable, that is just fine as Interface
definition.

Why should IDL make classes bad for everything in JS land instead of
adopting above pattern in case it does not want to go enumerable?

And again, who actually wants that enumerability and why?

Best Regards



On Fri, Jan 30, 2015 at 10:52 AM, Anne van Kesteren <annevk at annevk.nl>
wrote:

> On Fri, Jan 30, 2015 at 7:44 AM, Andrea Giammarchi
> <andrea.giammarchi at gmail.com> wrote:
> > Developers have to understand they cannot `new HTMLDivElement()` anyway
> and
> > they cannot extend WebIDL interfaces in JS world neither.
>
> That will change.
>
> bz and others have been working on bridging the gap for quite a while
> now. It's rather frustrating TC39 keeps ignoring the feedback given
> while at the same time complaining that DOM and IDL are so different.
>
>
> --
> https://annevankesteren.nl/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20150130/b30f04e4/attachment.html>

this will change too ?
`NodeList.prototype.propertyIsEnumerable('length')`

WebIDL is full of inconsistencies compared with JS world and that, talking
about backward compatibility, shouldn't change.

Prototypal inheritance done the old JS way works perfectly and everything
is enumerable.
I rewrite the example you apparently ignored:

```js

var HTMLDivElement = new WebIDL({
  yourDefinitionAsObject() {
  },
  get properties() {
  },
  attributeName: 'value'
});

```

That is just fine as everything enumerable, that is just fine as Interface
definition.

Why should IDL make classes bad for everything in JS land instead of
adopting above pattern in case it does not want to go enumerable?

And again, who actually wants that enumerability and why?