- From: Matthew Raymond <mattraymond@earthlink.net>
- Date: Sun, 08 Aug 2004 17:36:17 -0400
Matthew Thomas 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.
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. A compliant browser could
process such a page with something similar to pop-up blocking, and if
the user permits, the page would be displayed without chrome regardless
of how it was opened.
>> 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.
It does if you want to simulate your own desktop interface, which is
the example I gave above. The webmaster may want a unique look and feel
that don't belong to any specific operating system.
>>> 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.
I'm not arrogant enough to think that I can always come up with a
better UI solution than vendors for a specific platform, nor do I
believe we can necessarily come up with the presentation details for
menubars on every operating system that existed or will exist. Write the
specification so that there is a RECOMMENDED solution for key operating
systems, then make the specification loose enough so that it can be
implemented without tying the hands of vendors that might have a better
solution.
> (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.
Prove that the choices are zero on all platforms.
>> 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.
Some do, but they don't rely on it as a general menu system.
>> so suddenly turning <link> into a menu system could cause serious
>> problems.
>
> Like it becoming useful, perhaps. :-)
How about the fact that existing <link> elements are not necessarily
ordered in a way that the webmaster might want them in a menu because
many browsers group specific kinds of <link> elements in a predetermined
fashion? What if the webmaster defines them in the order of { Last,
Bottom, Next, First, Previous, Top }? I wouldn't want it to show up in a
menu like that. But in current browsers, there's absolutely no reason
not to put items in random order.
>> 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>.
I was referring to how a vendor implemented the HTML 4.01
specification, not something you invented for the mailing list. If a UA
vendor implemented support for link in a submenu, that existing browser
will have to be modified to remove the submenu and add some new
implementation.
>>> 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.
Seeing as the window would be chromeless, I don't understand how.
>> 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.
Good example would be MS Office for Windows (and maybe Mac too, but
I wouldn't know). Look at the menubar. See the little grippy? Grab it
and you can put the menu on the sides of the window, or on the bottom,
or make it a menu in a little floating toolbox.
Furthermore, without a parent tag, there's no semantic connection
between the separate menu items.
>> 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.
I think that's because we're supposed to talk about instead of
having Ian unilaterally decide for us.
>> 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.)
In most <select> implementations, you can simply use the arrows to
select the next or previous item. This behavior would not have to change
to use a popup menu instead of a drop-down list. 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.
> 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.
So it can't be done because you've never seen it done?
>> 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.
By making <optgroup> non-nesting, you make the <select>-based
solution that's in the current WA1 spec useless for menus more than two
levels deep. The subjects of <optgroup> nesting and WA1 menus are related.
>>> 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.
How would any of the selection be narrower in any other type of
control that's one line of text high when closed? You'd have to have a
tree of some kind, which is kinda silly if you're selecting something
from a group of categories and subcategories that aren't necessarily in
the name of the item. For instance, my car is a 1994 Subaru SVX Lsi:
Subaru->Car->Sports Car->SVX->Lsi->1994
By your reasoning, the selection would read:
"Subaru - Car - Sports Car - SVX - Lsi - 1994"
In reality, it would simply be "1994 Subaru SVX Lsi". That's the
whole reason there's a separate |label| property. The W3C wanted you to
make the selection name different from the menu name so that the actual
text node under the <option> could exclude unnecessary information about
the submenu titles, allowing the web master to avoid large
treeview-style controls.
Received on Sunday, 8 August 2004 14:36:17 UTC