W3C home > Mailing lists > Public > public-script-coord@w3.org > October to December 2009

Re: Possible Agenda items for Joint TC39/WebApps WG meeting

From: Maciej Stachowiak <mjs@apple.com>
Date: Fri, 06 Nov 2009 01:11:23 -0800
Cc: "public-script-coord@w3.org" <public-script-coord@w3.org>, "Mark S. Miller (erights@google.com)" <erights@google.com>, Allen Wirfs-Brock <Allen.Wirfs-Brock@microsoft.com>, Paul Cotton <Paul.Cotton@microsoft.com>, Sam Weinig <weinig@apple.com>
Message-id: <DC72B287-DDAD-41A2-B3F1-6ADE9707E2A4@apple.com>
To: Travis Leithead <travil@microsoft.com>

On Nov 5, 2009, at 11:03 PM, Travis Leithead wrote:

> I thought I’d put together the short list of possible agenda items  
> for tomorrow’s joint meeting. This could be a place to start our  
> discussion from. Some of these have been re-curring discussions of  
> late, a few of these are taken from the mailing list, others have  
> simply been on my mind recently.

Seems like a decent agenda. I am not entirely happy with the framing  
of one item:

>
> 1.
> "It's not your job" -> specing ECMAScript language features by non- 
> ECMAScript folks
> * GOALS: Discuss possible process changes, how to get review (or  
> have TC-39 folks author) any language features needed for legacy  
> browser support.
> * GOALS: Not desiring to spec new language features of ECMAScript,  
> just pieces required for legacy browser support.

Let's focus on the collaboration aspect and set the potential turf  
wars aside. Keep in mind that the keen interest of the folks working  
on ECMAScript in the details of Web platform APIs is a relatively  
recent thing. ECMAScript specs have always provided for host objects  
so these details could be defined from the outside. And so maybe it's  
a little presumptuous and needlessly combative to tell the people who  
have worked on specifying the details thereof that it's "not [their]  
job".

I think a more neutral and collaborative way to state the goals here  
would be like this:

"Over the long run, the behavior of Web platform host objects should  
converge with what is possible to implement in pure ECMAScript. This  
can be achieved by exercising care in introducing new kinds of Web  
platform behavior, and by extending the ECMAScript language over time.  
Web IDL can be a focal point for this convergence, by limiting the  
introduction of new kinds of host object behavior, and by identifying  
behavior that is required for the Web platform but not yet possible in  
ECMAScript."


>
> 2.
> WebIDL syntax considerations
> * Method overloads vs. union types for functions - General focus on  
> EMCAScript binding vs. JavaBinding syntax
>
> 3.
> Standardizing "Mistakes" (or how to organize the spec to make legacy  
> stuff legacy only)
> * ISSUE: 'caller' syntax
> * ISSUE: creator/deletor?
> * more?
>
> 4.
> Object catchAlls and related issues
> * catchalls and the prototype chain--mixed appraoches in WebIDL  
> necessary?
> * preventExtensions() on DOM collections?
>
> 5.
> New Data Types for W3C Specs in ECMAScript bindings
> * GOALS: Discuss a convenient way to have byte arrays (i.e., "data"  
> in general) represented in W3C specs (File API
> spec) and ECMAScript itself.
> * Binary Data Proposal: http://lists.w3.org/Archives/Public/public-script-coord/2009OctDec/0093.html
>
> Other topics:
> ES5 concepts on DOM objects: accessor or data properties?
Received on Friday, 6 November 2009 09:12:04 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 8 May 2013 19:30:02 UTC