W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2009

Re: Web IDL Garden Hose (was: ECMA TC 39 / W3C HTML and WebApps WG coordination)

From: Yehuda Katz <wycats@gmail.com>
Date: Fri, 25 Sep 2009 23:20:18 -0700
Message-ID: <245fb4700909252320t54368417k5691007cb3b47e67@mail.gmail.com>
To: Brendan Eich <brendan@mozilla.com>
Cc: Doug Schepers <schepers@w3.org>, public-webapps@w3.org, HTML WG <public-html@w3.org>, es-discuss <es-discuss@mozilla.org>
On Fri, Sep 25, 2009 at 11:15 PM, Brendan Eich <brendan@mozilla.com> wrote:
> On Sep 25, 2009, at 9:38 PM, Yehuda Katz wrote:
>
> Another way to put my earlier concern
>
> Sorry, what earlier concern? You are replying to my reply to Doug Schepers
> on a sub-thread where I didn't see a message from you.

So confusing! So many messages!

>
> is: It's impossible to write a
> conforming JS engine that browsers will want to use by only following
> the ES spec - since there's additional, un-speced, behavior that isn't
> in ES that is necessary in order to construct a browser's DOM.
>
> This is a problem to fix. No one is arguing that it's not a problem. What's
> the real topic?

The *real* problem is that for people who are not implementing this
stuff, it is extremely difficult to track down and piece together all
of the semantics. It would seem reasonable to go look at the
ECMAScript spec to understand ECMAScript semantics, but as it turns
out, it's also necessary to read HTML5 and WebIDL. I have no objection
to needing to read the HTML5 spec to understand how the *DOM* works. I
object to having to read HTML5 to understand how ECMAScript works
(which is currently necessary).

> Consider the following scenario: I write an ECMAScript engine that is
> significantly faster than any existing engine by simply following the
> ECMAScript spec. A browser maker then wishes to use this engine. This
> would be impossible without adding additional (hidden) features to the
> engine to support the DOM. There is nothing in the ECMAScript spec
> that requires the ability (at the very least) to add native extensions
> with arbitrary behavior to the engine.
>
> The ES spec allows extensions, but it cannot require them without the
> extensions being no longer extensions in any sense, rather as specified
> parts of the normative core language. Again I don't know what your point
> here is.

My point is that understanding the semantics of the language as
implemented by browser vendors is not possible by reading the language
spec. These is not some hypothetical extension, but a mandatory way
that ECMAScript implemented for the web must behave.

> Is this a requirement ECMA is comfortable with?
>
> What requirement? Your scenario? I have no idea where it came from, but it
> doesn't follow from anything you cited (cited again below).
> If you mean we need to specify multiple globals, split windows, execution
> model, etc. -- that's what I've been saying on the main thread since the
> first message, and what Sam's transcription of a private message from me
> tried to say.
> Still not sure what your point is,
> /be

I'm sorry.

>
> -- Yehuda
>
> On Thu, Sep 24, 2009 at 3:19 PM, Brendan Eich <brendan@mozilla.com> wrote:
>
> On Sep 24, 2009, at 2:43 PM, Doug Schepers wrote:
>
> [much appreciated information snipped -- thanks!]
>
> I really don't see how the review process and accountability could be much
>
> more open for the development of Web IDL elsewhere, nor is the burden on
>
> reviewers that large... it would simply be one more low-traffic mailing
>
> list.  Are there other barriers you see?
>
> I alluded to employers who are not currently paying W3C members not wanting
>
> their employees participating, even individually. I'll let one notable
>
> example that I know of speak for himself.
>
> The "mailing list as firehose" problem can be solved with enough work, but
>
> with two standards groups there is always greater risk of conflict, and just
>
> competition for attention. Two lists is simply one more list than one list
>
> to keep up with.
>
> This is a price of collaboration at wider scale, so don't let me stand in
>
> the way, since I've been explicit about being in favor of collaboration.
>
> W3C and Ecma both have transparency issues, but I don't expect those to be
>
> fixed easily. I mentioned them ("People in dark-glass houses ... [should not
>
> throw stones]") in reply to Maciej asserting greater openness on one side.
>
> Again this is not a "barrier" I'm trying to take down right now.
>
> /be
>
> _______________________________________________
>
> es-discuss mailing list
>
> es-discuss@mozilla.org
>
> https://mail.mozilla.org/listinfo/es-discuss
>
>
>
>
> --
> Yehuda Katz
> Developer | Engine Yard
> (ph) 718.877.1325
>
>



-- 
Yehuda Katz
Developer | Engine Yard
(ph) 718.877.1325
Received on Saturday, 26 September 2009 06:21:26 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:33 GMT