Re: [dialog element] need another name for "visible" attribute

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.com

http://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)