- From: Maciej Stachowiak <mjs@apple.com>
- Date: Fri, 06 Nov 2009 01:11:23 -0800
- To: Travis Leithead <travil@microsoft.com>
- 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>
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