Re: [whatwg] WebIDL and HTML5

On Tue, Aug 26, 2008 at 1:04 PM, Andrew Oakley <andrew@ado.is-a-geek.net> wrote:
> Garrett Smith wrote:


>
>>> You can assign the Array methods to the NodeList prototype, they're
>>> generic.
>>>
> I'm going to take slice as an example here - lets say you wanted the first n
> nodes in a NodeList (no, I don't see how that would be useful, but lets
> pretend that it is).
>>

slice is often used for the purpose of creating a new Array based on
the NodeList.

Array.prototype.slice.call(nodeList);

- to obtain an array.

NodeList and Array are two separate beasts.

Array generics are useful, but provide mixed results in
implementations when using NodeList as the thisArg. For example:-

every, filter, forEach, reverse, some, sort, slice.

-only slice will work in IE and even that is now broken in IE8b1.

>> 2) NodeList is an interface and should not have any implementation.
>> Even in browsers that expose a NodeList object, it cannot be
>> guaranteed
>
> WebIDL is here to specify the behavior.  In ECMAScript there is no such
> thing as an interface, so WebIDL maps them to what it refers to as
> "interface objects" and "interface prototype objects".  It would seem
> reasonable that you cannot call functions on these objects directly, or that
> functions could appear further down the prototype chain than is implied by
> the IDL (as long as the function appears on all the relevant DOM objects).
>  In any case adding a new function should work if WebIDL has been followed.
>

EcmaScript doesn't have interfaces, but it does have objects.
Ducktyping is a common practice, and is why the Array generics are so
useful with NodeList (if IE had more robust Array methods). An
EcmaScript object that implements a dom interface would be provided by
the browser. The interface wouldn't have to be provided by the
browser. So, document.body should return an object that implements
Node, Element, HTMLBodyElement interfaces. There is no need for the
environment to modify those interfaces, and doing so could potentially
cause problems and make the web page less stable.

>> 3) You answered a question for which no need was demonstrated, and
>> provided no example.
>
> I could argue that there is no need for interactive web pages at all (they
> tend to annoy me), but we want to be flexible.
>
Businesses want to make rich, featureful software-as-a-service. It is
a common business model and is very useful.


>> javascript:try{ alert(Array.prototype.push.call(document.childNodes));
>> } catch(ex){alert(ex.message);}
>>
>> Should err out in step 7 of push attempting to set the "length" property.
>
> I believe length is read-only on a NodeList, and assigning to read-only
> members in ECMAScript fails silently.  So we should carry on regardless.

You are partially correct. The correct part is that assigning a value
to a native EcmaScript object property that has the attribute ReadOnly
will fail silently, as per Ecma-262 r3, 8.6.2.2 [[Put]](P, V)[1]. For
example:-

Math.max.length = 10;
Math.max.length;
=> 2

However, assigning to a readonly DOM property should raise a DOMException[2]*.

document.childNodes.length = 10;

Safari: No Error
Firefox: Error, setting a property that has only a getter.
Opera: DOMException: NO_MODIFICATION_ALLOWED
IE: I can't start windows :-(

Opera has the official standard behavior.

You are confusing DOM readonly and EcmaScript ReadOnly. These are not
the same ReadOnly.

* The one way to usurp that is in some cases for HTMLCollection, to
create a property with the name/id of the readonly property. For
example, to modify the length property of a form, create an element
with the name "length" and give it the value you desire. This is not
yet standard, but is implicitly specified in WF 2.0 WD, section 7.1.
This fails in Firefox. It is my opinion that it is a bad feature.

>>
>> Modifying host objects is a very bad idea. NodeList is an Interface.
>> An interface should have no implementation. Even if you really wanted
>> to follow Ian's advice, it wouldn't work.
>>
>
> OK, I'll agree that in general its a bad idea, and all hell breaks loose if
> you have multiple windows.  But it should be specified in WebIDL, and if the
> document implies that it should work (which it does) and it is not a
> requirement for it to work, then it should say so (and preferably explain
> why).
>

Granting programs access to native interfaces makes the program less
stable. It also changes the meaning of the word interface to mean
something that I don't know what it is. For example, an Interface
cannot have a constructor, yet in WebIDL[4]:-

| An ECMAScript implementation supporting these interfaces
| would have a [[Construct]] property on the Circle interface
| object which would return a new object that implements the
| interface.

- defines a type of interface that implements [[Construct]].

Interfaces are used to describe objects. They should be flexible. They
should not provide any implementation. An object can be defined to
implement many interfaces and should not have any one of those
interfaces be a "constructor".

Garrett

[1] Ecma-262 r3
http://www.ecma-international.org/publications/standards/Ecma-262.htm
[1] DOM Core IDL Definitions
http://www.w3.org/TR/DOM-Level-2-Core/idl-definitions.html
[3] Web Forms 2.0
http://www.whatwg.org/specs/web-forms/current-work/
[4] WebIDL, Constructor
http://dev.w3.org/2006/webapi/WebIDL/#Constructor

Received on Tuesday, 26 August 2008 23:20:43 UTC