W3C DOM Level 3 Events Issues List

This document contains a list of issues regarding the DOM Level 3 Events specification Last Call period. All comments or issues regarding the specification or this document must be reported to www-dom@w3.org (public archives) before 1 May, 2003.

Inside: Issue summary | State description | Decision cycle description | Issue details

Issue summary (52 issues)

Reformat summary with options:
Expert mode options
Hide types:
Hide Columns:

Other views: types | states | concerning | reviewers | open actions

Add to issues list: create issue

Changes between dates (YYYY-MM-DD) and [Optional]

Color key: error warning note

Id: TitleStateTypeOpen actionsAck.
pettit1 : Description of Event flowdeclinedclarificationAgreement
pettit2 : Event listeners activationagreedclarificationAgreement
pettit3 : Event captureagreededitorialAgreement
pettit4 : HTML eventsagreedclarification
pettit5 : Event CreationagreederrorAgreement
pettit6 : Mouse eventdeclinedrequestNo reply from reviewer
pettit7a : Text eventsdeclinederrorAgreement
pettit7b : Text eventsdeclinederrorAgreement
pettit7c : Text eventsagreederrorAgreement
pettit7d : Text eventsagreedclarification
    Agreement
    pettit7e : Text eventsagreedclarificationAgreement
    pettit8 : Mutation event typesagreederrorAgreement
    pettit9 : HTML event typesdeclinedrequestAgreement
    schiemann1 : Range.cloneNodes and event listenersagreedclarificationNo reply from reviewer
    schiemann2 : extractNodes and event listenersagreedclarificationNo reply from reviewer
    flanagan1 : TextEvent.visibleOutputGenerated definitiondeclinedclarificationAgreement
    flanagan2 : CustomEvent definitionagreedclarification
    codding1 : CustomEvent definitionagreedrequestNo reply from reviewer
    pemberton1 : default actiondeclinederrorNo reply from reviewer
    arnold1 : namespace supportdeclinedrequest
      No reply from reviewer
      arnold2 : creating eventsdeclinedrequestNo reply from reviewer
      gilman1 : semantic eventsdeclinedrequest
        No reply from reviewer
        pemberton2 : TextEventagreederrorNo reply from reviewer
        lerstad1 : DOMAttributeNameChangedagreederrorNo reply from reviewer
        allen1 : processSubtreeModifiedEventsdeclinedrequestNo reply from reviewer
        alex1 : NodeFiltering system for event listenersdeclinedrequestNo reply from reviewer
        duerst1 : target ancestor?agreedclarificationAgreement
        duerst2 : type, category, and groupagreedclarificationAgreement
        duerst3 : Event propagation and event groupsagreedclarificationAgreement
        duerst4 : Event types, IRIs, and XML NamespacesagreedrequestAgreement
        duerst5 : resize, scroll, and BasicEventsdeclinedclarificationAgreement
        duerst6 : Event.type, NCName, and colonagreedclarificationAgreement
        duerst7 : obtaining a DocumentEvent objectagreedclarificationAgreement
        duerst8 : cut/paste and TextEventagreedrequestAgreement
        duerst9 : Do we need initTextEvent?declinedproposalAgreement
        duerst10 : init* methodsagreededitorialAgreement
        duerst11 : right Ctrl key and mouse events declined initial suggestion, agreed on follow-up request
        duerst12 : right Ctrl key and keyboard eventssubsumed
        [duerst11]
        request
        duerst13 : pressing and releasing modifiersagreedclarificationAgreement
        duerst14 : key identifiersagreedrequestAgreement
        duerst15 : key location unknownagreedproposalAgreement
        duerst16 : Unicode notation for key identifiersagreedrequestAgreement
        duerst17 : why keydown of a capital letter produces a textInput of a lowercase letterdeclinedproposalAgreement
        duerst18 : Event groupsdeclinedclarificationAgreement
        duerst19 : CAPS LOCK has a modifieragreedrequestAgreement
        duerst20 : PDF and Unicode declined initial suggestion, agreed on follow-up request
        duerst21 : examples of keyboard events with different architecturesdeclinedrequestAgreement
        duerst24 : textInput and NFCagreedclarificationAgreement
        duerst25 : Convert and HiraganaagreededitorialAgreement
        rehor1 : Ordering of Event GroupsdeclinedrequestNo reply from reviewer
        rehor2 : Event selectiondeclinedrequestNo reply from reviewer
        rehor3 : Hierarchical NamespacedeclinedrequestNo reply from reviewer

        State description

        Decision cycle description

        Issue details

        Validate my issues file

        pettit1: Description of Event flow

        How does modification of the DOM tree affect event propagation, section 1.2.2 notwithstanding ("If modifications occur to the tree during event processing, event flow will proceed based on the initial state of the tree"). If an EventTarget is deleted during propagation of an event, does that affect propagation?

        Discussion history
        6 Aug 2002, 6 Aug 2002

        Transition history

        raised on 13 Jul 2002 by Brad Pettit
        declined on 28 Aug 2002

        The modification of the DOM tree does not affect the event propagation. The nodes evolved are determined before the event propagation.

        No changes were made in the specification.

        Acknowledgment cycle
        announced by group on 28 Aug 2002
        agreement by reviewer on 28 Aug 2002

        pettit2: Event listeners activation

        "It is expected that actions taken by EventListeners may cause additional events to fire. Additional events should be handled in a synchronous manner and may cause reentrancy into the event model."

        Since implementations may have restrictions such as stack-usage or other memory requirements, applications should not depend on how many synchronous events may be triggered.

        Transition history

        raised on 13 Jul 2002 by Brad Pettit
        agreed on 28 Aug 2002

        The following sentence has been added:

        "Since implementations may have restrictions such as stack-usage or other memory requirements, applications should not depend on how many synchronous events may be triggered."

        Acknowledgment cycle
        announced by group on 28 Aug 2002
        agreement by reviewer on 28 Aug 2002

        pettit3: Event capture

        " Capture operates from the top of the tree, generally the Document, downward "

        Is "generally" necessary? Can events be fired on nodes that are not in the document?

        Discussion history
        6 Aug 2002

        Transition history

        raised on 13 Jul 2002 by Brad Pettit
        agreed on 28 Aug 2002

        "Generally the document" has been removed.

        Acknowledgment cycle
        announced by group on 28 Aug 2002
        agreement by reviewer on 28 Aug 2002

        pettit4: HTML events

        " In the case of the hyperlink in the browser, canceling the action would have the result of not activating the hyperlink."

        "Different implementations will specify their own default actions, if any, associated with each event. The DOM does not attempt to specify these actions."

        In the case of HTMLEvents, the default actions for some of the objects, such as <A>, as well as their relationship with DOM 1 HTML (such as what DOM2/3 events result from calling the "click, blur, focus, or select" methods on an element) would be worth specification. Otherwise we end up with a situation where the first widely distributed implementation dictates the specification.

        Discussion history
        6 Aug 2002, 6 Aug 2002

        Transition history

        raised on 13 Jul 2002 by Brad Pettit
        accepted on 28 Aug 2002

        We should change the sample in section 1.3 to make it less miss-leading.

        agreed on 14 Mar 2003

        The new Section 1.7.7.1 should now clarify this.

        Acknowledgment cycle
        announced by group on 20 Jun 2003
        proposal from reviewer on 20 Jun 2003

        How about changing "If a change is made before the activation," to "If a DOM property is changed before the event is fired,"

        proposal incorporated by group on 25 Jun 2003

        Changed to "If a DOM attribute is changed before the event is fired,"

        pettit5: Event Creation

        CustomEvent -- What is the use case for SetEventPhase? Can preventDefault or stopPropagation be called during execution of that method.

        Discussion history
        6 Aug 2002, 6 Aug 2002, 6 Aug 2002

        Transition history

        raised on 13 Jul 2002 by Brad Pettit
        agreed on 28 Aug 2002

        An Event cannot be dispatch twice simulteously in the DOM tree. An exception has been added for that effect in the specification.

        Acknowledgment cycle
        announced by group on 28 Aug 2002
        agreement by reviewer on 28 Aug 2002

        pettit6: Mouse event

        Issue public0023 notwithstanding, the spec should discuss the implementation's responsibility regarding screen- and client-coordinate translation with regard to DOM 0 event handlers. Since one set of coordinates implies the other set of coordinates, applications might assume some behavior - once again the "first-implementation- dictates-the-spec" problem.

        Regarding the resolution of 0023, this _is_ a future version and it seems like a good time to address this issue, particularly since new API is being added. I'd suggest that the new API remove the specification of screen/sclient coordinates entirely and support ONLY target-relative coordinates. That would be less ambiguous.

        Transition history

        raised on 13 Jul 2002 by Brad Pettit
        declined on 28 Aug 2002

        The spec should mention that application manufactured UI events (i.e. an event created with createEvent()) should use the client coordinates for calculation of other coordinates (such as DOM0 event properties).

        Acknowledgment cycle
        announced by group on 25 Jun 2002

        pettit7a: Text events

        Is there no differentiation between the 'Enter key on the numeric keypad' and the 'Return or Enter key on regular typing keyboard'? I see only DOM_VK_ENTER specified. Other keys are differentiated between left and right in the spec. On the Mac, a different character code is generated as well.

        Transition history

        raised on 13 Jul 2002 by Brad Pettit
        declined on 28 Aug 2002

        The numPad property on TextEvent is the difference.

        Acknowledgment cycle
        announced by group on 28 Aug 2002
        agreement by reviewer on 28 Aug 2002

        pettit7b: Text events

        Only one of keyVal or virtKeyVal should be non-zero. If initTextEvent is called with both non-zero, should the implementation check for this? If so, what action should it take since no exception is specified?

        Transition history

        raised on 13 Jul 2002 by Brad Pettit
        declined on 28 Aug 2002

        If initTextEvent is called with incorrect values it may fire with incorrect values. Validation is left to the author.

        Acknowledgment cycle
        announced by group on 28 Aug 2002
        agreement by reviewer on 28 Aug 2002

        pettit7c: Text events

        keyDown and keyUp events are not necessarily generated in pairs by a platform. All that can be assumed is that one or more keyDown events are followed by a keyUp event. The spec suggests these occur in pairs "Depending on the input system being used, textEvent events may or may not be generated for each pair of keydown and keyup events." The alternative is that only the first keyDown in a "autoKey" sequence should result in a keyDown.

        "i.e. onkeydown="alert('foo')", the keydown happens in the window, but the keyup event happens in the alert window."

        Transition history

        raised on 13 Jul 2002 by Brad Pettit
        agreed on 28 Aug 2002

        We change the specification as follows:

        " Depending on the character device generation system, those events may or may not be generated and not necessarily in pairs for various reasons: the system never generates one of them or the focus may change between the keydown and the keyup. "

        Acknowledgment cycle
        announced by group on 28 Aug 2002
        agreement by reviewer on 28 Aug 2002

        pettit7d: Text events

        In previous mailing list discussion, it's been clarified that "canceling" a keyDown event has NO EFFECT on whether a textEvent event is generated from that keyDown. This should be in the spec.

        Discussion history
        31 Mar 2003

        Transition history

        raised on 13 Jul 2002 by Brad Pettit
        accepted on 28 Aug 2002

        We should had the clarification that canceling a keyDown has no effect on a textEvent.

        declined on 2 Jul 2003

        Canceling keyDown or keyUp (using Event.preventDefault) does cancel the textInput event.

        Acknowledgment cycle
        announced by group on 24 Jul 2003
        objection from reviewer on 24 Jul 2003

        I believe it is a mistake to create such a tie between Keyboard events and Text events. Whether a particular device generates a specific character code in response to one, two, or a thousand keydown/keyup events should have no bearing on what text event is generated. By tying the cancelling of a keyboard event to the (non-)generation of a text event encourages assumptions regarding event ordering. One should not assume ordering of keyboard events in relationship to the textEvent. Since it would be possible for a developer to cancel the text event itself, there is no need to specify that cancelling the keyboard event should affect whether a text event is generated.

        objection accepted by group on 14 Aug 2003

        The issue was revisited.

        declined on 15 Aug 2003

        Keyboards are generating text, so tying the keyboard events to the text events do make sense. The reverse would certainly not be appropriate. We removed the previous added section and added the following description to the definitions of keydown and keyup:

        "If cancelled (Default actions and cancelable events), a keydown cannot contribute to the generation of text events. Whether a keydown contributes or not to the generation of a text event is implementation dependent. "

        Acknowledgment cycle
        announced by group on 15 Aug 2003
        objection from reviewer on 15 Aug 2003

        By stating that a cancelled keyDown CANNOT contribute to the generation of a text event, you are suggesting that it DOES contribute to a text event because changing the key down controls whether the text event will fire.

        Additionally, one situation where this could be a problem is a modifier key. If one cancels the keydown of a modifer key, but then does not cancel the keyDown for an alpha-numeric key following it, the cancelled modifier key would still probably contribute to the character generated by the system, and there may be no reasonable way to change that.

        That's why I was suggesting key events should be as detached from textEvents as possible. Cancelling a key event should have no relation to the generation of the text event, just as cancelling a keyDown event may have no relation to the generation of a keyUp event. The generation of text should not be assumed as the default action of the keyDown.

        objection accepted by group on 27 Aug 2003

        The issue was revisited.

        agreed on 27 Aug 2003

        After discussions, there was still reluctance to ignore the fact that keys do generate text. However, the control of the text generation following the cancellation of a key could be a problem, as you demonstrated with your modifier example. The consensus was to remove the first sentence ("If cancelled, a keydown cannot contribute to the generation of text events. ") and keep the second one:

        " Whether a keydown/keyup contributes or not to the generation of a text event is implementation dependent. "

        This statement should be enough to discourage applications to cancel keys in order to affect the text generation imho.

        Acknowledgment cycle
        announced by group on 27 Aug 2003
        agreement by reviewer on 27 Aug 2003

        Action history

        Philippe

        test implementations on this and report.

        pettit7e: Text events

        In what case would visibleOutputGenerated be TRUE for any TextEvent other than textInput?

        Transition history

        raised on 13 Jul 2002 by Brad Pettit
        agreed on 28 Aug 2002

        visibleOutputGenerated would only be true for a textInput event but would not always be true for that. The wording was clarified to make it clear that this attribute was only relevant for textInput event.

        Acknowledgment cycle
        announced by group on 28 Aug 2002
        agreement by reviewer on 28 Aug 2002

        pettit8: Mutation event types

        Given that the support of prevValue in MODIFICATION mutations can have a significant performance and design impact on an implementation, is it acceptable to claim support for MutationEvent events if NULL is always returned for prevValue/newValue of implementation-generated mutation events?

        Transition history

        raised on 13 Jul 2002 by Brad Pettit
        agreed on 28 Aug 2002

        A method canDispatch was added on DocumentEvent in order to query the implementation and knows if it's going to generate and dispatch events of a certain type.

        Acknowledgment cycle
        announced by group on 28 Aug 2002
        agreement by reviewer on 28 Aug 2002

        pettit9: HTML event types

        For Focus and Blur, it seems like any element with a default- or script-supplied action for key-input (such as return should be eligible for these events, particularly since it's common to allow keyboard navigation between any element with some default action. Don't restrict the list to specific element types.

        Transition history

        raised on 13 Jul 2002 by Brad Pettit
        declined on 28 Aug 2002

        Focus and Blur are based on compatibility with previous HTML events. Continued expansions of focus/blur events seems like it makes more sense on the DOMFocusIn and DOMFocusOut events.

        Acknowledgment cycle
        announced by group on 28 Aug 2002
        agreement by reviewer on 28 Aug 2002

        schiemann1: Range.cloneNodes and event listeners

        should cloneContents clone eventListeners? Based on behavior for cloneNode and the Events spec., I would guess no. If it did, this raises issues for partially-selected nodes.

        Transition history

        raised on 15 Jul 2002 by Dylan Schiemann
        agreed on 28 Aug 2002

        The following sentence was added:

        Copying a Node does not copy the event listeners attached to it. Event listeners must be attached to the newly created node afterwards if so desired. Therefore, when Nodes are copied using Node.cloneNode or Range.cloneContents, the EventListeners attached to them are not automatically attached to their copies.

        Acknowledgment cycle
        announced by group on 18 Sep 2002

        schiemann2: extractNodes and event listeners

        should extractNodes maintain eventListeners? If this method is considered cloning, then I would guess no. If so, then I see issues with extracting partially-selected nodes.

        Transition history

        raised on 15 Jul 2002 by Dylan Schiemann
        agreed on 28 Aug 2002

        The following sentence was added:

        Moving a Node does not affect the event listeners attached to it. Therefore, when Nodes are moved using Document.adoptNode, Node.appendChild, or Range.extractContents, the EventListeners attached to the moved Nodes stay attached to them.

        Acknowledgment cycle
        announced by group on 18 Sep 2002

        flanagan1: TextEvent.visibleOutputGenerated definition

        The visibleOutputGenerated attribute of TextEvent could use some clarification. Are non-printing characters such as spaces and newlines visible characters? This is not entirely clear as currently worded. Also, it seems to me that the following is always true:

        	      visibleOuputGenerated == (outputString != null)
        	    

        I think it would be helpful to either confirm that this is always the case, or to give an example of a case in which it is not the case.

        Transition history

        raised on 30 Jul 2002 by David Flanagan
        accepted on 28 Aug 2002

        whitespace would be considered visible since it has immediate visible effects on document formatting. This should probably be clarified. The larger issue here is that of firing textInput for keys such as modifiers or as parts of multikey sequences. The idea was that textInput could be used to indicate that text information had been entered, either printable or not, including modifiers and such. This is noted in the spec as:

        " The textInput event indicates that text information has been entered, either in the form of printable characters or non-printable text information such as modifier keys. "

        The idea was based on both the fact that keypress, an Level 0 key event be deprecated for textInput, has in the past fired for such input. Additionally the textInput event might be used on handheld devices or other devices with no keyboard. In such cases it might be necessary to convey modifier input before visible input. From various comments this idea is clearly not fully understood and probably needs clarification or modification. As textInput is a new event it has no backwards compatibility issues and can be modified in the spec as needed if required by design necessities.

        declined on 31 Mar 2003

        visibleOuputGenerated has been removed from the TextEvent interface since it was device dependent (display related).

        Acknowledgment cycle
        announced by group on 20 Jun 2003
        agreement by reviewer on 20 Jun 2003

        flanagan2: CustomEvent definition

        The description of the CustomEvent interface in the Last Call draft of the Level 3 Events spec is very confusing. I was only able to figure it out after reading the note about it in the description of DocumentEvent.createEvent(). I suggest you add more description to CustomEvent itself. In particular, please say when it is necessary to implement this interface.

        Transition history

        raised on 30 Jul 2002 by David Flanagan
        agreed on 28 Aug 2002

        Section 1.6.1 has been rewritten.

        Acknowledgment cycle
        announced by group on 18 Sep 2002
        proposal from reviewer on 19 Sep 2002

        My only suggestion is that you rewrite the sentences beginning with "This problem could be resolved using two techniques...". This part of the text is a distraction discussion of options considered in the design, rather than a simple description of the final specification.

        proposal incorporated by group on 31 Mar 2003

        reworded a bit the sentences.

        codding1: CustomEvent definition

        The two methods in CustomEvent, setCurrentTarget() and setEventPhase(), should be added to the Event interface for Level 3. In order for an implementation to determine how to set the Event.currentTarget and Event.eventPhase of an Event it is dispatching, it now needs to be able to tell if that Event is actually a CustomEvent or not. This requires some form of runtime type information. Xerces-C++ does not use RTTI, which makes this determination impossible without adding a method/field to the Event interface that can be used to determine the type of an Event (similar to getNodeType() on Node).

        Transition history

        raised on 2 Aug 2002 by Nathan Codding
        agreed on 18 Sep 2002

        A readonly boolean attribute isCustom was added on the Event interface. This attribute is true if the event object implements the CustomEvent interface.

        Acknowledgment cycle
        announced by group on 14 Sep 2002

        pemberton1: default action

        ""Before invoking a default action, the implementation must check for all event listeners registered to receive the event and dispatch the event to those listeners.""

        DOM2 doesn't define when a default action gets invoked. Suppose an implementation implements default actions as a special class of handler on a node, that get executed after all user-defined handlers on that node (which is perfectly allowable according to DOM2.) All of a sudden those implementations will break for DOM3. So this is a non-compatible change.

        Transition history

        raised on 1 Aug 2002 by Steven Pemberton, on behalf of HTML WG
        declined on 28 Aug 2002

        DOM2 did define when a default action gets invoked and any other interpretation was wrong. No change in the specification.

        Acknowledgment cycle
        announced by group on 18 Sep 2002

        arnold1: namespace support

        " For backward compatibility reasons, the dispatching of an event will ignore namespace URIs if either the event or the event listener has a null namespace URI. If a DOM Level 2 event (i.e. with a null namespace URI) is dispatched in the DOM tree, all event listener that match the type will be triggered as described in Description of event flow. If a DOM Level 3 event (i.e. with a namespace URI) is dispatched in the DOM tree, all event listener with the same type and the same or null namespace URI, will be triggered as described in Description of event flow. "

        This basically results in a null namespace parameter to addEventListernerNS acting like "*" in getElementsByTagNameNS. It also has the effect of discouraging use of common event names (like "load") in arbitrary namespaces since existing DOM L2 Event clients would receive those messages in addition to the intended {http://www.w3.org/2001/xml-events}load and {null}load events.

        The motivating factor is to not break existing event handling code while effectively changing the DOM defined events from not being in a namespace to being in {http://www.w3.org/2001/xml-events}. Instead of having addEventListenerNS(null, "load") or addEventListener("load") receive any event named "load", it would not be difficult to define the behavior so that it would only get {http://www.w3.org/2001/xml-events}load and {null}load events.

        One mechanism to accomplish this would be to add an additional boolean parameter or the init*EventNS's that mark the event as being dispatched in a compatibility mode. If this parameter was set on the event, then the event should be dispatched to any listener that matches its namespace and event type or any listener registered with addEventListener() or addEventListenerNS(null,) and its event type.

        The second option would be to imply that behavior for any event in {http://www.w3.org/2001/xml-events}.

        Discussion history
        18 Sep 2002

        Transition history

        raised on 14 Aug 2002 by Curt Arnold
        declined on 24 Oct 2002

        After consideration, we decided that the current solution in the draft was a better trade-off solution.

        Acknowledgment cycle
        announced by group on 20 Jun 2003

        Action history

        Philippe

        The consensus was not to change the specification. The decision needs to be announced.

        arnold2: creating events

        An alternative to creating NS suffixed versions of all the existing init[*]Event methods would be to add a createEventNS() method and set the namespace (and potentially the compatibility flag mentioned in the previous message) at event creation time and use the existing init[*]Event methods to set the remaining parameters.

        I think it would be very unlikely that the inability to change an event's namespace after creation would ever be a significant issue and it would reduce both the size of the spec and the number of interfaces that need to change for DOM L3.

        Transition history

        raised on 14 Aug 2002 by Curt Arnold
        declined on 24 Oct 2002

        Based on the rejection of [Issue arnold1] , and also on the fact that the namespace is part of the event type, this issue has been rejected.

        Acknowledgment cycle
        announced by group on 20 Jun 2003

        gilman1: semantic events

        A requirement that is not met is the ability to attach a description to event handlers registered in the DOM and to be able to access that description when enumerating events for a given element. This requirement, "Access to scripting semantics and activation schemes," was part of the DOM 3 requirements submission by the PF group. Discussions with the DOM and UA working group regarding the DOM 3 event model led us to believe that we would need a more robust mechanism other than simply just adding descriptive text. One such mechanism could be through the use of linked RDF document information. We would like to investigate this more with the DOM working group either for this release of the DOM or the next.

        Discussion history
        18 Sep 2002

        Transition history

        raised on 16 Aug 2002 by Al Gilman, on behalf of Protocols and Formats WG
        declined on 28 Aug 2002

        Semantics need to be addressed at the XML level (i.e. XML Events) first, before we will be able able to address them appropriately in the DOM Events system. Also, while the requirement for semantics was brought up a long time ago, no consensus has been reached between the HTML/WAI/DOM WGs on what to expose exactly through the DOM API (is it RDF? a simple String?). Therefore, we don't think we are in a position to appropriately address this requirement for DOM Level 3 Events unfortunately.

        Acknowledgment cycle
        announced by group on 6 Aug 2003

        Action history

        Ray

        Find the link to his proposal.

        Philippe

        The decision needs to be drafted, but depends on Ray's action item.

        pemberton2: TextEvent

        This interface is horrible. Bound to a keyboard, and a fairly specific one as far as I can see (No 'help' key? Oh, Windows keyboards don't have them!). Why should text be bound to a keyboard? What about speech input? Or a tablet? I think you need a logical text interface before a keyboard interface. And why the inconsistencies between the keyboard in the mouse events, and the one here?

        We did spend an enormous amount of time on our review of the DOM Level 2 Events Specification and, while some of the issues we then raised have been resolved, others have not. We, therefore, ask that you treat our comments of 1999-10-19 as comments on the DOM Level 3 Events Specification.

        Background and related

        This is related to the discussion in the December 1999 meeting.

        Discussion history
        18 Sep 2002, 18 Sep 2002

        Transition history

        raised on 1 Aug 2002 by Steven Pemberton, on behalf of HTML WG
        raised again on 5 Sep 2002 by Misha Wolf, on behalf of Internationalization WG
        agreed on 31 Mar 2003

        The new proposal, the TextEvent and KeyboardEvent interfaces, is a complete new approach for keyboard events. It should satisfy your concerns.

        Acknowledgment cycle
        announced by group on 20 Jun 2003

        lerstad1: DOMAttributeNameChanged

        " DOMAttributeNameChanged: Fired after the namespaceURI and/or the nodeName of a Attr node have been modified (e.g., the attribute was renamed using renameNode). The target of this event is the renamed attribute. "

        shouldn't the target be the element that contains the attr, and relatedNode be the attr? how can bubbling etc. work if the target is the attribute, since the attribute isn't part of the tree..

        Transition history

        raised on 9 Oct 2002 by Sigurd Lerstad
        agreed on 24 Oct 2002

        Correct. This has been clarified in the new draft.

        Acknowledgment cycle
        announced by group on 20 Jun 2003

        allen1: processSubtreeModifiedEvents

        It would be nice if there were a processSubtreeModifiedEvents function that would dispatch DOMSubreeModified events without resorting to employing another thread. I'm using C but I can imagine with Java or any other language it may not aways be easy or practical to make your code thread safe.

        Discussion history
        29 Jan 2003

        Transition history

        raised on 11 Oct 2002 by Michael B. Allen
        declined on 9 Jul 2003

        There's nothing in the spec that says that DOMSubtreeModified needs other threads, or even permits firing the DOMSubtreeModified events on a different thread. Therefore, there is no need to have a processSubtreeModifed function in the DOM Events API.

        Acknowledgment cycle
        announced by group on 24 Jul 2003

        alex1: NodeFiltering system for event listeners

        The suggestion is to add new methods for "filtered" EventListener objects. They would correspond to the addEventListener and removeEventListener methods, but with two additional NodeFilter arguments for the Event object's target and currentTarget properties.

        Discussion history
        5 Feb 2003, 5 Feb 2003, 6 Feb 2003

        Transition history

        raised on 5 Feb 2003 by Alexander J. Vincent
        declined on 7 Mar 2003

        Given that it is possible to implement and address this use case using existing interfaces, it has been not to provide user convenience methods for this use case.

        Acknowledgment cycle
        announced by group on 24 Mar 2003

        duerst1: target ancestor?

        1.2.1 Phase, 1st para: "target ancestor" is misleading, it took me while to understand that it was "ancestor of the target" (or "target's ancestor"), not some ancestor that is qualified as a target. Same comment for other instances of "target ancestor" later on.

        Clarification concerning
        Event Phases

        Transition history

        raised on 15 May 2003 by Martin Duerst, on behalf of Internationalization WG
        agreed on 2 Jul 2003

        Fixed. (now using target's ancestor)

        Acknowledgment cycle
        announced by group on 3 Jul 2003
        agreement by reviewer on 11 Aug 2003

        duerst2: type, category, and group

        1.2.2.1, 1st para: this sentence is hard to understand at this point, as one doesn't know yet what "type", "category" and "group" mean. Looking at the glossary didn't help.

        Clarification concerning
        Registration of event listeners

        Transition history

        raised on 15 May 2003 by Martin Duerst, on behalf of Internationalization WG
        agreed on 2 Jul 2003

        We added pointers to the respective sections.

        Acknowledgment cycle
        announced by group on 3 Jul 2003
        agreement by reviewer on 11 Aug 2003

        duerst3: Event propagation and event groups

        1.2.2.6, 1st para: "The effect could be:" Under what conditions? Under control of the API? At implementer's choice?

        Clarification concerning
        Event propagation and event groups

        Transition history

        raised on 15 May 2003 by Martin Duerst, on behalf of Internationalization WG
        agreed on 2 Jul 2003

        clarified as follows:

        The effect can be:

        • immediate: no more event listeners from the same group will be triggered by the event object (see Event.stopImmediatePropagation());
        • deferred until all event listeners from the same group have been triggered on the current node, i.e. the event listeners of the same group attached on other nodes will not be triggered (see Event.stopPropagation()).
        Acknowledgment cycle
        announced by group on 3 Jul 2003
        agreement by reviewer on 11 Aug 2003

        duerst4: Event types, IRIs, and XML Namespaces

        1.4, 1st para: "The event type is composed of a local name and a namespace URI as defined in [XML Namespaces]." It would be far better to say "namespace name" instead of "namespace URI" and to point normatively to Namespaces 1.1 (http://www.w3.org/TR/xml-names11/), now in CR and therefore referenceable from a WD or CR. One reason is to allow IRIs, another is to buy in all the behaviour defined in Namespaces, instead of paraphrasing it in the Note below the 1st para. This note, also, appears to contain normative language that is made non-normative by being in a Note. Only the last two sentences need to survive, the rest should be farmed out to the Namespaces spec.

        Request concerning
        Event types

        Transition history

        raised on 15 May 2003 by Martin Duerst, on behalf of Internationalization WG
        agreed on 2 Jul 2003

        The language was taken from DOM Level 3 Core and, as said in the Note, no lexical check is done on the namespace URI. The new section 1.3.2 "DOM URIs" (to be published soon, if not already) should clarify the relation between namespace URI, URI, and IRI. The reference to "XML Namespace" was removed in the text and the glossary now defines namespace URIs as follows:

        " A namespace URI is a URI that identifies an XML namespace. This is called the namespace name in Namespaces in XML [XML Namespaces]. See also sections 1.3.2 " DOM URIs" and 1.3.3 " XML Namespaces" regarding URIs and namespace URIs handling and comparison in the DOM APIs. "

        Acknowledgment cycle
        announced by group on 3 Jul 2003
        agreement by reviewer on 11 Aug 2003

        I feel that in both cases (both Core and Events), it would be good to explicitly mention IRIs to make sure developers don't miss that. But I guess I could live with them being only mentioned in Core. (as mentioned by Francois).

        duerst5: resize, scroll, and BasicEvents

        1.4.2: There seems to be a contradiction between the listings for "resize" and "scroll" in the table and the wording in 1.7.6 which place them in the BasicEvents module, not UIEvent.

        Clarification concerning
        Complete list of event types

        Transition history

        raised on 15 May 2003 by Martin Duerst, on behalf of Internationalization WG
        declined on 11 Jun 2003

        The concept of "BasicEvents" was introduced in DOM Level 3, in order to expose the HTML events to XML user agents. Given that conformance and features are defined against the event types and not the DOM interfaces, it is not a contradiction. The name of a feature shouldn't have to do with the name of the interface.

        Acknowledgment cycle
        announced by group on 3 Jul 2003
        agreement by reviewer on 11 Aug 2003

        duerst6: Event.type, NCName, and colon

        1.6, description of the "type" attribute of Event: the 1st sentence says "must be an NCName", second sentence says "(colon) should not be used". This is redundant, except for the "should" and "must" which are not consistent.

        Clarification concerning
        Event.type

        Transition history

        raised on 15 May 2003 by Martin Duerst, on behalf of Internationalization WG
        agreed on 11 Jun 2003

        We changed the two sentences to say:

        "The name should be an NCName as defined in [XML Namespaces] and is case-sensitive."

        Acknowledgment cycle
        announced by group on 3 Jul 2003
        agreement by reviewer on 11 Aug 2003

        duerst7: obtaining a DocumentEvent object

        1.6.1, 1st para in description of the DocumentEvent interface: "It is expected that the DocumentEvent interface will be implemented on the same object..." It would seem that interoperability would require a MUST here. Otherwise, how does one get to the DocumentEvent interface?

        Clarification concerning
        DocumentEvent

        Transition history

        raised on 15 May 2003 by Martin Duerst, on behalf of Internationalization WG
        agreed on 2 Jul 2003

        This section needs updates following the changes to the DOM Level 3 Core. It should read:

        " If the feature "Events" is supported by the Document object, the DocumentEvent interface must be implemented on the same object. If the feature "+Events" is supported by the Document object, an object that supports the DocumentEvent interface must be returned by invoking the method Node.getFeature("+Events", "3.0") on the Document object. "

        Acknowledgment cycle
        announced by group on 3 Jul 2003
        agreement by reviewer on 11 Aug 2003

        duerst8: cut/paste and TextEvent

        1.7.2, issue paste-1: decision seems wrong. An app that wants to be alerted on text input (e.g. to implement something like an incremental search) would miss important input. And what if some voice-to-text software uses the clipboard?

        Request concerning
        TextEvent

        Transition history

        raised on 15 May 2003 by Martin Duerst, on behalf of Internationalization WG
        agreed on 11 Jun 2003

        We added the following sentence to the description of the textInput event:

        "Where a "paste" operation generates a simple sequence of characters, i.e. a text without any structure or style information, this event type should be generated as well."

        Acknowledgment cycle
        announced by group on 3 Jul 2003
        agreement by reviewer on 11 Aug 2003

        duerst9: Do we need initTextEvent?

        1.7.2, initTextEvent: since this interface is new to Level 3, this method appears to be superfluous. One can just call initTextEventNS with a null namespace. Same comment for KeyboardEvent and MutationNameEvent.

        Proposal concerning
        TextEvent.initTextEvent

        Transition history

        raised on 15 May 2003 by Martin Duerst, on behalf of Internationalization WG
        declined on 25 Jun 2003

        Having the non-NS methods is consistent with the rest of the API and, while it could be viewed as superfluous, it doesn't hurt the current design of the API to have them.

        Acknowledgment cycle
        announced by group on 3 Jul 2003
        agreement by reviewer on 11 Aug 2003

        duerst10: init* methods

        1.7.2, description of initTextEvent: it gets really annoying to re-read in each init*Event and each init*EventNS method that "This method may only be called before the UIEvent has been dispatched via the EventTarget.dispatchEvent method, though it may be called multiple times during that phase if necessary. If called multiple times, the final invocation takes precedence." Can't this this factored away somewhere? Also, the ones in TextEvent say "This method has no effect if called after the event has been dispatched.", but not the others, is there a reason?

        Editorial concerning
        TextEvent.initTextEventNS

        Transition history

        raised on 15 May 2003 by Martin Duerst, on behalf of Internationalization WG
        agreed on 2 Jul 2003

        Fixed. Not sure if the new version is an improvement over the previous but at least, it is now consistent.

        Acknowledgment cycle
        announced by group on 3 Jul 2003
        agreement by reviewer on 11 Aug 2003

        duerst11: right Ctrl key and mouse events

        1.7.3, MouseEvent interface: thanks for the addition of altGraphKey, but this is still missing an important modifier, that for the right Ctrl key. This is distinct from the left Ctrl key and is standardized by ISO 9995 as the Group Select key. It is a modifier just like Shift, Alt, etc. It is not the same as the Meta key, some keyboards (notably Macintosh) have both.

        Request concerning
        MouseEvent.ctrlKey

        Transition history

        raised on 15 May 2003 by Martin Duerst, on behalf of Internationalization WG
        declined on 2 Jul 2003

        We don't support right or left in the modifiers. If an application wishes to distinguish right and left controls, it should listen to Keyboard events and get the location when the keyIdentifier is "Control".

        Acknowledgment cycle
        announced by group on 3 Jul 2003
        proposal from reviewer on 11 Aug 2003

        Does the spec say so, or does the reader have to infer that? The spec should say so.

        proposal incorporated by group on 11 Aug 2003

        A note was added for that effect on the getModifierState methods.

        duerst12: right Ctrl key and keyboard events

        1.7.4, KeyboardEvent interface: same comment as above for the missing attribute for the right Ctrl modifier key.

        Request concerning
        KeyboardEvent.ctrlKey

        Transition history

        raised on 15 May 2003 by Martin Duerst, on behalf of Internationalization WG
        Subsumed by issue(s) duerst11 on 2 Jul 2003

        Same response as previous issue.

        duerst13: pressing and releasing modifiers

        1.7.4, KeyboardEvent interface: it should be clarified in this section that the pressing and releasing of modifiers keys are expected to generate events, as the examples in Appendix A show.

        Clarification concerning
        KeyboardEvent

        Transition history

        raised on 15 May 2003 by Martin Duerst, on behalf of Internationalization WG
        agreed on 2 Jul 2003

        Added, in the appendix section on modifiers:

        " Keys associated with modifiers generate, like other keys, "keydown" and "keyup" events [...]. "

        Acknowledgment cycle
        announced by group on 3 Jul 2003
        agreement by reviewer on 11 Aug 2003

        duerst14: key identifiers

        1.7.4, description of "keyIdentifier", says "For a list of *possible* values..." (emphasis mine). This seems to be much too weak, there is no conformance requirement at all and nothing for implementers of DOM applications to rely on. It is possible that a key will generate some identifier as described in Appendix A, but it is also possible that it will generate something else or whatever. What is the poor programmer to do? This needs to be tightened, so that one can have a reasonable expectation that the "Enter" key will generate "Enter", and so on.

        Request concerning
        Keyboard.keyIdentifier

        Transition history

        raised on 15 May 2003 by Martin Duerst, on behalf of Internationalization WG
        agreed on 2 Jul 2003

        Reworded as follows:

        "keyIdentifier holds the identifier of the key. The key identifiers are defined in Appendix A.2 "Key identifiers set". Implementations that are unable to identify a key must use the key identifier "Unidentified"."

        Acknowledgment cycle
        announced by group on 3 Jul 2003
        agreement by reviewer on 11 Aug 2003

        duerst15: key location unknown

        1.7.4 DOM_KEY_LOCATION_UNKNOWN: It seems to be a bad idea to have this at 0x04. Why not e.g. move it up to 0x80, so that there is space for potential future standardization?

        Proposal concerning
        Keyboard.keyLocation

        Transition history

        raised on 15 May 2003 by Martin Duerst, on behalf of Internationalization WG
        agreed on 2 Jul 2003

        This constant has been removed.

        Acknowledgment cycle
        announced by group on 3 Jul 2003
        agreement by reviewer on 11 Aug 2003

        Does this mean that there are no private key locations? If so, that's okay with us.

        duerst16: Unicode notation for key identifiers

        App. A: U+HHHHHH notation: This should use the standard form: At least 4 and at most 6 hex digits, leading digits only for 4-digit form. This means that all identifiers in the spec have to lose two leading zeroes.

        Request concerning
        Key identifiers for keyboard events

        Transition history

        raised on 15 May 2003 by Martin Duerst, on behalf of Internationalization WG
        agreed on 2 Jul 2003

        Fixed. The description now says:

        " "U+0000", "U+0001", ..., "U+FFFFFF" are Unicode based key identifiers ([Unicode]). "

        Acknowledgment cycle
        announced by group on 3 Jul 2003
        agreement by reviewer on 11 Aug 2003

        duerst17: why keydown of a capital letter produces a textInput of a lowercase letter

        A.1: For the first two examples, there should be an explanation why keydown of a capital letter produces a textInput of a lowercase letter. (the example as such is correct because the embossing on the key is usually upper case)

        Proposal concerning
        A.1 Introduction

        Transition history

        raised on 15 May 2003 by Martin Duerst, on behalf of Internationalization WG
        declined on 2 Jul 2003

        Added a link to section A.1.4 instead.

        Acknowledgment cycle
        announced by group on 3 Jul 2003
        agreement by reviewer on 11 Aug 2003

        duerst18: Event groups

        General: There should be an example that shows how event groups can be used. Otherwise, this looks like an unnecessary complication to many readers.

        Clarification concerning
        Event groups

        Transition history

        raised on 15 May 2003 by Martin Duerst, on behalf of Internationalization WG
        declined on 2 Jul 2003

        Given that this is a specification, I don't think if it is the right place for a tutorial on how to use groups. However, I did add a rational to have them in the specification:

        " In general, a DOM application does not need to define and use a separate group unless other event listeners, external to the DOM application, may change the event propagation (e.g. from a concurrent DOM application, from imported functionalities that rely on the event system, etc.). "

        Acknowledgment cycle
        announced by group on 3 Jul 2003
        agreement by reviewer on 11 Aug 2003

        duerst19: CAPS LOCK has a modifier

        Key events: The CAPS LOCK key needs to be added as a modifier. This is used on some Hebrew, Czech, and Swiss German keyboards.

        Request concerning
        KeyboardEvent

        Transition history

        raised on 15 May 2003 by Martin Duerst, on behalf of Internationalization WG
        agreed on 25 Jun 2003

        Correct. The same kind of comments could be made with keys such as NumLock, ScrollLock, ... We decided to introduce an extensible system for modifiers (for MouseEvent, KeyboardEvent):

        boolean getModifierState(String keyIdentifier);

        It will take arguments such as "Alt", "AltGraph", "CapsLock", "Control", "Meta", "NumLock", "Scroll", or "Shift". It returns true if the corresponding modifier is activated, false otherwise. The attribute altGraphKey, introduced in DOM 3, will be dropped. The other convenient attributes (ctrlKey, etc.) will remain. The init methods will contain an extra parameter modifiers, which is a white spaces separated list of modifiers, to be activated. The methods initMouseEventNS, initKeyboardEvent, and initKeyboardEventNS will not longer have the parameters for the convenience attributes.

        Acknowledgment cycle
        announced by group on 3 Jul 2003
        agreement by reviewer on 11 Aug 2003

        duerst20: PDF and Unicode

        A.1, third example: In the PDF version (probably also PS), replace љ by the actual character.

        Request concerning
        PDF version of DOM Level 3 Events

        Transition history

        raised on 15 May 2003 by Martin Duerst, on behalf of Internationalization WG
        declined on 2 Jul 2003

        Unfortunately, html2ps doesn't support the character and except stealing the actual shape from a converter that is able to generate it, I'm not sure how to procede. Helps or advices are welcome.

        Acknowledgment cycle
        announced by group on 3 Jul 2003
        proposal from reviewer on 11 Aug 2003

        Is it possible to add some kind of note here in the PDF/PS versions, so that readers don't get confused, and check the HTML? While we say that the normative version is HTML, I guess implementers often work from a printout.

        proposal incorporated by group on 11 Aug 2003

        done.

        duerst21: examples of keyboard events with different architectures

        A.1: Provide an example (or two contrasting ones) that shows that on different architectures, it may be possible to receive different key events even if the text event(s) are the same.

        Request concerning
        A.1 Introduction

        Transition history

        raised on 15 May 2003 by Martin Duerst, on behalf of Internationalization WG
        declined on 2 Jul 2003

        The proposal relies on keyboard mapping, not specific architectures. Therefore, for the same keyboard mapping, keyboard and text events will be the same, independently of the architecture. No changes were made to the specification.

        Acknowledgment cycle
        announced by group on 3 Jul 2003
        agreement by reviewer on 11 Aug 2003

        duerst24: textInput and NFC

        A.1.2: Clearly say that textInput events should return data in NFC.

        Clarification concerning
        A.1 Introduction

        Transition history

        raised on 15 May 2003 by Martin Duerst, on behalf of Internationalization WG
        agreed on 25 Jun 2003

        Added:

        " Characters should be normalized as defined by the Unicode normalization form NFC. "

        Acknowledgment cycle
        announced by group on 3 Jul 2003
        agreement by reviewer on 11 Aug 2003

        duerst25: Convert and Hiragana

        A.1.3: Pressing the "Convert" key usually will change the Hiragana 'shi' (which is already visible when the user types 'i') into a kanji.

        Editorial concerning
        A.1 Introduction

        Transition history

        raised on 15 May 2003 by Martin Duerst, on behalf of Internationalization WG
        agreed on 2 Jul 2003

        Fixed.

        Acknowledgment cycle
        announced by group on 3 Jul 2003
        agreement by reviewer on 11 Aug 2003

        rehor1: Ordering of Event Groups

        Even though the specification supports ordering of events within a group, it doesn't support the ordering of events between event groups. Some of the requirements we're considering for VoiceXML 3.0 include changes to the 2.0 event model, in particular handling external asynchronous events. One potential use of ordered event groups would be to include 'standard' VoiceXML events in one group, and 'external' asynchronous events in a second group. It may also be useful to enable prioritization of events, assigned by the interpreter developer and possibly even within an application by the developer. For example, external events may need to be handled at a higher priority than other events; on the other hand, it might be necessary in some circumstances to allow the developer to block some or all events by priority.

        Request concerning
        Event groups
        Discussion history
        12 Jun 2003

        Transition history

        raised on 12 Jun 2003 by Ken Rehor, on behalf of VoiceXML WG
        declined on 2 Jul 2003

        Status Quo. we won't prevent them from doing as an extension.

        Acknowledgment cycle
        announced by group on 24 Jul 2002

        rehor2: Event selection

        An event handler is selected (see sect 5.2.4 "Catch Element Selection") based on several conditions that are evaluated at the event throw time. The count attribute specifies the occurance for that event; the cond attribute is an ECMAScript expression which specifies whether the event applies at that time.

        Request concerning
        Catch element
        Discussion history
        12 Jun 2003

        Transition history

        raised on 12 Jun 2003 by Ken Rehor, on behalf of VoiceXML WG
        declined on 9 Jul 2003

        One can imagine lots of possible conditions and the count attribute is only one possibility. Implementing the count attribute functionality on top of a DOM generic implementation is very easy to do: it requires introducing a wrapper on top of the event listener in order to take care of the count. Therefore, we decided to not address this use case.

        Acknowledgment cycle
        announced by group on 24 Jul 2002

        rehor3: Hierarchical Namespace

        In Section 1.5.3, you discuss the concept of the hiearchical name spaces that we've included in VoiceXML, but it isn't clear how this is compatible with your specification. We have found it to be a very powerful mechanism for selecting categories of events, or as needed, subcategories as well. It would be helpful to have the DOM Events spec support this.

        Request concerning
        Using VoiceXML Events
        Discussion history
        12 Jun 2003

        Transition history

        raised on 12 Jun 2003 by Ken Rehor, on behalf of VoiceXML WG
        declined on 9 Jul 2003

        The DOM Event model do support the concept of hierarchy support, as shown in section 1.5.3. It is called event categories in the DOM Event Model. However, the DOM API itself does not expose those DOM Event categories i.e. you have no ability to register an event listener for a specific event category (as mentioned in section 1.5.1). Again, implementing event categories on top of a DOM generic implementation would require modifying the underlying implementation first since it modifies the dispatch. We didn't see enough interest for the moment to impose this new set of functionalities to all DOM generic implementations. Therefore, we decided to not address this requirement.

        Acknowledgment cycle
        announced by group on 24 Jul 2002

        Maintained by DOM Working Group.

        Last update: $Date: 2003/10/31 18:12:35 $