W3C home > Mailing lists > Public > public-xformsusers@w3.org > March 2015

ACTION-1993: Analyse which events should also go to dialog

From: Erik Bruchez <erik@bruchez.org>
Date: Tue, 3 Mar 2015 15:21:58 -0800
Message-ID: <CAAc0PEXvb7OEuo7KhVAqd3bsU9z++eGYLE3Ws6wQS2jsG+sgsQ@mail.gmail.com>
To: Forms WG <public-forms@w3.org>, "public-xformsusers@w3.org" <public-xformsusers@w3.org>
All,

Action item from [this call][1] regarding the review of section 10.
>From [my original email][2]:

> Events dispatched to the `group` or `switch` element should
> probably also be dispatched to `dialog element. Search for
> "group|switch", "<group>, <repeat>", and "group or switch".

I think the only events make sense for xforms-dialog is `xforms-focus`!

Because the dialog doesn't have a binding, I don't think it should
receive xforms-valid/invalid and other MIP events. Being a top-level
control, it probably shouldn't receive xforms-enabled/disabled.

DOMFocusIn/DOMFocusOut are unclear. The spec mentions that
"group|switch|repeat" can receive it. But I am unclear why. Further,
DOMFocusIn/DOMFocusOut are deprecated in the latest [UI Events
Specification (formerly DOM Level 3 Events)][3].

If all grouping controls can receive DOMFocusIn/DOMFocusOut, then
<dialog> should as well.

NOTE: Our implementation dispatches DOMFocusIn/DOMFocusOut to
container controls to indicate the focus has left the container
control. But I am not sure that is implied by DOM or XForms.

Related: in "10.3.6 The xforms-next and xforms-previous Events", there
is mention of <group>, <repeat>, and <switch>. If this section remains
as is, then <dialog> should be added to that list.

-Erik

[1] http://www.w3.org/2015/01/21-forms-minutes.html
[2] http://lists.w3.org/Archives/Public/public-forms/2015Jan/0013.html
[3] https://dvcs.w3.org/hg/dom3events/raw-file/tip/html/DOM3-Events.html#event-type-DOMFocusIn
Received on Tuesday, 3 March 2015 23:22:45 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 3 March 2015 23:22:45 UTC