On Wed, Aug 26, 2009 at 10:47 AM, Ojan Vafai<[email protected]> wrote: > On Tue, Aug 25, 2009 at 11:45 PM, Maciej Stachowiak <[email protected]> wrote: >> >> On Aug 25, 2009, at 11:21 PM, Maciej Stachowiak wrote: >> >> Hi everyone, >> Recently at Apple we've been considering our plans to implement new HTML >> elements from HTML5. I'd like to share our thoughts with the WebKit >> community and see if we are in sync before passing this on to the HTML >> Working Group. Does anyone have thoughts to add to the below: >> ---------- >> >> I realized I forgot to cover <command> and <menu>. >> - <menu> >> The list form of a menu seems straightforward enough, it is good to have >> a list type specifically for popup menus. The toolbar form does not seem >> fully baked. First, it seems weird to think of a toolbar as a kind of menu. >> Second, the rendering is too inflexible and underspecified for the real Web >> content authoring use cases for toolbars. And finally, an important point of >> toolbars in many applications is that they can embed custom controls in a >> flexible layout that also includes some standard buttons, but <menu >> type="toolbar"> does not seem flexible enough to handle this. The context >> menu form does seem genuinely useful. But it also seems like a lot of >> complexity for the somewhat marginal case of overriding the context menu. It >> seems like about a dozen different elements are allowed, all with different >> processing requirements. This seems like overkill for the use case of a >> context menu. It doesn't even make much semantic sense for a context menu to >> contain a button. Overall, it doesn't seem like the cases of menu list, >> toolbar and context menu really share enough behavior or appropriate content >> model to make them use the same element. >> - <command> >> It's unclear if this element is worth having without the use cases for >> toolbars or menus, and it also has 0 implementations so far and seems like >> it might not be fully baked. > > While I don't disagree, I'm a little sad to see these not move forward in > some form. JS libraries currently use a ridiculous amount of code to create > simple flexible toolbars and menus that are keyboard accessible. Would be > nice if someone with experience here (looking at you Hyatt) could chime in > on whatwg with what a better design would look like so progress can be made.
+1. Menus (menu strips, lists, what have you) and toolbars that share keyboard accelerators are a huge burden today, particularly in rich-text editing where focus constraints mean that in order to implement a11y for toolbars, you need to do lots of magical focus/selection saving in order to service the ad-hoc toolbar for things like keyboard navigation. Even if WebKit decides against the current HTML 5 spec for this stuff, having a toolbar and menu system that's sufficient for implementing the states needed for a rich text editor (think drop-down menus from a toolbar, toggle-buttons corresponding to style application, button-sets for multiple state toggles, e.g. alignment, etc.) would go a very long way to making a lot of UIs load faster and suck less (since, hopefully, a browser-provided UI would remove the ad-hoc nature of much of these UIs). Regards _______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
