Re: ISSUE-148 (modularize d3e): Consider modularizing DOM3 Events [DOM3 Events]

On 11/3/10, Doug Schepers <schepers@w3.org> wrote:
> Hi, Garrett-
>
> We discussed this in a teleconference, and again at the WebApps WG
> face-to-face meeting at TPAC (W3C's tech plenary) [1].  Anne van
> Kesteren from Opera, the new editor of Web DOM Core, represented the
> viewpoint of modularizing DOM3 Events.
>

The endorsement of the idea for modularization isn't supported by any
reasoned argument. That doesn't mean that no reasonable argument could
be made, however unreasoned argument can be and should be and was shot
down.

It looks like the argument wasn't presented well and if you read over
it and then contrast to what was carefully thought out and written by
myself, Sergey Illinsky, Charles Pritchard. The arguments we mentioned
didn't come up there; there was no talk of keyboard events.

There was a brief endorsement,
|  shepazu: wansts to modularize
|
|    … and Anne wants to modularize more too


And then there was brief mention about mutation events and then:

| mjs: my preference would be to move forward but plan [to move things
|    to DOM Core later]
|
|    smaug_: I agree
|
|    … let's get DOM3 Events done now

Yes, right now.

Sounds like implementors want a spec right now. Of course, and why
would they want otherwise?

But what about looking just past right now? Are there longer-term
(permanent) ramifications of D3E being published as-is? D3E is not
cohesive, not modular, and all the mistakes that have been made with
it are causing it to take longer.

What does it take to appreciate what happens when an API is published?

Some of the more specific functionality in D3E has problems and many
of these have been mentioned.. However the whole spec is a ball of
mud. I'd rather not be optimistic and say to do a good job or make
some improvements in various places. It's too big and bloated to
tackle like that.  Get it organized. Divide and conquer, not the other
way around.

> I understand and agree with the goals of modularization, but there are
> also other goals that modularization makes more difficult;

What are they?

it's always a
> judgment call in deciding which spec covers which functionality.
>
> Anne specifically advocated splitting out parts of DOM3 Events and
> putting them instead into Web DOM Core, but the general tenor of the
> majority of browser vendors expressed a desire to finalize DOM3 Events,
> and did not feel that the benefits of modularizing or otherwise
> reorganizing the spec outweighed the benefits of finalizing this spec

"just get it done" -- sounds like panic mode.

<http://www.w3.org/2008/webapps/track/issues/1>

> with the set of features currently defined.  So, we have resolved not to
> modularize the spec in the way you have suggested.
>

For any other reason that the vendors want something right now? And
how does not modularizing speed things up?

I think the API design matters. How easily can the API of a published
TR be changed or modified at a later date? In the discussion you've
linked, I don't see any proposal for modularity, no rationale, nor any
plan of attack, not for now, not for later.

> This is not to say that this may not be revisited in a later DOM spec,
> such as Web DOM Core.
>

The more components that change in any release of a package, the
greater the work to rebuild, test, and deploy the release. Work takes
time. I heard mention that the spec is late, (and not to beat a dead
horse, but again, issue 1). The spec has grown as things have been
realized. Grown too much. I am not surprised that lumping all of that
functionality  together (and *geting it done right now*) does not save
time and effort.

> Please let us know whether or not you are satisfied with this resolution.
>

Doesn't sound like a very reasonable solution. I can't think of
anything else on the matter that hasn't already been ignored,
misunderstood, top-posted over, etc.

> [1] http://lists.w3.org/Archives/Public/public-webapps/2010OctDec/0430.html
>
>
> Regards-
> -Doug Schepers
> W3C Team Contact, SVG, WebApps, and Web Events WGs
>
>
> Web Applications Working Group Issue Tracker wrote (on 10/6/10 8:58 AM):
>>
>> ISSUE-148 (modularize d3e): Consider modularizing DOM3 Events [DOM3
>> Events]
>>
>> http://www.w3.org/2008/webapps/track/issues/148
>>
>> Raised by: Doug Schepers
>> On product: DOM3 Events
>>
>> Garrett Smith
>> in<http://lists.w3.org/Archives/Public/www-dom/2010OctDec/0003.html>:
>> [[
>> I think we're all well aware of the monstrosity that has become D3E.
>>
>> D3E should be cut way back; it is too large and too complicated.
>> Individual events and keyboard specificity are not "core" features;
>> they are details and particulars of specific events. These events
>> should be moved each to a separate specification.
>>
>> Moving specific event specification details to independent
>> specifications will help reveal the real "core" of DOM 3 Events; so
>> that core can be looked at more closely and independently questioned;
>> e.g. "should useCapture be optional" and ditto for the extracted/moved
>> event "Should we specify keyCode and charCode".
>>
>> To put this idea to action, I suggest starting with the a complicated
>> part of the spec that seems the least core. For example, keyboard
>> events, which itself is about 30 pages long. I would extract that from
>> the spec and move it to another document and see how it reads on its
>> own.
>>
>> If further help is wanted, then a request can be made for an associate
>> editor.
>> ]]
>>
>
>

Received on Wednesday, 10 November 2010 08:20:07 UTC