- From: Matthew Thomas <mpt@myrealbox.com>
- Date: Tue, 10 Aug 2004 22:15:12 +1200
On 9 Aug, 2004, at 9:36 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.
>
> 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?
> ...
>> 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.
> 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. 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.
> ...
>> 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.
>> (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.
No, I did not say "the platforms all user agents are running on". I
said "the platforms some user agents are running on".
<http://dictionary.reference.com/search?q=some>
> ...
> 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.
Well, good, a UA wouldn't put them in a menu like that. (Existing
<link> implementations are hopeless in most respects, but at least they
get *that* much right.)
> ...
> 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.
> ...
>>> 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?
>>> 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.
> ...
>>> 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.
> 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.
>> 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.
>>> 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. And if your hierarchy of options has more than one
level, a single option menu is the wrong control to use.
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. And Web Forms could provide a tree
control for the latter situation.
> ...
>> 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.
> 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.
> ...
Firstly, that degree of compression is only rarely possible. For
example, "Palmerston, NT, Australia" is hardly shorter than "Australia
- NT - Palmerston".
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.
--
Matthew Thomas
http://mpt.net.nz/
Received on Tuesday, 10 August 2004 03:15:12 UTC