[whatwg] HTML 5 : Misconceptions Documented

On Wed, Aug 6, 2008 at 7:03 PM, Maciej Stachowiak <mjs at apple.com> wrote:
>
> On Aug 6, 2008, at 11:23 AM, Garrett Smith wrote:
>
>>
>> My apologies for being rude.
>>
>> What would you suggest, Maciej?
>
> I would suggest:
>
> a) Point out mistakes courteously.

Done.

> b) Preferably do so in the appropriate public forum where others can see
> them (I don't see any mail from you on this topic in public-webapps).

Sorry, it was public-html, not webapi.

> c) Assume good faith on the part of the editor, even if you do not receive
> an immediate reply.
>

I'll do my best.

>> If Cameron McCormick ignores constructive criticism for three weeks,
>> what's to say he'll won't ignore it another three weeks and then
>> forget about it altogether?
>
> Because he has a track record of responding to feedback
>

These things often change and develop very quickly. Two weeks seems
like long enough. Should it be four?


>> I tried to elicit a response by providing test cases and through
>> constructive criticism.
>>
>> The longer that document stays up there in its current form, the
>> greater the chance that someone will come along and write a book or
>> blog about this and teach those who are less knowledgeable, and pretty
>> soon, it starts appearing as a 'bug' on webbugtrack and filed as a bug
>> against IE. It has happened before. I can see on the JScript blog
>> right now, a bug that is not a bug, filed against IE, and comments
>> from the JScript team about how they will "fix" it.
>
> This lacks all sense of proportion. No one expects a W3C Working Draft to be
> technically correct in all details,

I ask that the standards docs are based on tests and facts; examples
at the very least. I don't think its too much to ask. I don't agree
with the mentality you ascribe to: just add [x] to the document. It is
careless. It is harmful. And, I think it is arrogant.

In fact, browser vendors do implement stuff in working Drafts. For
example, look at the CSSOM disaster that Anne cooked up. I can find
bugs right now on connect.microsoft.com, regarding that spec and I can
observe changed behavior in IE8b1 that closely matches that spec,
deviating from MSIE 7. We have a Working Draft that got adopted
without ever becoming a Technical Recommendation.

> and browser vendors and authors of books
> in particular know to test things

LOL.

What book authors are you talking about?

> and not rely on specs, and to look at the
> maturity level of documents. I would hasten to add that the mistake they'd
> make based on this (that '0' in HTMLCollection might be false when it is in
> fact true) is an error that would have almost no effect on anyone in
> practice.
>
> While pointing out technical errors in specifications is extremely valuable,
> please do not assume that just because you found it, it must become the most
> important thing in the world for the editor.
>

The inference here is that I found something, then, I decided that it
would become the most important thing in the world of the editor.

The only way you could make such inferences is if you read my mind,
right? So, let's have an example of that. Why don't you tell me what
I'm thinking right now, Maciej?


>> # No Indexed Property
>
> [[IndexGetter]] is a spec fiction,

I think I agree with that, it exists in the spec; it is fiction.

> as is the notion of whether something
> "has" a property. What is observable is the effects of getting the property,
> hasOwnProperty, in, and attempts to delete or put the property. If you
> describe things in those terms it will be easier to know what you mean.
>

If you ask a specific question using that terminology, I'll try and
answer it. If I don't have an answer, I'll say "I don't know".

Or post up some examples. That would be great.

>>
>> For example:
>>
>> <body id='test'>
>> <script>
>> alert('id' in document.body.attributes)
>> </script>
>> </body>
>>
>> alerts "false" in FF3 and Saf2 (but 'true' in Saf3).
>
> It probably doesn't matter which behavior is chosen on this, since it is
> such an unlikey thing to do, but better to choose one. And better for such
> things to be consistent if possible.
>

An example would show that IE doesn't support getters.

Creating a bug for IE where a good cross-browser solution exists would
seem unethical.

The indexed items could be specified to be a property, which is more
consistent in implementations.

It could be left to an implementation detail.


>>
>>> I think Web IDL should provide a formalism to cater to this, because
>>> nearly
>>> all bindings with special dynamic properties work like this afaik. But I
>>> think it would have to involve a pseudo-method for the "hasOwnProperty"
>>> check (which "in" is based on).
>>>
>>
>> WRONG.
>>
>> The 'in' operator is based on the [[HasProperty]], not "hasOwnProperty"
>
> First of all, [[HasProperty]] is often implemented in terms of
> hasOwnProperty, since it cannot return true unless hasOwnProperty does for
> some element of the prototype chain. Second, how could this distinction
> possibly make a difference in this case?

You're discussing an implementation detail. Saying that the 'in'
operator uses hasOwnProperty is dead wrong. Rather than apologize, you
decided to try and defend your position. You, of all people on this
list, should be very careful not to mislead others about this topic.
You're probably one who could considered an expert on this topic.

> If the property is an own property,
> then there is no operational difference between [[HasProperty]] and
> hasOwnProperty. Thus, your all-caps "WRONG" seems a little over the top.
>

There would be a difference. The difference would be that
hasOwnProperty is a method in EcmaScript, 'in' is an operator. Just
launch Opera and try this:

<body id='x'>
<script>
alert(({}).hasOwnProperty.call(document.body, 'id'));
alert(({}).hasOwnProperty.call(document.body.attributes, 'id'));
</script>
</body>


and we can see 'false' twice.

That is a bug in Opera.

Opera has a different implementation than Webkit.

But the point is not to confuse others by saying that the in operator
calls 'hasOwnProperty' whatever implementation details exists in your
implementation don't necessarily exist in another.

As far as IDL goes, it seems like a bad idea to specify a property
being added to that object.

In Java, - 0 - would be an illegal identifier. It would be possible to
use Array access in Java, but HTMLCollection, NamedNodeMap, et c
aren't Arrays. There already exists the item() method. The need for
specifying an EcmaScript binding shortcut in ID hasn't been
demonstrated.

The phenomenon we're talking about is non-standardized property-access
that returns a property on an object.

Could this be a note in the EcmaScript Bindings?


Garrett

> Regards,
> Maciej

Received on Wednesday, 6 August 2008 20:20:10 UTC