Re: publish a new Working Draft of DOM Core; comment deadline March 2
On Wed, 02 Mar 2011 06:10:47 +0100, Garrett Smith dhtmlkitc...@gmail.com wrote: On 3/1/11, Anne van Kesteren ann...@opera.com wrote: These are the reasons they are intertwined: * document.createEvent() That was previously DocumentEvent interface, IIRC. Implementations put it on Document instead. And of course we could then still define it in a separate document (we are planning to introduce extends or some such for that), but it is more convenient to not do so. * mutation events Why can't those be defined independently in Events. (not a fan of mutation events, BTW). Nobody is a fan. They are dispatched directly as the result of method invocation and in some cases can even effect what exception the method needs to throw (as I understand it). So they are highly intertwined and defining them separately is not a good idea. * we want Node to inherit from EventTarget That can be stated in DOM Core. For example: The Node Interface implements EventTarget [Events Core]. Implements is different from inheritance. Again though, yes that would not require Events to be in the same document, it is just more convenient. * both events and documents depend on the same tree concept How do XHR events or progress events depend on tree concept? Indexed DB does. Not everything does, of course. * INVALID_STATE_ERR is shared XHR and Event instances can have invalid states, but should those exceptions to have the same name and numerical representation? That is the convention we have used thus far, yes (not just for XMLHttpRequest). I doubt we will change that at this point. [...] I noticed that the DOM Core spec uses throw instead of raise. I don't mind the change but it might be something that matters for IDL formalism. This will probably converge over time. -- Anne van Kesteren http://annevankesteren.nl/
Re: publish a new Working Draft of DOM Core; comment deadline March 2
On Thu, 03 Mar 2011 04:43:04 +0100, Shiki Okasaka
shiki.okas...@gmail.com wrote:
I guess the reason behind this has been discussed around:
http://lists.w3.org/Archives/Public/public-script-coord/2010OctDec/0081.html
Actually what are the blocking issues why DOM Core does not state like,
interface EventTarget {
...
};
interface Node : EventTarget ...
yet?
None, I think, so done:
https://bitbucket.org/ms2ger/dom-core/changeset/5a0331350bed
Thanks!
--
Anne van Kesteren
http://annevankesteren.nl/
Re: publish a new Working Draft of DOM Core; comment deadline March 2
* we want Node to inherit from EventTarget
That can be stated in DOM Core. For example: The Node Interface
implements EventTarget [Events Core].
I guess the reason behind this has been discussed around:
http://lists.w3.org/Archives/Public/public-script-coord/2010OctDec/0081.html
Actually what are the blocking issues why DOM Core does not state like,
interface EventTarget {
...
};
interface Node : EventTarget ...
yet?
Best,
- Shiki
Re: publish a new Working Draft of DOM Core; comment deadline March 2
2011/3/3 Garrett Smith dhtmlkitc...@gmail.com: On 3/2/11, Shiki Okasaka shiki.okas...@gmail.com wrote: * we want Node to inherit from EventTarget That can be stated in DOM Core. For example: The Node Interface implements EventTarget [Events Core]. I guess the reason behind this has been discussed around: What is the reason behind what? Totally lost me on that one. Sorry about the confusion; I wanted to clarify inherits and implements are going to mean different things in Web IDL. http://lists.w3.org/Archives/Public/public-script-coord/2010OctDec/0081.html
Re: publish a new Working Draft of DOM Core; comment deadline March 2
On Sat, 26 Feb 2011 16:15:25 +0100, Doug Schepers schep...@w3.org wrote: I will remove my objection to publish DOM Core if: 1) conflicts (rather than extensions) are removed from the draft, or reconciled with changes in DOM3 Events; and 2) for those changes that have broad consensus, we can integrate them into DOM3 Events, which means that the changes should be sent as comments on DOM3 Events, to be discussed by the group and their current status determined. I am fine with raising issues to be discussed (and I am planning on doing so), but do we really need to resolve them before proceeding with publication? Is having a clear warning at the start of the Events section not sufficient, as Adrian suggested? I had previously started a DOM Core 4 draft specification, but when Anne and others volunteered to do Web DOM Core, I moved aside to let them work, and volunteered to help with that draft; Actually, before you worked on that Simon Pieters wrote fair bit of Web DOM Core (now DOM Core). Then Geoffrey Sneddon. Then Ms2ger. And only then I started helping out. I would still like to help edit that specification, to bring a slightly different perspective and approach, and to coordinate between DOM3 Events and DOM Core, and I believe we can edit the spec together amicably and productively. Do you have a bitbucket.org account? Ms2ger and I use https://bitbucket.org/ms2ger/dom-core as our primary repository. We typically coordinate editorial ideas in #whatwg and for them we also do commit first, then review every so often. Changes to existing features are brought up for discussion on public-webapps@w3.org, usually after we sanity checked them with each other. So far we have avoided adding new features as we would like to first reach some kind of stability with the current DOM implementations. If this all works for you I think it can work out. I have not run this by Ms2ger though I suspect he will agree. To be frank I am a little skeptical given our strained relationship to date, but I am willing to give it a try. Kind regards, -- Anne van Kesteren http://annevankesteren.nl/
Re: publish a new Working Draft of DOM Core; comment deadline March 2
On Mon, 28 Feb 2011 17:59:45 +0100, Adrian Bateman adria...@microsoft.com wrote: Something boxed out at the start of the Events section would be great for now. Added: https://bitbucket.org/ms2ger/dom-core/changeset/a997dac35d91 Hopefully we can make sure that the drafts are aligned and if the new DOM Core spec picks up where DOM L3 Events leaves off then that might be an helpful outcome. Since you keep bringing this up I thought I should clarify that the emphasis of DOM Core is not on new features. It is about a better definition of the DOM that better reflects reality and is more in line with specifications written from scratch in the last couple of years, such as HTML5, XMLHttpRequest, etc. Regardless of that (potential) misunderstanding, it is much appreciated we could work this out. Kind regards, -- Anne van Kesteren http://annevankesteren.nl/
Re: publish a new Working Draft of DOM Core; comment deadline March 2
On Tue, 01 Mar 2011 08:51:24 +0100, Maciej Stachowiak m...@apple.com wrote: What conflicts or contradictions exist currently? Does anyone have a list? Some time ago I put a list in the draft: http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#dom-events Glenn Maynard and I are still researching the last bullet point. It seems there are a variety of options there each with their own implications (oh, and current browsers do not really agree). Hopefully I will get to that soon. Doug, should I open a thread for each of these on www-...@w3.org? What about http://www.w3.org/TR/DOM-Level-3-Events/#events-event-type-eventPhase not being defined for this scenario: var e = document.createEvent(Event); alert(e.eventPhase);? There is quite a few of those undefined issues. Are they conflicts or extensions of DOM Core? -- Anne van Kesteren http://annevankesteren.nl/
Re: publish a new Working Draft of DOM Core; comment deadline March 2
On Mon, 28 Feb 2011 18:49:48 +0100, Garrett Smith dhtmlkitc...@gmail.com wrote: | DOM Core defines the event and document model the Web platform uses. That says that DOM Core defines two different things: events and DOM. Some things might implement DOM Events Core (or a subinterface thereof) but are unrelated to the DOM. Like XHR. Could Events Core exist on its own? (You could make DOM Core conformance require Events Core conformance). These are the reasons they are intertwined: * document.createEvent() * mutation events * we want Node to inherit from EventTarget * both events and documents depend on the same tree concept * INVALID_STATE_ERR is shared Of course, given a mutual dependency they could be split, but I do not really see the point. Should the Exceptions section be split out too in your opinion? Given that Events and Exceptions are quite short and per the above summary quite integral to how everything fits together I think the current division makes sense. -- Anne van Kesteren http://annevankesteren.nl/
Re: publish a new Working Draft of DOM Core; comment deadline March 2
On Tue, 1 Mar 2011, Anne van Kesteren wrote: On Sat, 26 Feb 2011 16:15:25 +0100, Doug Schepers schep...@w3.org wrote: I would still like to help edit that specification, to bring a slightly different perspective and approach, and to coordinate between DOM3 Events and DOM Core, and I believe we can edit the spec together amicably and productively. Do you have a bitbucket.org account? Ms2ger and I use https://bitbucket.org/ms2ger/dom-core as our primary repository. We typically coordinate editorial ideas in #whatwg and for them we also do commit first, then review every so often. Changes to existing features are brought up for discussion on public-webapps@w3.org, usually after we sanity checked them with each other. So far we have avoided adding new features as we would like to first reach some kind of stability with the current DOM implementations. If this all works for you I think it can work out. I have not run this by Ms2ger though I suspect he will agree. To be frank I am a little skeptical given our strained relationship to date, but I am willing to give it a try. I don't know if this helps, but for what it's worth, one thing that still needs defining and that is partly defined in the DOM 3 Events work that Doug has worked on but is not, and probably should not be, defined in the DOM Core work, is interaction events. That is, defining the exact order of operations when a user clicks their mouse: how the target is picked (especially given weird cases like table cells and border-collapse, or SVG with pointer-events), what the various MouseEvent interfaces should be, all the stuff with key events that we've avoided defining for years, what events should be fired for joysticks, etc. This is critical work that really needs a serious effort and would be of huge help to the platform as a whole. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: publish a new Working Draft of DOM Core; comment deadline March 2
On 3/1/11, Anne van Kesteren ann...@opera.com wrote: On Mon, 28 Feb 2011 18:49:48 +0100, Garrett Smith dhtmlkitc...@gmail.com wrote: | DOM Core defines the event and document model the Web platform uses. That says that DOM Core defines two different things: events and DOM. Some things might implement DOM Events Core (or a subinterface thereof) but are unrelated to the DOM. Like XHR. Could Events Core exist on its own? (You could make DOM Core conformance require Events Core conformance). These are the reasons they are intertwined: * document.createEvent() That was previously DocumentEvent interface, IIRC. * mutation events Why can't those be defined independently in Events. (not a fan of mutation events, BTW). * we want Node to inherit from EventTarget That can be stated in DOM Core. For example: The Node Interface implements EventTarget [Events Core]. * both events and documents depend on the same tree concept How do XHR events or progress events depend on tree concept? * INVALID_STATE_ERR is shared XHR and Event instances can have invalid states, but should those exceptions to have the same name and numerical representation? Defining Errors within the API that uses them makes it easier to change the Error. Of course, given a mutual dependency they could be split, but I do not really see the point. Something that depends on Events Core doesn't necessarily need to depend on DOMImplementation. I believe ProgressEvents is an existing case of that. I like to define specification to be specific. This makes them easier to read and change. Things that aren't related to document navigation can theoretically implement EventTarget. Node stuff, for example, nextSibling and cloneNode, aren't relevant to ProgressEvents. Should the Exceptions section be split out too in your opinion? Given that Events and Exceptions are quite short and per the above summary quite integral to how everything fits together I think the current division makes sense. No. Exceptions should not be in a separate specification; there is no core Exception module or interfaces. I like having the exception grouped with the API that uses it. INVALID_STATE_ERR for EventTarget is conceptually different than for XMLHttpRequest. I don't like having the same name for two different things. For example, a program that redispatches an Event would be putting that Event instance in an invalid state. Conversely, an `XMLHttpRequest` that calls `send()` before `open()` also creates an invalid state. However, to me, those are different scenarios. These two scenarios don't have enough in common to justify giving them the same numerical error code. I would actually prefer these two cases to have different error names because I think it would ease debugging. For instance, when an error message is missing or unhelpful, a web search on the error name should result in something more closely relevant to what caused the error. I'd stink to have a program with an XHR problem and get an error, search the web for that error, find the the Events API, and then go back to the program's event code. I noticed that the DOM Core spec uses throw instead of raise. I don't mind the change but it might be something that matters for IDL formalism. -- Garrett
RE: publish a new Working Draft of DOM Core; comment deadline March 2
On Friday, February 25, 2011 1:54 AM, Anne van Kesteren wrote: The idea is to provide a better definition of the events model at a more appropriate location. I do not think DOM Level 3 Events is the right way forward, but I am happy to work in parallel to see which turns out better in the end. This is a fair goal but my feedback is that it would be better to find a way to build on or enhance DOM L3 Events than to ignore it. I have studied it while writing the Events chapter actually. However it did not always provide all the answers, as indicated e.g. by Ian and also by my email announcing the addition. My preference is to not have two drafts in the WebApps working group with conflicting specification of the same feature. If there is feedback or clarifications that need to be added to DOM L3 Events we should make sure that happens. Where would you like the note to be located? Do you have preferred wording? Something like this maybe: DOM Core provides an alternative definition for the 'DOM Event Architecture' and 'Basic Event Interfaces' chapters of DOM Level 3 Events. We would appreciate your input on which approach you prefer. Something boxed out at the start of the Events section would be great for now. Hopefully we can make sure that the drafts are aligned and if the new DOM Core spec picks up where DOM L3 Events leaves off then that might be an helpful outcome. I think it's important for us to get DOM L3 Events to done to capture all the work that has been done over the last decade before moving on to something new. I'll also say for the record, since you're asking about this, that Microsoft's view is that keeping Event in DOM L3 Events is the best approach but that a profile elsewhere if necessary is fine. Changes along these lines would help show forward progress as intended by a heartbeat draft and then I would happily endorse this call for consensus to publish. Cool! Thanks for considering the feedback, Adrian.
Re: publish a new Working Draft of DOM Core; comment deadline March 2
Le 28 févr. 2011 à 17:59, Adrian Bateman a écrit : My preference is to not have two drafts in the WebApps working group with conflicting specification of the same feature. Looking at http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#events and http://www.w3.org/TR/DOM-Level-3-Events/#interface-Event For the IDL definition the only line which is really different is # DOM-Level-3-Events void initEvent( DOMString type, optional boolean bubbles, optional boolean cancelable); # Web Dom Core void initEvent( in DOMString eventTypeArg, in boolean canBubbleArg, in boolean cancelableArg); The prose in between the two is very different. The prose of Web DOM Core is closer than the one of HTML5. I haven't looked into details. -- Karl Dubost - http://dev.opera.com/ Developer Relations Tools, Opera Software
Re: publish a new Working Draft of DOM Core; comment deadline March 2
On 2/28/11, Adrian Bateman adria...@microsoft.com wrote: On Friday, February 25, 2011 1:54 AM, Anne van Kesteren wrote: The idea is to provide a better definition of the events model at a more appropriate location. I do not think DOM Level 3 Events is the right way forward, but I am happy to work in parallel to see which turns out better in the end. This is a fair goal but my feedback is that it would be better to find a way to build on or enhance DOM L3 Events than to ignore it. I have studied it while writing the Events chapter actually. However it did not always provide all the answers, as indicated e.g. by Ian and also by my email announcing the addition. My preference is to not have two drafts in the WebApps working group with conflicting specification of the same feature. If there is feedback or clarifications that need to be added to DOM L3 Events we should make sure that Redundance is bad. Breaking up D3E into modules, such as core, keyboard, mouse, etc, is a good thing. I've proposed this action in the past, as have others and Doug (the maintainer of D3E) disagreed then and now. The parts of D3E that are made redundant can be removed from D3E. A clean extraction and cooperation won't come without conflict. Although I defiantly[1] agree with modularization of D3E, I'm not sure if events belong in DOM core. It makes DOM core a this and that, not just a this formally speaking, less cohesive. | DOM Core defines the event and document model the Web platform uses. That says that DOM Core defines two different things: events and DOM. Some things might implement DOM Events Core (or a subinterface thereof) but are unrelated to the DOM. Like XHR. Could Events Core exist on its own? (You could make DOM Core conformance require Events Core conformance). -- Garrett [1]http://lists.w3.org/Archives/Public/www-dom/2010OctDec/0133.html
Re: publish a new Working Draft of DOM Core; comment deadline March 2
On Feb 24, 2011, at 5:21 PM, Doug Schepers wrote: Hi, Anne- I object to publishing a Working Draft of the DOM Core spec that includes DOM Events. Introducing conflicting specifications that cover the same materials dramatically harms interoperability, and the idea of competing specifications is an anti-pattern when it comes to standardization. If there are changes that you want to the DOM3 Events spec, and if you get the support of the browser vendors to make those changes, then I am happy to change the spec; I'm not married to the spec as it exists, but that is the result of what the last few years of discussing it with the browser vendors and users has resulted in. Please simply raise the individual issues on the www-dom mailing list for discussion. So far, I've seen no support on the list for adding events to DOM Core. Finally, at TPAC, when we discussed working on DOM Core and DOM 3 Events in parallel, we did not agree to adding events to DOM Core; in fact, we agreed to exactly the opposite: you wanted to move mutation events into DOM Core in a thinly-veiled attempt to remove them completely (rather than simply deprecate them as is done in DOM3 Events), and all the browser vendors disagreed with that. Claiming otherwise is simply an attempt to rewrite history. So, in summary: please remove section 4, Events, from DOM Core before publishing it as a Working Draft, for now. After serious discussion, if the group agrees, we can always add them back later, but I would prefer to change DOM3 Events to seeing conflicting specifications. I recall that we discussed putting core event support into DOM Core, so that it could be a unified Web-compatible successor to both DOM Level 3 Core and DOM Level 3 Events. Many specific reasons were given why it's better to define events together with the core instead of separately. I don't think we had agreement to leave events out of DOM Core. I believe what implementors present at TPAC agreed to is that we do not like mutation events and want them to die in a fire. I can't recall the details beyond that, I would have to check the minutes. For what it's worth, I (still) think it makes sense to define DOM Core and the central parts of DOM Events together (not necessarily the individual event names and interfaces though). They are not really logically separate. Regards, Maciej
Re: publish a new Working Draft of DOM Core; comment deadline March 2
On Feb 26, 2011, at 7:15 AM, Doug Schepers wrote: I will remove my objection to publish DOM Core if: 1) conflicts (rather than extensions) are removed from the draft, or reconciled with changes in DOM3 Events; and 2) for those changes that have broad consensus, we can integrate them into DOM3 Events, which means that the changes should be sent as comments on DOM3 Events, to be discussed by the group and their current status determined. What conflicts or contradictions exist currently? Does anyone have a list? Regards, Maciej
Re: publish a new Working Draft of DOM Core; comment deadline March 2
Hi, folks- I have no problem changing the DOM3 Events spec if that's the behavior that implementers want specified. I'd love for it to be as clear, simple, and precise as possible, and I have been asking for specific feedback for the past few years; while we have gotten a lot of good feedback, we did not get feedback asking for these specific changes... if we had, and if there was agreement by the browser vendors, we would have simply made the changes. In fairness, it's often easier to start with a blank slate than to revise something that's been around for 10 years with several different rounds of editors. I've thought of doing the same with DOM3 Events before, and maybe I should have. So, sometimes things simply become more clear when you write them yourself than when you comment on existing specs. I applaud the DOM Core editors taking the initiative to revisit assumptions and try to make a cleaner model. However, what I don't want is for DOM3 Events to be irrelevant, incorrect, and misleading by the time it reaches Rec... obviously, we'd revise it, but in the meantime, it would be sitting in CR, giving implementers the impression that it is the way to get interoperable behavior, and that it is relatively stable... having a concurrent conflicting spec within the same group is an anti-pattern, when one spec is moving toward stability after years of consensus-building around the behavior. (In general, I don't think it is a good practice to make conflicting working drafts rather than commenting on existing specifications first; I don't think it is an efficient way for a group to proceed (though of course conflicting proposals help improve specs in the early stages).) I don't object to specifying the event model in DOM Core going forward, nor to extensions to what is defined in DOM3 Events; I only object to conflicts or contradictions between the two specs. In fact, there are changes I would like to have specified in DOM3 Events, but couldn't build consensus around for that timeframe, including generic event constructors and initializers, rather than initializers for each event; I think this is a much better model. I will remove my objection to publish DOM Core if: 1) conflicts (rather than extensions) are removed from the draft, or reconciled with changes in DOM3 Events; and 2) for those changes that have broad consensus, we can integrate them into DOM3 Events, which means that the changes should be sent as comments on DOM3 Events, to be discussed by the group and their current status determined. I had previously started a DOM Core 4 draft specification, but when Anne and others volunteered to do Web DOM Core, I moved aside to let them work, and volunteered to help with that draft; I would still like to help edit that specification, to bring a slightly different perspective and approach, and to coordinate between DOM3 Events and DOM Core, and I believe we can edit the spec together amicably and productively. Regards- -Doug Schepers W3C Team Contact, SVG, WebApps, and Web Events WGs
Re: publish a new Working Draft of DOM Core; comment deadline March 2
On Fri, 25 Feb 2011 02:21:44 +0100, Doug Schepers schep...@w3.org wrote: Finally, at TPAC, when we discussed working on DOM Core and DOM 3 Events in parallel, we did not agree to adding events to DOM Core; in fact, we agreed to exactly the opposite: you wanted to move mutation events into DOM Core in a thinly-veiled attempt to remove them completely (rather than simply deprecate them as is done in DOM3 Events), and all the browser vendors disagreed with that. Claiming otherwise is simply an attempt to rewrite history. http://www.w3.org/2010/11/02-webapps-minutes.html#item01 # adrianba: I don't have a strong opinion about where # we go in the long term # mjs: my preference would be to move forward but plan # [to move things to DOM Core later] # smaug_: I agree And no, I did not necessarily want to remove mutation events. If they remain implemented they need to be defined. And the best place for that is by the methods that cause them to be fired. Those methods are defined by DOM Core. That was my argument. -- Anne van Kesteren http://annevankesteren.nl/
Re: publish a new Working Draft of DOM Core; comment deadline March 2
On Fri, 25 Feb 2011, Anne van Kesteren wrote: On Fri, 25 Feb 2011 02:21:44 +0100, Doug Schepers schep...@w3.org wrote: Finally, at TPAC, when we discussed working on DOM Core and DOM 3 Events in parallel, we did not agree to adding events to DOM Core; in fact, we agreed to exactly the opposite: you wanted to move mutation events into DOM Core in a thinly-veiled attempt to remove them completely (rather than simply deprecate them as is done in DOM3 Events), and all the browser vendors disagreed with that. Claiming otherwise is simply an attempt to rewrite history. http://www.w3.org/2010/11/02-webapps-minutes.html#item01 # adrianba: I don't have a strong opinion about where # we go in the long term # mjs: my preference would be to move forward but plan # [to move things to DOM Core later] # smaug_: I agree And no, I did not necessarily want to remove mutation events. If they remain implemented they need to be defined. And the best place for that is by the methods that cause them to be fired. Those methods are defined by DOM Core. That was my argument. For what it's worth, I strongly support the work done by Anne and Ms2ger here. The new DOM Core spec is fantastic, specifying things to a great level of detail. I think we should adopt this level of detail for all our specs. For example, it is the first specification of the Event interface that I have seen in over 13 years of DOM specs that actually normatively defines (using RFC2119 terminology) what exactly event.eventPhase is to return, and it does so succinctly and unambiguously. Similarly for pretty much the entire API. It's also the first time I've seen the event dispatch processing model described to sufficient detail to get interoperability, and it does so in a tenth of the prose of earlier specifications. The same applies to its description of the DOM Node interfaces, and indeed to its definitions of a number of concepts such as trees, etc. Throughout the spec there is a consistent approach of comprehensive concision. I'm a fan. I intend to update the various specs I maintain to reference this spec in the near future (tracked as bug 12094 [1]). Doing so will actually fix a number of outstanding bugs in the HTML spec, as well as resulting in a significant amount of material being cut out and replaced with simple references to the new DOM Core spec. [1] http://www.w3.org/Bugs/Public/show_bug.cgi?id=12094 -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. It should still be called Web DOM Core though. `._.-(,_..'--(,_..'`-.;.'
Re: publish a new Working Draft of DOM Core; comment deadline March 2
On Fri, 25 Feb 2011 01:57:04 +0100, Adrian Bateman adria...@microsoft.com wrote: Of course it's true that the status doesn't imply everyone agrees with everything and I'm okay with that but heartbeat working drafts are intended to show forward progress and this feels like a retrograde step to me compared to the previous draft. This should be updated to reflect the discussions for ISSUE-171 and ISSUE-172. I see. I missed that it was resolved. The issue status still says RAISED. Is it expected that all implementations will actually converge on this less than optimal behavior? From the issue it seemed pretty clear that e.g. Gecko had engineered it quite differently. Since DOM L3 Events is further along and likely to track faster than this spec it would be reasonable to refer to this. I changed the 2 to a 3. The idea is to provide a better definition of the events model at a more appropriate location. I do not think DOM Level 3 Events is the right way forward, but I am happy to work in parallel to see which turns out better in the end. This is a fair goal but my feedback is that it would be better to find a way to build on or enhance DOM L3 Events than to ignore it. I have studied it while writing the Events chapter actually. However it did not always provide all the answers, as indicated e.g. by Ian and also by my email announcing the addition. Working Drafts are there to share ideas with the wider world. They are not endorsed. Last Call Working Drafts and beyond are supposed to be checked carefully. Letting the wider world comment on this idea is exactly what I would like; to see if it's a good idea. It would be nice if you could suggest some approach as to how we could resolve this timely. If this is your intent then it would be helpful to include a note in the draft making this clear so people know to give this kind of feedback. Otherwise it is just confusing to see it defined in two different places. Where would you like the note to be located? Do you have preferred wording? Something like this maybe: DOM Core provides an alternative definition for the 'DOM Event Architecture' and 'Basic Event Interfaces' chapters of DOM Level 3 Events. We would appreciate your input on which approach you prefer. I'll also say for the record, since you're asking about this, that Microsoft's view is that keeping Event in DOM L3 Events is the best approach but that a profile elsewhere if necessary is fine. Changes along these lines would help show forward progress as intended by a heartbeat draft and then I would happily endorse this call for consensus to publish. Cool! -- Anne van Kesteren http://annevankesteren.nl/
Re: publish a new Working Draft of DOM Core; comment deadline March 2
Doug, Le 25 févr. 2011 à 02:21, Doug Schepers a écrit : Finally, at TPAC, when we discussed working on DOM Core and DOM 3 Events in parallel, Would it help if the DOM 3 Events was republished at the same time, with a note pointing to the work done in DOM Core. Something along. The DOM Core published by the WebApps Working Groups has a description of DOM Events. We are in the process of looking for the best place for defining DOM events. etc. For what is worth, I like the prose of DOM Core and there is value in this document. If it helps to attract additional comments about events, it will be good. As long as you and Anne/Msg2ger find a way to coordinate. There will be a way :) -- Karl Dubost - http://dev.opera.com/ Developer Relations Tools, Opera Software
RE: publish a new Working Draft of DOM Core; comment deadline March 2
On Wednesday, February 23, 2011 8:21 AM, Arthur Barstow wrote: Anne and Ms2ger (representing Mozilla Foundation) have continued to work on the DOM Core spec and they propose publishing a new Working Draft of the spec: http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html As such, this is a Call for Consensus (CfC) to publish a new WD of DOM Core. If you have any comments or concerns about this proposal, please send them to public-webapps by March 2 at the latest. As with all of our CfCs, positive response is preferred and encouraged and silence will be assumed to be agreement with the proposal. I'm concerned about the working group endorsing a working draft with phrasing like The timeStamp attribute must be useless. I understand there are issues related to this (e.g. ISSUE-172) but this doesn't seem like a professional way to approach them. I think the document should have a clearly stated goal relative to DOM L3 Events. Currently it describes building on DOM L3 Core and DOM L2 Events. Anne described adding events to the draft last week [1] but it's not clear to me what the benefit of redefining the Event interface in this document is when W3C is proceeding with DOM L3 Events on the Recommendation track. If there are things that need to be clarified specifically for browsers and similar user agents then perhaps a profile of DOM L3 Events would be better. I'd prefer issues like this to be resolved before endorsing them in a Working Draft. Thanks, Adrian. [1] http://lists.w3.org/Archives/Public/public-webapps/2011JanMar/0559.html
Re: publish a new Working Draft of DOM Core; comment deadline March 2
On Thu, 24 Feb 2011 19:26:19 +0100, Adrian Bateman adria...@microsoft.com wrote: I'm concerned about the working group endorsing a working draft with phrasing like The timeStamp attribute must be useless. I understand there are issues related to this (e.g. ISSUE-172) but this doesn't seem like a professional way to approach them. It's a funny way ;-) And it has a red marker pointing out the problems. And as stated in the Status of this Document section publication does not imply endorsement. I think the document should have a clearly stated goal relative to DOM L3 Events. I thought that would be inappropriate since DOM Level 3 Events is still in development. We discussed this at TPAC and decided that DOM Core would do things in parallel and based on that we would figure out which is the better approach once both are somewhat more stable. However, relative to DOM Level 3 Events the differences are identical. So if that would remove your objection I can change the 2 to a 3. Currently it describes building on DOM L3 Core and DOM L2 Events. Anne described adding events to the draft last week [1] but it's not clear to me what the benefit of redefining the Event interface in this document is when W3C is proceeding with DOM L3 Events on the Recommendation track. If there are things that need to be clarified specifically for browsers and similar user agents then perhaps a profile of DOM L3 Events would be better. The idea is to provide a better definition of the events model at a more appropriate location. I do not think DOM Level 3 Events is the right way forward, but I am happy to work in parallel to see which turns out better in the end. I'd prefer issues like this to be resolved before endorsing them in a Working Draft. Working Drafts are there to share ideas with the wider world. They are not endorsed. Last Call Working Drafts and beyond are supposed to be checked carefully. Letting the wider world comment on this idea is exactly what I would like; to see if it's a good idea. It would be nice if you could suggest some approach as to how we could resolve this timely. [1] http://lists.w3.org/Archives/Public/public-webapps/2011JanMar/0559.html -- Anne van Kesteren http://annevankesteren.nl/
RE: publish a new Working Draft of DOM Core; comment deadline March 2
On Thursday, February 24, 2011 2:37 PM, Anne van Kesteren wrote: On Thu, 24 Feb 2011 19:26:19 +0100, Adrian Bateman adria...@microsoft.com wrote: I'm concerned about the working group endorsing a working draft with phrasing like The timeStamp attribute must be useless. I understand there are issues related to this (e.g. ISSUE-172) but this doesn't seem like a professional way to approach them. It's a funny way ;-) And it has a red marker pointing out the problems. And as stated in the Status of this Document section publication does not imply endorsement. Of course it's true that the status doesn't imply everyone agrees with everything and I'm okay with that but heartbeat working drafts are intended to show forward progress and this feels like a retrograde step to me compared to the previous draft. This should be updated to reflect the discussions for ISSUE-171 and ISSUE-172. I think the document should have a clearly stated goal relative to DOM L3 Events. I thought that would be inappropriate since DOM Level 3 Events is still in development. We discussed this at TPAC and decided that DOM Core would do things in parallel and based on that we would figure out which is the better approach once both are somewhat more stable. However, relative to DOM Level 3 Events the differences are identical. So if that would remove your objection I can change the 2 to a 3. Since DOM L3 Events is further along and likely to track faster than this spec it would be reasonable to refer to this. The idea is to provide a better definition of the events model at a more appropriate location. I do not think DOM Level 3 Events is the right way forward, but I am happy to work in parallel to see which turns out better in the end. This is a fair goal but my feedback is that it would be better to find a way to build on or enhance DOM L3 Events than to ignore it. I'd prefer issues like this to be resolved before endorsing them in a Working Draft. Working Drafts are there to share ideas with the wider world. They are not endorsed. Last Call Working Drafts and beyond are supposed to be checked carefully. Letting the wider world comment on this idea is exactly what I would like; to see if it's a good idea. It would be nice if you could suggest some approach as to how we could resolve this timely. If this is your intent then it would be helpful to include a note in the draft making this clear so people know to give this kind of feedback. Otherwise it is just confusing to see it defined in two different places. I'll also say for the record, since you're asking about this, that Microsoft's view is that keeping Event in DOM L3 Events is the best approach but that a profile elsewhere if necessary is fine. Changes along these lines would help show forward progress as intended by a heartbeat draft and then I would happily endorse this call for consensus to publish. Thanks for your consideration, Adrian.
Re: publish a new Working Draft of DOM Core; comment deadline March 2
Hi, Anne- I object to publishing a Working Draft of the DOM Core spec that includes DOM Events. Introducing conflicting specifications that cover the same materials dramatically harms interoperability, and the idea of competing specifications is an anti-pattern when it comes to standardization. If there are changes that you want to the DOM3 Events spec, and if you get the support of the browser vendors to make those changes, then I am happy to change the spec; I'm not married to the spec as it exists, but that is the result of what the last few years of discussing it with the browser vendors and users has resulted in. Please simply raise the individual issues on the www-dom mailing list for discussion. So far, I've seen no support on the list for adding events to DOM Core. Finally, at TPAC, when we discussed working on DOM Core and DOM 3 Events in parallel, we did not agree to adding events to DOM Core; in fact, we agreed to exactly the opposite: you wanted to move mutation events into DOM Core in a thinly-veiled attempt to remove them completely (rather than simply deprecate them as is done in DOM3 Events), and all the browser vendors disagreed with that. Claiming otherwise is simply an attempt to rewrite history. So, in summary: please remove section 4, Events, from DOM Core before publishing it as a Working Draft, for now. After serious discussion, if the group agrees, we can always add them back later, but I would prefer to change DOM3 Events to seeing conflicting specifications. Regards- -Doug Schepers W3C Team Contact, SVG, WebApps, and Web Events WGs Anne van Kesteren wrote (on 2/24/11 5:37 PM): On Thu, 24 Feb 2011 19:26:19 +0100, Adrian Bateman adria...@microsoft.com wrote: I'm concerned about the working group endorsing a working draft with phrasing like The timeStamp attribute must be useless. I understand there are issues related to this (e.g. ISSUE-172) but this doesn't seem like a professional way to approach them. It's a funny way ;-) And it has a red marker pointing out the problems. And as stated in the Status of this Document section publication does not imply endorsement. I think the document should have a clearly stated goal relative to DOM L3 Events. I thought that would be inappropriate since DOM Level 3 Events is still in development. We discussed this at TPAC and decided that DOM Core would do things in parallel and based on that we would figure out which is the better approach once both are somewhat more stable. However, relative to DOM Level 3 Events the differences are identical. So if that would remove your objection I can change the 2 to a 3. Currently it describes building on DOM L3 Core and DOM L2 Events. Anne described adding events to the draft last week [1] but it's not clear to me what the benefit of redefining the Event interface in this document is when W3C is proceeding with DOM L3 Events on the Recommendation track. If there are things that need to be clarified specifically for browsers and similar user agents then perhaps a profile of DOM L3 Events would be better. The idea is to provide a better definition of the events model at a more appropriate location. I do not think DOM Level 3 Events is the right way forward, but I am happy to work in parallel to see which turns out better in the end. I'd prefer issues like this to be resolved before endorsing them in a Working Draft. Working Drafts are there to share ideas with the wider world. They are not endorsed. Last Call Working Drafts and beyond are supposed to be checked carefully. Letting the wider world comment on this idea is exactly what I would like; to see if it's a good idea. It would be nice if you could suggest some approach as to how we could resolve this timely. [1] http://lists.w3.org/Archives/Public/public-webapps/2011JanMar/0559.html
