- From: Anssi Kostiainen <anssi.kostiainen@nokia.com>
- Date: Thu, 22 Oct 2009 16:21:14 +0300
- To: ext Robin Berjon <robin@robineko.com>
- Cc: ext Brian LeRoux <brian@westcoastlogic.com>, Device APIs and Policy Working Group WG <public-device-apis@w3.org>
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). 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). -Anssi [1] <http://www.whatwg.org/specs/web-apps/current-work/multipage/interactive-elements.html#menus >
Received on Thursday, 22 October 2009 13:21:25 UTC