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

Re: Output to the user

From: Erik Bruchez <ebruchez@orbeon.com>
Date: Tue, 28 Feb 2017 21:53:49 -0800
Message-ID: <CAAc0PEWcY8g3xqHfVHzq+NtWqjyeqZcWtUgVmvEp86=PFJV4XQ@mail.gmail.com>
To: Steven Pemberton <steven.pemberton@cwi.nl>
Cc: XForms <public-xformsusers@w3.org>
All,

I think we can make a case for a dialog control.

`dialog` is a more semantic element name. This is consistent with the
choice of different element names for `select`, `select`, `input`,
`textarea`, etc.

We could argue that we could have:

    <input multiline="true">

and get a textarea, or:

    <input section="single">
      <itemset>

and get a `select1`.

I can see the case made for those as well, it is not ridiculous at all, but
XForms chose different element names.

I would argue that a dialog:

- is a well-enough understood control/component/UI concept
- is different enough from `group`, `switch`, and other controls

to deserve its own element name.

This said, I realize that there is not a single answer to this.

-Erik

On Wed, Feb 22, 2017 at 5:36 AM, Steven Pemberton <steven.pemberton@cwi.nl>
wrote:

> We have three ways of outputting to the user:
>
> 1. Control <output/> with @ref and @value
>    Attribute: @appearance
>    Extra attribute: @mediatype
>
> 2. Action <message/> with @ref and @value
>    Extra attribute: level (modal, modeless, ephemeral)
>
> 3. Control <dialog/>
>    Attribute: @appearance
>    Extra attributes: level (as above), hide (true/false).
>
>    + 2 new actions <show/> <hide/>
>    + 2 new events  xforms-dialog-show, xforms-dialog-hide
>
> What worries me about these is the lack of consistency, and the lack of
> underlying model.
>
> Visibility is (nearly) always controlled by relevance in XForms, and from
> that point of view, I don't really see the advantage of <dialog/> over what
> we already have, with an extra layer of generality.
>
> For instance, instead of
>
> <dialog id="my-dialog" label="Please enter your information">
>   <input ref="first-name" label="First Name:"/>
>   <input ref="last-name"  label="Last Name:"/>
>   <input ref="e-mail" label="E-mail:"/>
>   <trigger label="Submit">
>     <hide ev:event="DOMActivate" dialog="my-dialog"/>
>   </trigger>
> </dialog>
>
> why not
>
> <group level="modal" ref="visible" label="Please enter your information">
>   <input ref="first-name" label="First Name:"/>
>   <input ref="last-name"  label="Last Name:"/>
>   <input ref="e-mail" label="E-mail:"/>
>   <trigger label="Submit">
>     <setvalue ev:event="DOMActivate" ref="visible" value="0"/>
>   </trigger>
> </group>
>
> or
>
> <switch level="modal" label="Please enter your information">
>   <case id="hidden"/>
>   <case id="visible">
>      <input ref="first-name" label="First Name:"/>
>      <input ref="last-name"  label="Last Name:"/>
>      <input ref="e-mail" label="E-mail:"
>      <trigger label="Submit">
>        <toggle ev:event="DOMActivate" case="hidden"/>
>      </trigger>
> </switch>
>
> (or the equivalent @caseref version).
>
> That is to say, all these new examples have done is added @level in order
> to make the control modal. No new actions, no new events, same effect.
>
> Steven
>
>
Received on Wednesday, 1 March 2017 06:56:48 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:37:47 UTC