[webkit-dev] Implementation thoughts on HTML5 elements

[tali garsiel]

Hi,

I don't think overriding the context menu is a marginal case.
I think its very widely used in web applications.

Tali


On Wed, Aug 26, 2009 at 7:47 PM, 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.
>
> Ojan
>
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20090826/f02bfaf1/attachment.html>