This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
In table (5.1.1 List of DOM3 Event Types) beforeinput event has this: Default Action: None But definition beforeinput event has some default action (https://dvcs.w3.org/hg/dom3events/raw-file/tip/html/DOM3-Events.html#event-type-beforeinput). Definition table for beforeinput and input should have this (in Context info) UIEvent.view UIEvent.detail All event types implement (or inherit) UIEvent list this property in their tables. And this tables should also include InputEvent.isComposing attribute. InputEvent.data description in table probably is not complete (when comparing with HTML5). In HTML5 we have only input event type, and it can be fired additionally for input type=checkbox/type=radio or select, and in this case what value is appropriate - empty string or null? On the other hand, HTML5 does not take into account the InputEvent interface for input event (just inherit from Event). At now only Firefox started implement this interface (with some objection due to the HTML5: https://bugzilla.mozilla.org/show_bug.cgi?id=970802). According above HTMLSelectElement should be trate as a target for this event type. In description for data attribute we have: [data of type DOMString, readonly ...This attribute MAY be null or contain the empty string.] What exactly means null? If nullable type then definition in interface and dictionary should have '?' after DOMString (DOMString?).
I'll take a look a this one...
About 'data' and nullable type: CompositionEvent.data << nullable InputEvent.data << not nullable All other DOMString attributes are not nullable. In all cases default is empty string and wondering if null is really returned in any case for above attributes. And in the very similar case: partial interface CompositionEvent { // Originally introduced (and deprecated) in DOM Level 3 void initCompositionEvent (DOMString typeArg, boolean bubblesArg, boolean cancelableArg, Window? viewArg, DOMString? dataArg, DOMString? locale); }; "locale" in this method is nullable, but in UIEvents not (https://dvcs.w3.org/hg/d4e/raw-file/tip/source_respec.htm#composition-event-interface).
I check this more closely and: === In initCompositionEvent() DOMString? locale >> should be change to DOMString locale Created untrusted event (with locale = null in initCompositionEvent or constructor) and getting e.locale return string. <script> var ev = document.createEvent("CompositionEvent"); ev.initCompositionEvent("hellow", true, true, window, null, null); document.write(ev); document.write("<br>"); document.write(ev.locale === null); // false (IE/Firefox, Chrome doesn't suport .locale) </script> === .data is more interesting, now we don't have suport it on InputEvent interface, but work in CompositionEvent interface (in FF, Chrome, IE). Below works only in Chrome <script> var ev = new CompositionEvent("hello", { data: null }); document.write(ev); document.write("<br>"); document.write(ev.data === null); // false </script> Below works in Chrome/IE and Firefox <script> var ev = document.createEvent("CompositionEvent"); ev.initCompositionEvent("hellow", true, true, window, null, null); document.write(ev); document.write("<br>"); document.write(ev.data === null); // false (IE/Chfome), true (Firefox) </script> Only Firefox respect nullable and I wonder if it should be for some reason, or just a small mistake in the specification that has been implemented.
(In reply to spiritRKS1910 from comment #0) > In table (5.1.1 List of DOM3 Event Types) beforeinput event has this: > Default Action: > None > > But definition beforeinput event has some default action > (https://dvcs.w3.org/hg/dom3events/raw-file/tip/html/DOM3-Events.html#event- > type-beforeinput). Yep. I will make this consistent. > Definition table for beforeinput and input should have this (in Context info) > > UIEvent.view > UIEvent.detail > > All event types implement (or inherit) UIEvent list this property in their > tables. I will add these. Good find. > And this tables should also include InputEvent.isComposing attribute. Yep. This was added recently, but we forgot to update the tables. Good catch. > InputEvent.data description in table probably is not complete (when > comparing with HTML5). In HTML5 we have only input event type, and it can be > fired additionally for input type=checkbox/type=radio or select, and in this > case what value is appropriate - empty string or null? On the other hand, > HTML5 does not take into account the InputEvent interface for input event > (just inherit from Event). At now only Firefox started implement this > interface (with some objection due to the HTML5: > https://bugzilla.mozilla.org/show_bug.cgi?id=970802). > > According above HTMLSelectElement should be trate as a target for this event > type. I think I will make this more generic, limiting the trusted event targets to "Element" and then in the event definition, calling out that these are control type elements as well as contenteditable element. The umbrella "Element" covers all these cases.
Regarding nullable DOMString locale and data: I think that these all need to be non-nullable, and that the prose indicating that it can be null needs to be changed to match the IDLs. I'll do a pass through these to make sure that they are consistent.
I've made these fixes now. Changelist: https://dvcs.w3.org/hg/dom3events/rev/937b13a68529
Still exist in Input: [data of type DOMString, readonly ...This attribute MAY be null or contain the empty string.] Just [This attribute MAY be the empty string.] like in CompositionEvent.
Great catch. I think I have them all now: https://dvcs.w3.org/hg/dom3events/rev/14b8c9f6caa0