- From: Garrett Smith <dhtmlkitchen@gmail.com>
- Date: Wed, 10 Nov 2010 00:19:30 -0800
- To: Doug Schepers <schepers@w3.org>
- Cc: "www-dom@w3.org" <www-dom@w3.org>, Sergey Ilinsky <castonet@yahoo.co.uk>
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