[whatwg] HTML 5 : Misconceptions Documented

On Thu, Aug 7, 2008 at 4:37 PM, Maciej Stachowiak <mjs at apple.com> wrote:
>
> On Aug 7, 2008, at 3:44 PM, Garrett Smith wrote:
>

I'd like to put this back on the list, and it doesn't contain anything
personal, so I'm taking the liberty here.
>
> I'm not sure what you mean by "in the binding".

I meant the EcmaScript binding.

> Do you mean in Web IDL's
> definition of how to map Web IDL interfaces to the ECMAScript language, or
> one-off in the HTML5 spec for every interface this applies to?

Narrowing the scope in the interest of not creating bugs seems like a
very good idea.

This could potentially be described in the EcmaScript bindings. But it
would be a good idea to explore some edge cases. Particularly, if the
case was the order of definition of properties: One such case would be
an HTMLCollection with an element named "length". In that case, the
readonly "length" property would have to be the actual length of the
collection; the value should not be replaced with an element of that
name/id.

<form><input name="length"></form>

document.forms[0].elements.length

Opera9: [object HTMLInputElement] <-- BUG
FF3: 1
Saf3: 1

Another consideration would be a form element with an attribute
"length". That would be a problem as neither the attribute, nor the
Netscape 4 DOM "named items" are specified as "readonly". So that's
one reason for not specifying the Netscape 4 DOM and for removing that
example from WF 2.0
http://www.whatwg.org/specs/web-forms/current-work/#select-check-default

>
> I think the Web IDL spec should correctly define how to map Web IDL to
> ECMAScript, while not precluding the possibility of mapping to other
> languages.

It's a good idea to understand what is happening in the language we're
concerned with: EcmaScript implementations (browsers) are where the
phenomenon was noticed and from where the concern was raised.

Aren't [IndexGetter] and [ NameGetter] are really doing the same thing
in most cases?

Why differentiate between "number" properties and "name" properties?

Is "added as properties" an accurate description?

For example:
For each item in the collection object, a corresponsding property is
present on that object. The property's name is the ordinal index and
the value is the result of calling the collection's item() method.

>From the Web IDL WD:
http://dev.w3.org/2006/webapi/WebIDL/#IndexGetter

| An ECMAScript implementation would have an internal [[Get]]
| method that allows values to be retrieved from the  map as
| properties, and a corresponding [[Put]] method for setting values
| in the map:
| ECMAScript
|
|  // Assume map is a host object implementing
| //  the OrderedMap interface.
| var map = getOrderedMap();
| var x, y;
|
| x = map[0];                 // Same as: x = map.getByIndex(0)
| map[1] = false;             // Same as: map.setByIndex(1, false)
|
| y = map.apple;              // Same as: y = map.get('apple')
| map.banana = 123;           // Same as: map.set('banana', 123)
`------------------------------------------------------------------

It seems that the expectation is that [[Get]] will differentiate
between and typecheck the Expression. This is not how property access
works. In the above, the Expression in map[0] is 0. This 0 is
converted to the string "0".

| The production MemberExpression :
| MemberExpression [ Expression  ] is evaluated as follows:
|
| 1. Evaluate MemberExpression.
| 2. Call GetValue(Result(1)).
| 3. Evaluate Expression.
| 4. Call GetValue(Result(3)).
| 5. Call ToObject(Result(2)).
| 6. Call ToString(Result(4)).

In step 4., we call GetValue(Result(3)

| 8.7.1 GetValue(V)
|
|  4.. If Type(V) is not Reference, return V.

Type V is not a reference, it is a Number, 0, so 0 is returned to
property access algorithm step 4. In step 6, property access calls
ToString(Result(4)),

| 9.8.1 ToString Applied to the Number Type

This is a little involved, and includes exponential notation, but the
result of ToString(0), will be "0",

map[0] has the same effect as map["0"].

I don't know if any other languages have this functionality.

Now the same cannot be said for [[Put]] because Arrays have a special
[[Put]] method that does do some checking on the Expression. Array's
[[Put]] can change the length of the Array, or, if the property name
is 'length', can cause indexed properties to be deleted. Special
[[Put]] functionality might apply to the HTMLSelectElement, which in
all browsers will create/remove options when the length is changed.
However, a "[NameSetter]"  seems over the top.
http://dev.w3.org/2006/webapi/WebIDL/#NameSetter

<!DOCTYPE HTML>
<html lang="en">
<head>
    <title>Magic-Select [[Put]]</title>
</head>
<body>
<form><select name=aaa></select></form>
<script>
var a = document.forms[0].elements.aaa;
a.length = 12
a.options[3].text = "pass";
a.selectedIndex = 3;
</script>
</body>
</html>

Wouldn't it be better to just have a simple note in the HTML 5 spec
what happens when a Select's length property is set?

Garrett

> This may include hints that are relevant to ECMAScript but not
> for most other language bindings. Indeed [IndexGetter] is such a hint, and
> the Web IDL spec includes other aspects of IDL markup that would affect
> ECMAScript but have no effect on Java. If you look at the Web IDL spec you
> will see that general issues are well-separated from the ECMAScript language
> mapping for Web IDL.
>
> Regards,
> Maciej
>
>

Received on Friday, 8 August 2008 17:05:47 UTC