W3C home > Mailing lists > Public > public-device-apis@w3.org > October 2009

Re: ISSUE-16: Gathering requirements [User Interaction API]

From: Robin Berjon <robin@robineko.com>
Date: Fri, 23 Oct 2009 15:24:38 +0200
Cc: Device APIs and Policy Working Group WG <public-device-apis@w3.org>
Message-Id: <F10721EC-F63C-4DA4-AB44-17CA08A8EB6F@robineko.com>
To: Anssi Kostiainen <anssi.kostiainen@nokia.com>
On Oct 22, 2009, at 15:21 , Anssi Kostiainen wrote:
> On 20.10.2009, at 16.50, ext Robin Berjon wrote:
>> Note that another aspect (supported by BONDI) of the UI deliverable  
>> is
>> the ability to control menus. This has clear value in that a web
>> application could declare its own menu (which could be one of the two
>> menus on a mobile, an extra menu entry on a desktop, etc.) and
>> therefore have better integration with the system, but I am wondering
>> what its relationship with HTML's <menu> element is. I'd be  
>> interested
>> in input on that.
>
> They seem to be related. Here's my superficial analysis:
>
> The first obvious difference is that the <menu> element is  
> declarative by definition whereas BONDI UI proposes a programmatic  
> way only. A <menu> can of course be constructed via DOM API as well  
> so it can do both.
>
> Another major difference I was able to spot was that the current  
> <menu> element as specified in the HTML5 draft [1] only allows  
> representing menus which reside within the viewport (probably for a  
> good reason).

Well, traditionally that's what's been considered useful. But times  
are changing and greater system integration has some momentum.

> The BONDI UI deliverable targets the menu which is considered to be  
> part of the browser chrome. If we had the power to change the HTML5  
> an elegant approach would be to define a new keyword for <menu>  
> element's type attribute which would make the <menu> element  
> represent the chrome toolbar (ie. an extra menu beside the typical  
> File, Edit etc. on desktop and softkey(s) on typical mobile device  
> UAs).

Right, that's one option I was thinking about. The other was  
ui.addMenu(in HTMLMenuElement menu) that wouldn't require a change to  
HTML. I tend to prefer the option of adding a keyword (note that that  
can probably be done outside of HTML, it would just need co-ordination  
with the HTML WG), but I'm not married to it just yet.

--
Robin Berjon
   robineko  hired gun, higher standards
   http://robineko.com/
Received on Friday, 23 October 2009 13:25:07 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:14:01 GMT