Re: Context menus in XForms

Note that XForms on a mobile  device should not *require* CSS
support, however features accessed via CSS like settings could
still be implemented on such a device with a "hard-wired"
stylesheet.

i.e. the client behaves "as if a particular CSS definition wer
ein effect".



David Landwehr writes:
 > 
 > 
 > >> I think it might be a problem having appearance="softkey" as 
 > >> that make the appearance attribute specific to the mobile UI 
 > >> and only make little sense on a desktop machine (browser user 
 > >> agents don't normally use the
 > >> F1-F12 and show a meaning full description, I guess AS-400 
 > >> systems does something like that). Maybe it could get that 
 > >> styling information from a CSS stylesheet. Since authors can 
 > >> use the @media to apply different properties depending on the 
 > >> user agent it will make that solution flexible? Could the 
 > >> softkeys actually be selected using the accesskey attribute?
 > >>     
 > >
 > > I don't see it as a styling issue because there is a more fundamental
 > > user interaction question of which options are shown immediately and
 > > which require further action from the user to be seen. Also, if XForms
 > > is used by a separate mobile forms application instead of being built
 > > into the browser (an important use case for mobiles), there is no CSS
 > > support. I therefore would prefer not to have any usability-enhancing
 > > features in XForms that can only be accessed via CSS.
 > >
 > >   
 > Fair enough that XForms does not require the user agent to have CSS 
 > support. All I wanted to have was another way of assigning the hint for 
 > the rendering which was a less general hint.
 > > In general, I don't see it as a problem if a certain type of user agent
 > > does not support a specific value of the apperance attribute, because it
 > > is only a hint. 
 > I think the problem will be that an author can only give a single hint. 
 > If the appearance attribute could contain a list of hints it would be 
 > just fine. But since it can only have a single hint it will force the 
 > author to make a hint for a specific user client.
 > > There is nothing to prevent a browser-based XForms
 > > implementation from implementing soft keys either, e.g. by showing their
 > > labels in the status bar. However, the value should perhaps be called
 > > something else than "softkey" which is indeed mobile-specific. There is
 > > not really any need for the reverse ("options") value either, because
 > > that would be the default. One could either invent a new value, e.g.
 > > "immediate" (because the option is shown immediately, without need for
 > > further action) or one could reuse the select1 appearance values, with
 > > "full" meaning "use softkey if feasible", and other values meaning "put
 > > in separate options menu", and default appearance being "minimal".
 > >
 > > BR,
 > >      --Oskari
 > >   
 > I agree that the actual rendering is up to the user agent. However 
 > authors have a urge to want to control the user interface. My problem is 
 > that if I had to implement appearance="immediate" in a html+xforms 
 > browser it would be unclear for me how that should look like (e.g. if my 
 > browser was Firefox).
 > 
 > Best regards,
 > David
 > 
 > -- 
 > --------------------------------------------
 > David Landwehr (david.landwehr@solidapp.com)
 > Chief Executive Officer, SolidApp
 > Web: http://www.solidapp.com
 > Office: +45 48268212
 > Mobile: +45 24275518
 > --------------------------------------------
 > 

-- 
-- T. V. Raman

Received on Tuesday, 28 March 2006 16:14:35 UTC