- From: David Landwehr <david.landwehr@solidapp.com>
- Date: Tue, 28 Mar 2006 10:54:18 +0200
- 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 UTC