- From: Matthew Thomas <mpt@myrealbox.com>
- Date: Wed, 11 Aug 2004 20:55:40 +1200
On 11 Aug, 2004, at 3:35 AM, Matthew Raymond wrote:
> ...
> Matthew Thomas wrote:
>>>>> 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.
> ...
> 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?
It wouldn't. On these platforms, no windows have menu bars (except
those running in emulators and similar environments). But that doesn't
affect the shared menu bar at the top or the side of the screen,
because it's not part of any window.
> 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.
Non-compliant with what? I can't find the word "window" anywhere in the
ECMA-262 specification, the DOM1 specification, or the DOM2
specification. Apparently window.open is part of DOM0
<http://www.mozilla.org/docs/dom/domref/dom_window_ref76.html>, but
DOM0 doesn't appear to have a cross-UA specification in the first
place.
> "...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.
Not really, because that would be a security vulnerability. For
example, it would allow Web apps to masquerade as OS X's Software
Update utility by using the same icon.
> ...
>>> 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.
>>
>> That's great, but it doesn't have anything to do with the 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?
Mac OS X, GNUstep, and (with the right configuration) KDE. (I omit Mac
OS Classic because it's unlikely anyone will ever implement a
WA-supporting browser for that platform.)
> ...
> As for having more than one menu at the same time, there's any
> number of ways to handle that. You could have a little selection menu
> that's always visible and chooses which menu bar is visible at any
> given time. Or you could use little tabs, one with the browser name,
> one with the web application name. Solutions are only limited by the
> vendors' imaginations.
And by the platform's interface guidelines, e.g.
<http://developer.apple.com/documentation/LegacyTechnologies/
Conceptual/AquaHIGuidelines/AHIGHIGs/chapter_2_section_2.html#//
apple_ref/doc/uid/20000958/TPXREF110>.
> ...
> How about a collapsible menu?
Same problem. A large majority of the people who collapsed it would be
doing so by accident, and would have very little idea how to get it
back.
> ...
>>> 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.
>>
>> That's great, but it doesn't have anything to do with pull-down menus
>> being a much worse implementation of <select> than option menus are,
>> especially since most people use menus with a mouse.
>
> Interestingly enough, option menus typically don't have access
> keys, and yet you suggest they're more keyboard friendly for some
> reason.
I'm pretty sure I didn't say anything even remotely like that.
> This would only be the case for a flat list, where you can sort
> everything and just hit a key to get to the part of the list you want.
A list need not be sorted for type-ahead find to work. Since 1984, for
example, it has worked in Finder windows even when they're in an
unsorted icon view.
> ...
>>> 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.
>
> And, of course, vendors can't violate the sanctity of what the OS
> interface designers DIDN'T do...
That's right, at least for controls that look like they're supposed to
be native ones. You can put new stuff alongside the existing stuff
(e.g. a calendar button alongside a datepicker, or an auto-complete
menu underneath a text field), but you shouldn't change
likely-encountered behavior of existing clicks and keystrokes, because
that'll cause repeated accidents.
>>>> 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?
>>
>> It certainly could be done, just not by any vendor that was trying to
>> attract users.
>
> A little less opinion and a little more reason please.
If you've seen any commercial vendor (i.e. a vendor trying to attract
users) release an OS where the primary toolkit has menus that work in
the way the W3C illustrates, feel free to name that OS. (It could even
be a vendor like MandrakeSoft releasing a "hacked ... copy of Linux",
if you wanted.)
> ...
>> Which they shouldn't be in the first place. If your hierarchy of
>> anything has more than two levels, a pull-down menu is the wrong
>> control to use.
>
> As opposed to what, a pull-down tree???
As I said, "Web Forms could provide a tree control for the latter
situation".
> Perhaps I misunderstand your use of the term "pull-down".
I mean the kind of menus that can be found, for example, in:
* menu bars;
* some toolbars (e.g. the menus next to the Back and Forward buttons
in most Web browsers);
* some dialogs (e.g. the Find/Replace and Style dialogs in Microsoft
Word).
> I understood it to be the same kind of menu you get with an XUL popup
> menu.
That XUL popup menus pop *down* on all platforms, rather than just on
Windows, is a bug. <http://bugzilla.mozilla.org/show_bug.cgi?id=52106>
>> And if your hierarchy of options has more than one level, a single
>> option menu is the wrong control to use.
>
> What would you use in that case for selection of an item rather
> than a menu, then? Some kind of treeview version of select?
As I said, "Web Forms could provide a tree control for the latter
situation".
>> So far HTML has made it too hard to use appropriate controls for
>> those situations. Web Apps could provide dialogs or tabbed panels of
>> some sort for the former situation.
>
> Those would be poor tools in some cases.
Perhaps, but they would reliably be better than nested submenus.
>> And Web Forms could provide a tree control for the latter situation.
>
> You could use <select size=#> for this. That way no one even has to
> learn any new markup. May need some new CSS, though...
That would be nifty. select::has-child[optgroup] {presentation: tree;
min-height: 3em !important;}
> Doubt a tree control will be in WF2. That's slotted for WA1.
Which makes little sense, since the underlying data is submittable
exactly the same as <select> (as your syntax above demonstrates).
> ...
> The problem is that the tree may not display all the parents on the
> screen at once:
>
> ..#
> :
> +----------+
> | +..# |
> | : |
> | +..# |
> | : |
> | +..[#]|
> +----------+
>
> So it's still possible not to see the full name (path?) of the
> selection.
That's just as true for nested submenus. Once the submenus got to the
right side of the screen (which they could do very easily, for example
in a page's right-side navigation bar in a maximized browser window),
they'd have to start doubling back on themselves and obscuring previous
levels of the hierarchy.
>> Firstly, that degree of compression is only rarely possible. For
>> example, "Palmerston, NT, Australia" is hardly shorter than
>> "Australia - NT - Palmerston".
>
> Bad example, since you precompressed "NT".
Sure, though the result is too long even then.
> ...
>> And secondly, I think expecting authors to set <option label=
>> appropriately is unrealistic, because it's an attribute with a
>> non-obvious effect. Precedent: <img alt=, another attribute with a
>> non-obvious effect, which is ten years old and still used more often
>> incorrectly than correctly.
>
> How about adding an alias for |label| called |shortlabel|?
> ...
That would be slightly more obvious, but it wouldn't address the
problem I described. For example, renaming alt might improve its use a
little, but it wouldn't help *much*. (I'd suggest calling it
alternatetextwhichmeansanequivalentnotadescriptionyouinsensitiveclods.)
--
Matthew Thomas
http://mpt.net.nz/
Received on Wednesday, 11 August 2004 01:55:40 UTC