[webkit-dev] Implementation thoughts on HTML5 elements

[Alex Russell]

On Wed, Aug 26, 2009 at 10:47 AM, Ojan Vafai<ojan at chromium.org> wrote:
> On Tue, Aug 25, 2009 at 11:45 PM, Maciej Stachowiak <mjs at apple.com> 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