Re: Notes from Monday's meeting with TC39 folks

On Oct 7, 2009, at 11:46 PM, Brendan Eich wrote:

>
>
>>> 4. Something like ES5’s Appendix B
>>>   Not normative.  These would be advisory notes about things
>>>   implementations might want to do for compatibility, but it would  
>>> be
>>>   up to the implementor to determine whether it was required.  If
>>>   deemed required, then the implementor would follow the definitions
>>>   in this section (that is, it’s defined how to do it, but optional
>>>   whether it is required).  document.all falsey-ness was considered
>>>   to be in this category, although currently that behaviour is
>>>   specified in HTML5, not by virtue of any Web IDL feature.
>>
>> I don't like the idea of a non-normative appendix.
>
> This section is normative.

The first sentence above says "Not normative."

> It gives normative specs for optional features, so if  
> implementations support them (to risk chasing IE and win market  
> share, or lose by failing to emulate other IE unspecified features)  
> then they interoperate.
>
> Gecko is not going to support callable collections so these can go  
> here.

Web IDL just specifies the notion of callable interfaces, not callable  
collections per se. The right way to make callable collections  
optional would be at the HTML5 level. Better yet would be to remove  
them. We'd strongly consider doing it in WebKit if Microsoft was  
willing to remove them from IE in all modes.

>
>> Optional behaviors lead to interoperability problems and cause  
>> trouble for authors and implementors alike.
>
> The distinction is between required and optional feature. In both  
> cases there is a normative spec.
>
> I agree that options, profiles, and "levels" or "modes" create  
> complexity in which hide interop bugs, due to spec bugs or just  
> implementation bugs arising from the complexity.
>
> On the other hand, we do not intend to support callable collections  
> that WebKit and possibly Opera support, so either these don't get  
> any normative spec, or they get an optional one. The latter seems  
> better but I can live with the former.

Really the linchpin is IE/Trident supporting them. I think WebKit and  
Presto only support them only to chase IE compatibility. I'd much  
rather come to consensus on this than make it implementation-dependent.

>
>> I think it's a giant failure that ES5 takes this approach to  
>> anything - it's just a cheap way to maintain a smug sense of purity  
>> without actually serving interoperability of the Web platform.  
>> Interoperability is more important than wrinkling our noses at  
>> distasteful legacy.
>
> Fair enough, but bending current and future specs around legacy crap  
> is the yin to your yang. I think we have to keep both sides in mind  
> and strike a balance.

But failing to spec the bad stuff doesn't make it go away. It's the  
actual existence of legacy crap (in content and implementations) that  
constrains us, not its status as an implementation requirement. In  
fact, trying to design features without considering the impact of  
legacy implementation extensions can result in features that don't  
actually meet their intended goal. I recall some hard thinking to stop  
features that expose the call stack from breaking strict mode.

>
>> In the specific case of document falsey-ness, I think it should be  
>> mandatory, not optional (even though it is spec'd in HTML5, so this  
>> discussion doesn't really apply).
>
> You mean document.all falsyness? The way WebKit implements this  
> violates ECMA-262 (there's no exemption for a host object in  
> ToBoolean).

Indeed, and I think ECMAScript should be changed to allow document.all  
falsy-ness in some way. Would you claim the way Gecko implements it  
does not violate ECMA-262? (In tests I was unable to figure out a  
model of the Gecko behavior is.)

>
> Considering your finding fault with ES5 for HTML5 and ES5 still  
> conflicting over global code |this| binding (to something other than  
> the global object, namely WindowProxy per HTML5), I think you are  
> now in a glass house. Put down the stone. :-/

Huh? My position is that ES5 should be fixed on that score to conform  
to reality, and that an interoperable behavior should be normatively  
required. I don't see how this conflicts with my statement above. I  
also don't see how asking for specs to make things required instead of  
implementation-defined comprises casting of stones, in any case.

>
>>> 5. Things considered for standardisation but rejected, and why
>>>   Also not normative, and requirements wouldn’t be listed at all.
>>>   (Not sure if any features were deemed to be in this category.)
>>
>> Anything rejected for standardization shouldn't be mentioned in the  
>> spec.
>
> The Reject category is informative, for WebIDL users and would-be  
> extenders.

I don't think a spec needs to mention what's not in the spec. People  
already complain that it's too long. If this information is really  
valuable, we could publish it as a Note. That being said, I'm not sure  
there is anything really in this cateogry.

Regards,
Maciej