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.
Color key: error warning note
Id: Title | State | Type | Open actions | Ack. |
---|---|---|---|---|
pettit1 : Description of Event flow | declined | clarification | Agreement | |
pettit2 : Event listeners activation | agreed | clarification | Agreement | |
pettit3 : Event capture | agreed | editorial | Agreement | |
pettit4 : HTML events | agreed | clarification | Proposal incorporated | |
pettit5 : Event Creation | agreed | error | Agreement | |
pettit6 : Mouse event | declined | request | No reply from reviewer | |
pettit7a : Text events | declined | error | Agreement | |
pettit7b : Text events | declined | error | Agreement | |
pettit7c : Text events | agreed | error | Agreement | |
pettit7d : Text events | agreed | clarification | Agreement | |
pettit7e : Text events | agreed | clarification | Agreement | |
pettit8 : Mutation event types | agreed | error | Agreement | |
pettit9 : HTML event types | declined | request | Agreement | |
schiemann1 : Range.cloneNodes and event listeners | agreed | clarification | No reply from reviewer | |
schiemann2 : extractNodes and event listeners | agreed | clarification | No reply from reviewer | |
flanagan1 : TextEvent.visibleOutputGenerated definition | declined | clarification | Agreement | |
flanagan2 : CustomEvent definition | agreed | clarification | Proposal incorporated | |
codding1 : CustomEvent definition | agreed | request | No reply from reviewer | |
pemberton1 : default action | declined | error | No reply from reviewer | |
arnold1 : namespace support | declined | request | No reply from reviewer | |
arnold2 : creating events | declined | request | No reply from reviewer | |
gilman1 : semantic events | declined | request | No reply from reviewer | |
pemberton2 : TextEvent | agreed | error | No reply from reviewer | |
lerstad1 : DOMAttributeNameChanged | agreed | error | No reply from reviewer | |
allen1 : processSubtreeModifiedEvents | declined | request | No reply from reviewer | |
alex1 : NodeFiltering system for event listeners | declined | request | No reply from reviewer | |
duerst1 : target ancestor? | agreed | clarification | Agreement | |
duerst2 : type, category, and group | agreed | clarification | Agreement | |
duerst3 : Event propagation and event groups | agreed | clarification | Agreement | |
duerst4 : Event types, IRIs, and XML Namespaces | agreed | request | Agreement | |
duerst5 : resize, scroll, and BasicEvents | declined | clarification | Agreement | |
duerst6 : Event.type, NCName, and colon | agreed | clarification | Agreement | |
duerst7 : obtaining a DocumentEvent object | agreed | clarification | Agreement | |
duerst8 : cut/paste and TextEvent | agreed | request | Agreement | |
duerst9 : Do we need initTextEvent? | declined | proposal | Agreement | |
duerst10 : init* methods | agreed | editorial | Agreement | |
duerst11 : right Ctrl key and mouse events | declined initial suggestion, agreed on follow-up | request | Proposal incorporated | |
duerst12 : right Ctrl key and keyboard events | subsumed [duerst11] | request | ||
duerst13 : pressing and releasing modifiers | agreed | clarification | Agreement | |
duerst14 : key identifiers | agreed | request | Agreement | |
duerst15 : key location unknown | agreed | proposal | Agreement | |
duerst16 : Unicode notation for key identifiers | agreed | request | Agreement | |
duerst17 : why keydown of a capital letter produces a textInput of a lowercase letter | declined | proposal | Agreement | |
duerst18 : Event groups | declined | clarification | Agreement | |
duerst19 : CAPS LOCK has a modifier | agreed | request | Agreement | |
duerst20 : PDF and Unicode | declined initial suggestion, agreed on follow-up | request | Proposal incorporated | |
duerst21 : examples of keyboard events with different architectures | declined | request | Agreement | |
duerst24 : textInput and NFC | agreed | clarification | Agreement | |
duerst25 : Convert and Hiragana | agreed | editorial | Agreement | |
rehor1 : Ordering of Event Groups | declined | request | No reply from reviewer | |
rehor2 : Event selection | declined | request | No reply from reviewer | |
rehor3 : Hierarchical Namespace | declined | request | No reply from reviewer |
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?
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.
"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.
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."
" 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?
"Generally the document" has been removed.
" 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.
We should change the sample in section 1.3 to make it less miss-leading.
The new Section 1.7.7.1 should now clarify this.
How about changing "If a change is made before the activation," to "If a DOM property is changed before the event is fired,"
Changed to "If a DOM attribute is changed before the event is fired,"
CustomEvent -- What is the use case for SetEventPhase? Can preventDefault or stopPropagation be called during execution of that method.
An Event
cannot be dispatch twice
simulteously in the DOM tree. An exception has been added
for that effect in the specification.
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.
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).
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.
The numPad
property on TextEvent
is the difference.
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?
If initTextEvent is called with incorrect values it may fire with incorrect values. Validation is left to the author.
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."
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
.
"
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.
We should had the clarification that canceling a keyDown has no effect on a textEvent.
Canceling keyDown or keyUp (using Event.preventDefault) does cancel the textInput event.
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.
The issue was revisited.
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. "
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.
The issue was revisited.
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.
test implementations on this and report.
In what case would visibleOutputGenerated be TRUE for any TextEvent other than textInput?
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.
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?
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.
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.
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.
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.
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.
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.
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.
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.
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.
visibleOuputGenerated
has been removed from
the TextEvent
interface since it was device
dependent (display related).
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.
Section 1.6.1 has been rewritten.
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.
reworded a bit the sentences.
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
).
A readonly boolean attribute isCustom was added on the
Event
interface. This attribute is true if
the event object implements the CustomEvent interface.
""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.
DOM2 did define when a default action gets invoked and any other interpretation was wrong. No change in the specification.
" 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}.
After consideration, we decided that the current solution in the draft was a better trade-off solution.
The consensus was not to change the specification. The decision needs to be announced.
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.
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.
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.
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.
The decision needs to be drafted, but depends on Ray's action item.
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.
This is related to the discussion in the December 1999 meeting.
The new proposal, the TextEvent
and
KeyboardEvent
interfaces, is a complete new
approach for keyboard events. It should satisfy your
concerns.
" 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..
Correct. This has been clarified in the new draft.
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.
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.
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.
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.
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.
Fixed. (now using target's ancestor)
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.
We added pointers to the respective sections.
1.2.2.6, 1st para: "The effect could be:" Under what conditions? Under control of the API? At implementer's choice?
clarified as follows:
The effect can be:
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.
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. "
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).
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.
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.
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.
We changed the two sentences to say:
"The name should be an NCName as defined in [XML Namespaces] and is case-sensitive."
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?
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. "
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?
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."
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.
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.
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?
Fixed. Not sure if the new version is an improvement over the previous but at least, it is now consistent.
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.
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".
Does the spec say so, or does the reader have to infer that? The spec should say so.
A note was added for that effect on the getModifierState methods.
1.7.4, KeyboardEvent interface: same comment as above for the missing attribute for the right Ctrl modifier key.
Same response as previous issue.
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.
Added, in the appendix section on modifiers:
" Keys associated with modifiers generate, like other keys, "keydown" and "keyup" events [...]. "
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.
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"."
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?
This constant has been removed.
Does this mean that there are no private key locations? If so, that's okay with us.
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.
Fixed. The description now says:
" "U+0000", "U+0001", ..., "U+FFFFFF" are Unicode based key identifiers ([Unicode]). "
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)
Added a link to section A.1.4 instead.
General: There should be an example that shows how event groups can be used. Otherwise, this looks like an unnecessary complication to many readers.
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.). "
Key events: The CAPS LOCK key needs to be added as a modifier. This is used on some Hebrew, Czech, and Swiss German keyboards.
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.
A.1, third example: In the PDF version (probably also PS), replace љ by the actual character.
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.
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.
done.
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.
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.
A.1.2: Clearly say that textInput events should return data in NFC.
Added:
" Characters should be normalized as defined by the Unicode normalization form NFC. "
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.
Fixed.
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.
Status Quo. we won't prevent them from doing as an extension.
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.
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.
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.
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.
Last update: $Date: 2003/10/31 18:12:35 $