- From: Matthew Thomas <mpt@myrealbox.com>
- Date: Sat, 7 Aug 2004 20:15:18 +1200
On 7 Aug, 2004, at 3:50 PM, Matthew Raymond wrote: > ... > Matthew Thomas wrote: > ... >> Allowing a native-looking menu bar makes sense for applications that >> are going to have complete control over their own interface. >> However, the What-WG specifications (as opposed to other >> specifications deemed too ambitious and/or unmixable) are designed to >> be implementable inside Web pages, where applications cannot have >> complete control over their own interface. > > I think you're imagining a constraint on WF2 that doesn't really > exist. WF2 can be used in chromeless windows. The type of window used is irrelevant. To pick just three examples, HTML5 applications will not be able to avoid that on some platforms there will be a menu bar, they will not be able to control their taskbar/Dock icon, and they will not be able to handle documents dragged to the application's icon. None of those have anything to do with the type of window. > ... > Then again, I've seen Java applications in a browser that have such > menubars, so there may be a demand for this. Another thing is that > someone may want to create a simulated desktop interface where they can > open multiple "windows" within the browser windows. In that case, it > would be nice if these window-like blocks could have their own > menubars. That doesn't make sense on those platforms where applications have menu bars but windows do not. > ... >> Therefore, making <menubar> "look like a menu bar" would involve >> having two or more visually similar menu bars on the screen >> simultaneously. But this is bizarre behavior on some platforms, and >> even on platforms where it is expected behavior, it is highly >> confusing. > > One thing we could do is come up with a way to display menubars on a > few key operating systems that doesn't confuse users, then allow enough > room in the spec for user agent vendors to create their own solutions. IMO allowing "user agent vendors to create their own solutions" is a copout from admitting that there is no practical solution for the platforms some user agents are running on, which is bad for interoperability. (For an example of such silliness, see <http://www.w3.org/TR/2003/CR-css3-color-20030514/#flavor>.) There's no point in providing freedom to choose, if the number of practical choices is zero. > ... > Furthermore, HTML 4.01 allows support for <link> to implemented in > any way the UA vendor chooses, Which is partly why authors don't use it. > so suddenly turning <link> into a menu system could cause serious > problems. Like it becoming useful, perhaps. :-) > This is especially true if a browser vendor chose to put <link> items > in a submenu off the main browser menu. I don't remember anyone on this list suggesting that. Hiding them in a menu would certainly fail my "reliably noticable" criterion <http://listserver.dreamhost.com/pipermail/whatwg-whatwg.org/2004-July/ 001197.html>. > ... >> Therefore, I suggest the <menubar> element be renamed to <menulist>, >> to indicate that (in graphical UAs) its child <menu>s will be >> rendered vertically by default. > > A bar can be vertical. I've seen many toolbars that can be > positioned that way. The Windows "Taskbar" can be vertical. I don't > really think this presents a serious conceptual problem. Good! > As for a default direction, I'd rather have CSS or an HTML attribute > handle it. Sure, just as CSS can be used to alter the orientation of OL or UL or DL. >> That would suit the usual use case for adjacent menus, and would >> avoid wrongly implying that it should look like a native menu bar. > > On a chromeless window, it probably SHOULD look like a native > menubar. No, because that would (on some platforms) still involve having two or more visually similar menu bars on the screen simultaneously. >> Authors wanting horizontally adjacent menus could get them without >> extra styling just by using adjacent <menu>s, without a <menulist> >> element. > > How would they do this, by setting the |style| property equal to > "display: inline"? No, they'd do it "by using adjacent <menu>s, without a <menulist> element". For example, <menu...>...</menu> <menu...>...</menu>. > Keep in mind, an element name like "menubar" or "menulist" can > communicate more than just visual position. Native menubar rendering > on a chromeless window, for instance, would be impossible without such > an element. I don't know what you're trying to say here. > ... > I don't mind presenting <menu> as a button when not in the context > of a menubar. However, should this be required in the spec, or simply > recommended? How strongly the Web Apps spec suggests particular visual presentation is suggested for <menu> probably depends on how strongly the What-WG specs suggest particular visual presentation for controls in general. I don't think Ian has said anything about that yet. > ... > You're confusing the implementation of a drop-down list for <select> > with the <select> element itself. The <select> element could be > implemented in a manner similar to that shown in the HTML 4.01 > specification, for instance: > > http://www.w3.org/TR/html401/images/optgroup_exmpl.gif > > The <select> element could be implemented as a pull-down menu. That would be even worse, but in a different way: it would mean in some cases the current selection wasn't visible at all even immediately after the menu was opened. For example, someone who chose "Uzbekistan" by mistake instead of "USA" would have to scroll through (nearly) the whole damn menu of countries again, instead of mousing down on the menu and dragging northward ~5 pixels. (On the Windows platform, and in Gecko on all platforms, decrementing a <select> value is more time-consuming -- you need to click the menu, then move down(!) to click the up arrow, then move across to click the correct item. But that's still not as bad as a pull-down menu would be.) That's probably why no toolkit I know of presents any of its one-of-many selection controls (listboxes, scrolling listboxes, option menus, or sets of radiobuttons) in the way the W3C illustrates. It would be far too annoying. > Besides, in the context of using <select> WITHIN <menu>, a pull-down > menu would almost certainly be used. Sure, but that's not what was being discussed. > ... >> Another reason not to have <optgroup>s inside <select>s is that >> option menus are supposed to show their state even when closed, but >> they cannot do so reliably if two or more submenus contain items with >> the same text. > > Easy to fix. Display the <option> |label| as in the menu and the > child text of the <option> as the selection. This is consistent with > the example from section 17.6.1 of the HTML 4.01 spec: > ... As I said, "the distinction could not be shown in a single native-looking option menu while the menu was closed, without making the menu abnormally wide". The W3C's example uses abnormally short submenu items in an attempt to make <optgroup> look practically implementable. -- Matthew Thomas http://mpt.net.nz/
Received on Saturday, 7 August 2004 01:15:18 UTC