Just furthering the discussion...
The use case seems to be more around modeless dialogs that the author
wants to be available when the form starts. It's harder to imagine
starting a form off with a modal dialog, but it would be feasible. We'll
have some trouble dealing with what is supposed to happen if more than one
modal dialog is indicate as being opened on form start.
The "visible" attribute actually corresponds to whether it should be open
on construction, so it's not really related to xforms-ready. With a
switch, you have to know that the processor will construct one and show
you a particular case on startup. Similarly, this feature talks about
what initial UI creation will do with the dialog. So, although it's not
really more techie than what you have to know about switch, we're still
working on deprecating the selected attributes of case anyway, in
preference to something that is more data-centric and less specific to UI
initialization.
The particular name 'visible' is not very good because it is like
'selected' on case. The name does not really imply that the attribute is
saying something about how the dialog interacts with initial construction
of the form. In this regard, using another value for the appearance
attribute is also not too desirable because appearance also seems to hint
at something stable throughout the life of the dialog rather than
something that is processed at a moment in time in the startup of the
form. A horrible but nonetheless better name would be something like
showonformstart="true".
I thought I'd send an email to see if a better name showed up, but this
feature seems relatively low on the demand-o-meter and relatively high on
the picky-techie-detail-o-meter, to the point where <show
ev:event="xforms-ready" dialog="X" /> does not really seem out of place.
We could add something in the future to make "open on startup" dialogs
easier in the future if we see a lot of demand for that specific pattern.
But as Mark is pointing out, it might be better to see what the real
patterns are before we encode such picky features with more and more
attributes. Knobs and dials are good, but too many of them makes the
machine unwieldy.
Cheers,
John M. Boyer, Ph.D.
STSM, Interactive Documents and Web 2.0 Applications
Chair, W3C Forms Working Group
Workplace, Portal and Collaboration Software
IBM Victoria Software Lab
E-Mail: boyerj@ca.ibm.com
Blog: http://www.ibm.com/developerworks/blogs/page/JohnBoyer
Blog RSS feed:
http://www.ibm.com/developerworks/blogs/rss/JohnBoyer?flavor=rssdw
From:
Mark Birbeck <mark.birbeck@webbackplane.com>
To:
Nick Van den Bleeken <Nick_Van_den_Bleeken@inventivegroup.com>
Cc:
John Boyer/CanWest/IBM@IBMCA, "public-forms@w3.org" <public-forms@w3.org>
Date:
07/30/2009 03:41 AM
Subject:
Re: [dialog element] need another name for "visible" attribute
Hi Nick,
> I'm a bit concerned with using the attribute appearance for something
more as
> a rendering hint. Correct my if I'm wrong, but is appearance until now
not just a
> hint to the user agent about how the control could be rendered. I.e. it
doesn't
> drives the availability of a UI control, for your case a 'splashpage' it
probably
> doesn't matter if the dialog isn't showed at all. In the case we were
talking about
> on the phone, a modeless dialog that needs be shown at startup, it
probably
> would matter if the dialog is shown or not, so ignoring the appearance
attribute
> may make a form unusable.
Sure...except...
> Here is a link to what we currently have
http://www.w3.org/MarkUp/Forms/wiki/Dialog
...the @close value is based on the value of @appearance. So if you
can ignore @appearance, you could in theory end up with an uncloseable
dialog.
Anyway, the key point I'm making is that rather than creating very
literal attributes, that precisely define some behaviour, we might
consider asking why we want the behaviour in the first place, and see
if we can't put a layer over it.
To me, an attribute that means 'make a dialog visible after
xforms-ready' seems very techie. It requires you to understand dialogs
and 'xforms-ready', which in turn requires that you understand events.
An attribute value that means 'this dialog is a splash-page', only
requires you to understand dialogs.
How we achieve that is of course a separate question. We've talked in
the past about using @role to indicate the *purpose* of an element,
which is 'stronger' than the hint provided by @appearance.
By the way, I'm not saying this is the only solution. I'm merely
saying that we might want to go one level up, rather than simply
looking for another name for @visible.
But another solution would be to simply use @selected, from
switch/case -- it at least has the advantage of consistency.
Anyway, just some thoughts. :)
Regards,
Mark
--
Mark Birbeck, webBackplane
mark.birbeck@webBackplane.comhttp://webBackplane.com/mark-birbeck
webBackplane is a trading name of Backplane Ltd. (company number
05972288, registered office: 2nd Floor, 69/85 Tabernacle Street,
London, EC2A 4RR)