- From: Matthew Raymond <mattraymond@earthlink.net>
- Date: Tue, 10 Aug 2004 11:35:39 -0400
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.
>>
>> 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.
>
> 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.
"...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.
"...they will not be able to handle documents dragged to the
application's icon.
>>> 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.
>
> You're going to try and implement VNC in HTML5? Say it ain't so.
It ain't so. I'm referring to unique, artistic interface designs
similar to what you might see in Flash.
>> The webmaster may want a unique look and feel that don't belong to
>> any specific operating system.
>
> If that's what they want, they'd better not be mixing Web Forms
> controls with their Web Apps controls. Because in most rendering
> engines, Web Forms (1.0, and 2.0 so far) controls are implemented to
> look and feel like they belong to the operating system on which the UA
> runs, which would spoil the effect.
To some extent, this can be changed with CSS. You can also use
graphics to overlap controls (messy!) or build custom widgets that
behave in a similar fashion to a control (and perhaps use scripting and
a hidden <input> for submission).
> It would make more sense for such
> 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.
>>> 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.
>
> 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?
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.
>> 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.
>
> Sure. Just like they'll have to remove their existing implementation of
> HTML 3.2's <menu> and add some new implementation.
That's only inside a <menubar> element. The <menu> would be have
like a standard HTML 3.2 <menu> outside that context. (I suppose Ian
could make that more clear in the spec if he hasn't already.)
>>>> 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.
>
> There you go talking about chromeless windows again. What does that
> have to do with having two or more visually similar menu bars on the
> screen simultaneously?
Look at the deepest part of the quote. "On a chromeless window". Do
chromeless windows have multiple menubars? No. End of this part of the
discussion.
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.
>>>> 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.
>
> Oh, that.
> * <http://digilander.libero.it/chiediloapippo/Engineering/iarchitect/
> visual.htm#VISUAL35>
> * <http://joelonsoftware.com/uibook/chapters/fog0000000059.html> ("The
> trouble was...")
> In order to understand the need for <menubar> I think I would need to
> see a less malevolent use case.
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.)
>>>> 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.
>
> 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. 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.
Thought: provide a CSS value for selecting between the two for the
best solution in a given circumstance.
>> 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 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.
>>>> 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.
>
> 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??? Perhaps I misunderstand your
use of the term "pull-down". I understood it to be the same kind of menu
you get with an XUL popup menu.
> 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?
> 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.
> 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...
Doubt a tree control will be in WF2. That's slotted for WA1.
>>> 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,
>
> Correct.
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.
> 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". I would not argue, though
that a single select with multiple sublevels is the best control for ALL
situations.
> 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|?
Received on Tuesday, 10 August 2004 08:35:39 UTC