FW: Events review part II: 4.3 Interaction Events

As we've discussed previously, there are problems with default processing and bubbling in events, but I had also other questions
while reviewing.

4.3 Interaction Events

4.3.1 DOM Mutation Events
MH: Editorial: Not all DOM mutation events bubble. Change:
Bubbles: Varies (see DOM events)

4.3.2 xforms:next and xforms:previous
MH: Substantive: Default processing should happen only at the target. These events should not bubble, otherwise the default
processing will be done both in the control and e.g. in the enclosing group element.

4.3.3 xforms:focus and xforms:blur
MH: Substantive:
-	As discussed, focus event should not bubble.
-	Default processing: Set focus to the target control
-	Questions: What does blur’s default processing do? Which control will have focus after blur? What are the semantics in HTML’s blur
event?
-	We could use DOMfocusin DOMfocusout for notification purposes
http://www.w3.org/TR/2000/REC-DOM-Level-2-Events-20001113/events.html#Events-eventgroupings-uievents

4.3.4 xforms:activate
MH: Question:Why don’t we use DOMActivate? The semantics seem the same
http://www.w3.org/TR/2000/REC-DOM-Level-2-Events-20001113/events.html#Events-eventgroupings-uievents

4.3.5 xforms:valueChanging
MH: Question:What is the use for this event? It seems useless for the user, since there is no possibility to read the value before
it is changed to the instance. Maybe its an system internal event?

4.3.6 xforms:valueChanged
MH: Question: what happens if the user cancels the event? What will be the value in the control & in instance?
Editorial: Tense: Event XXX has been dispatched -> Event XXX is dispatched

4.3.7 xforms:scrollFirst
MH: This seems ok

4.3.8 xforms:scrollLast
MH:  This seems ok.

4.3.9 xforms:insert and xforms:delete
MH: Substantive: What is the difference between DOM mutation events and these? I think we could just use DOMNodeInserted and
DOMNodeRemoved instead of these.

4.3.10 xforms:select and xforms:deselect
MH: These seem ok as notification events

4.3.11 xforms:help and xforms:hint
MH : Substantive: I think these could be action events, so that the user could dispatch this to a form control and make it show its
help or hint? Then it should have:
Bubbles: No (Other option: it bubbles, and the first handler stops propagation.)
Default Processing: The UA should invoke the help or hint message connected to the target Form Control.

4.3.12 xforms:alert
MH: Substantive:
Default processing should happen only at the target. This should not bubble.
Other option: it bubbles, and the first handler stops propagation.

4.3.13 xforms:valid
MH: Seems ok as a notification event.

4.3.14 xforms:invalid
MH: Substantive: Default processing should happen only at the target. This should not bubble.

4.3.15 xforms:refresh
MH: Substantive: Default processing should happen only at the target. This should not bubble. Note: In X-Smiles all instance changes
are automatically updated to the form controls, so this event is not needed.

4.3.16 xforms:revalidate
MH: Substantive: This is an event with default processing only at its target, so it should not bubble
Note: In some implementations, this event may be useless. E.g. In X-Smiles, all value changes in the instance are immediately
revalidated

4.3.17 xforms:recalculate
MH: Substantive: This is an event with default processing only at its target, so it should not bubble
In some implementations, this event may be useless. E.g. In X-Smiles, all value changes in the instance result in immediate
recalculation

4.3.18 xforms:reset
MH: Substantive: This is an event with default processing only at its target, so it should not bubble

-mikko

Received on Monday, 4 February 2002 04:31:51 UTC