[webkit-dev] Implementation thoughts on HTML5 elements

[Maciej Stachowiak]

On Aug 26, 2009, at 10:47 AM, Ojan Vafai 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.

I think part of the problem with <menu> is that it doesn't really  
address either of those use cases.

> 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.

I'll talk to Hyatt about this today. I agree that a good way to do  
toolbars, context menus, and even your classic list-based hover menu  
would be worthwhile. Our concerns are about the current design, and  
we're not sure there is time to fix it by Last Call.

I'm going to let this thread go at least a few more days before  
compiling the feedback for the HTML WG.

Regards,
Maciej

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20090826/f950c22e/attachment.html>