[whatwg] Suggestion for Menus in Web Forms 2.0

Thu Aug 12 04:06:11 PDT 2004

Matthew Raymond wrote:
> Matthew Thomas wrote:
> 
>>>> The type of window used is irrelevant. To pick just three 
>>>> examples,   HTML5 applications will not be able to avoid
>>> 
>>> It has been suggested (I think by Ian) that there be an
>>> attribute for the <html> element that indicates if the web
>>> page is a web application that requires a chromeless window.
>> 
>> The type of window used is irrelevant. To pick just three
>> examples, HTML5 applications will not be ... Wait, hang on, I
>> just explained that. So why on earth are you still going on
>> about chromeless windows?
> 
> Perhaps I have missed something. Let's look a the three items...
> 
> "HTML5 applications will not be able to avoid that on some
> platforms there will be a menu bar..."
> 
> If the markup asks for and is granted a chromeless window, why
> would it have a menu bar? The window is chromeless. You're
> talking about a situation where the UA deliberately ignores the
> chrome-related markup, which would probably be non-compliant.

You have seen MacOS, right? How do you open a window without a menu 
bar when menu bar is *static* element of the whole screen? Don't be 
windows-centric here.

> "...they will not be able to control their taskbar/Dock icon..."
> 
> Web pages already have their own icon via <link>. It would only
> make sense that the UAs would use that icon.

I agree. But it should be up to the UA to decide. I don't think that 
WHATWG should say anything about this.

>> persnickety authors to use Java or Flash, where they can wallow
>> in as much non-nativeness as they like.
> 
> It can be argued that neither of these are open formats, though,
>  especially for Flash.

It doesn't really matter. 'Elite' authors can simulate their user 
interfaces with SVG and JavaScript too. I really don't care. If an 
application inside a browser window wants to behave like a native 
one, then the author must give up some control over UI tweaking.

>> situation I was talking about, where there is *no* practical
>> solution for the platforms some user agents are running on.
> 
> Perhaps you should specify the platform you are referring to,
> then?
> 
> My point was that you can't create solutions for a platform that
> you know nothing about, so it would be best to suggest
> implementations for platforms we DO know something about and
> allow enough room in the spec for alternative solutions that may
> be required on other platforms.

Having a recommendation about how different UI elements *might* be 
implemented on some well known platforms (win32, MacOS, perhaps 
KDE/Gnome) wouldn't be a bad thing. Authors should still design the 
UI based on the type of data they need. If the spec recommends 
rendering for some elements, authors may end up using the wrong 
elements because the recommended rendering for the wrong input 
element better fits their need.

> Yeah, at the very least the floating menu thing should be 
> discouraged. (Though if a vendor wants to do that, it's their
> right.)
> 
> How about a collapsible menu? (I'm sick, so my imagination isn't
> running on all cylinders today.)

A menu is a menu is a menu. I don't think that menubars *must* have 
some behavior. The spec could recommend something for some well 
known platforms.

>>> There's also nothing stopping vendors from opening up the
>>> entire menu  to the location of the selected item and moving
>>> the mouse pointer to a  position over that item.
>> 
>> Except that native menus don't do that either, whether they're
>>  pull-down menus *or* option menus.

I think that this is an important point. If the web application is 
supposed to feel native, it should behave like one. I definately 
*hate* when *any* application dares to move my mouse pointer. Only 
mouse movement should affect mouse pointer position, IMO.

-- 
Mikko