RE: Xforms appearances without stylesheets

Hello Richard,

> > Question: Actual item appearance. While the standard says we can use
> > 	appearance=full | simple | QName-but-not-NCName
> >  I haven't found much on what the final tag is for?  Can we overload

> > this to provide a series of extended input display styles  eg, 
> > "radio", "tickbox", or does it have another purpose?  To clarify,
the 
> > simple sex entry of M/F can be presented to the user in many
different 
> > styles, and the list of full/simple is potentially not strongly 
> > defined enough for some of our customer requirements.

@appearance is just a 'hint' to the output device, by the author, of
what they would like to happen when their form is rendered. An author
may think that a list of choices to choose from is so short, that they
would prefer that they were all available at the same time for the user,
and so might use @appearance="full". If the question is "are you a
smoker or non-smoker?", the choices might be "smoker" and "non-smoker",
and with such a short list, the author may want the user to be aware of
all choices without having to do anything. On a visual browser, using
radion buttons would certainly be a good way to go, since many users
would be familiar with their operation. The user does not need to click
anything to see the choices - they are in view all the time. In a voice
system the operation would obviously be different, but it might be
something like, every time a user gets to this question the system would
'read' all of the choices before letting the user choose.

In a similar vein, the author may decide that @appearance="minimal" is
more appropriate. If the list is large, such as a set of countries, then
a visual renderer would lose most of its screen real estate if it had to
show the choices available! Similarly, if every time a user accessing a
form via a telephone had to listen to all of the choices before they
were allowed to choose you wouldn't sell many cinema tickets. So in the
case of minimal, we might simply say that the choices are not available
to the user until they ask for them - by clicking the down arrow on a
combobox, or saying "more" to a voice system.

But note that none of this is more than a hint. If a PDA were to
implement all selections as if they were @appearance="minimal", it would
not be 'breaking' the XForms 1.0 specification. But the fact that they
are hints, and that they are of a device-agnostic nature, should at
least make it clear that @appearance="red", @appearance="loud" or
@appearance="checkbox" are *not* good choices for further values (as
Joern rightly says in his response to you).

> > The options I can see are:
> > a)	appearance="our-style-name"
> right - that's an option and maybe the best - but you should carefully

> choose the values for this attribute - XForms gives a hint here - 
> 'full,compact,minimal' do not imply any specific visual qualities but 
> can also be applied to e.g. voice applications.

The only thing I would just flag up is that your choices need to be
namespace qualified. For various reasons to do with standardisation, the
XForms specification needs to preserve non-prefixed and 'xforms:' values
for itself. For example, say everyone agreed that we need a particular
style of xf:repeat that had all the labels at the top, like a grid. This
might be added to a future version of XForms as either:

	appearance="grid"

or:

	appearance="xforms:grid"

If you have used the value 'grid' for your own forms to specify
something different, then you run the risk of making your forms
non-interoperable.


A few last things:

(1) If you have CSS2 selectors in your application, then obviously
@appearance becomes much more useful as a UI 'switch'.

(2) Look at whether you can 'switch' the UI being rendered on the basis
of schema type. This is a very good way of going, and gives a lot of
power and flexibility. See the date and boolean types in XForms 1.0.

Regards,

Mark


Mark Birbeck
CEO and CTO
x-port.net Ltd.

When you need a 100% standard Xforms processor:

	http://www.formsPlayer.com/

Received on Thursday, 20 November 2003 17:50:39 UTC