W3C home > Mailing lists > Public > www-forms@w3.org > March 2006

Re: Context menus in XForms

From: David Landwehr <david.landwehr@solidapp.com>
Date: Tue, 28 Mar 2006 10:54:18 +0200
Message-ID: <4428F9BA.7040602@solidapp.com>
To: Oskari.Koskimies@nokia.com
Cc: www-forms@w3.org


>> 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
--------------------------------------------
Received on Tuesday, 28 March 2006 08:54:29 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 10 March 2012 06:22:03 GMT