[whatwg] Suggestion for Menus in Web Forms 2.0

[Matthew Thomas]

On 17 Nov, 2004, at 4:06 AM, Ian Hickson wrote:
> ...
> On Mon, 6 Sep 2004, Matthew Thomas wrote:
>>
>> .... But I still think the possibility shouldn't exist in the first 
>> place.
>
> Why should Web-hosted applications be second-closs citizens?

First, because they're easier to develop. Second, because they're 
easier to (a) run accidentally or (b) run deliberately but without 
considering the consequences. And third, because while native 
application developers have the cloak of binary-ness to protect their 
shareware schemes etc, Web application developers do not, so the latter 
are more likely than the former to attempt UA-assisted DRM schemes 
(which, as usual, are more annoying than effective).

These three factors make it substantially more likely that people will 
be exposed to badly-behaved Web applications than that they will be 
exposed to badly-behaved native applications. Therefore, Web apps need 
to be restricted in the sort of things they are allowed to do. (For 
example, UAs already make great efforts to prevent Web apps from 
reading arbitrary files, while OS developers don't do the same for 
native apps.)

> ...
> Oh, quite the opposite, my intention was to make the non-native case 
> have the pull-down menu be available, just not as the primary menu 
> bar. For example (and this is only an example) from a button in a 
> toolbar, or in the page's context menu, or what-not.

The problem with both of those is that menus become submenus and 
submenus become (ugh) subsubmenus ... but I suppose they're better than 
nothing.

> ...
>> I agree with Jim Ley here: I doubt it'll ever be possible to prevent
>> such detection -- even when using crappy methods that return false
>> negatives in some cases (e.g. a getComputedStyle-related method that
>> breaks in Opera and Mozilla when author styles are turned off or when 
>> a minimum font size is set or when images are turned off or ...).
>
> At the end of the day I don't see why authors would even bother. They 
> can do that now with full-screen mode (only be usable in full-screen 
> mode) but they don't.

Because full-screen mode doesn't (appear to) offer any DRM benefit. The 
annoying things authors do are those that (appear to) offer a DRM 
benefit, e.g. disabling the page's shortcut menu, or (in a 
WA-supporting browser) replacing the browser's "File" and "Edit" menus.

> ...
>> The point is not whether bad UI is *possible*, but whether it is
>> *likely*. Since menu implementations vary so widely across platforms, 
>> it is much more *likely* that authors will produce layouts of menus 
>> that work on some platforms but not others, than it is with layouts 
>> of other controls.
>
> I don't see how it is more likely than with any of the other tools 
> we're proposing here.

It is more likely because menus differ more across platforms than other 
controls do. For example, the maximum length of a menu bar is finite in 
Mac OS. Therefore authors who never use a Mac and rely on the multi-row 
wrapping behavior of native menu bars on Windows will unwittingly 
produce unusable applications. That kind of problem doesn't occur with 
any other kind of control.

> ...
>> OSes could establish standard styles for "headers for menu sections"
>> that looked unmistakably different from unavailable items -- like the
>> "Entrées", "Mains", "Desserts", etc headers in a real menu. But as far
>> as I know, the number of OSes that have done that so far is zero. And 
>> I don't see why menus in Web apps are inherently so much more 
>> complicated than those in native apps, that they need more 
>> subdivision than menus in native apps do.
>
> Windows XP (the OS) uses list view headers in various places, so it's 
> not like this is unknown.

Yes, but it's unknown in menus. Using the headers in XP's task panes to 
justify headers in menus is like using the scrollbars in multi-line 
text fields to justify scrollbars in single-line text fields. They're 
different contexts.

> I've no idea why native app authors don't need this UI idiom much;

First, unfortunately, the quality of interface design on any platform 
has long been roughly proportional to the difficulty of software 
development on that platform. Native app development is harder than Web 
app development, so native apps tend to be better designed, so they 
rarely use hierarchical option menus ...

> in fact I don't know if they do or don't, I don't hear complaints from 
> native code authors. However, I've certainly heard so many people 
> clamouring for nested <optgroup> support in HTML that I know that
> on the Web, there is a demand for it. We don't _need_ to satisfy that
> demand by necessarily allowing nested <optgroup>, maybe it's just a
> symptom of a problem that has a better solution, but I don't know what
> problem it is.

.... And second, HTML UAs don't provide the controls that would make it 
easier to assemble an acceptable interface -- such as trees, lists 
filterable with a search field, tabbed views, and an easy way of making 
a control's availability and/or contents dependent on the choice made 
in another control.

> It's not just people wanting collapsible tree views; I _am_ hearding 
> demand for that too, but those requests sound very different. (And 
> indeed tree views are a lot more complicated than just <select> with 
> multi-level headers.)
> ...

I don't see why they need to be any more complicated, at least in their 
first iteration.

-- 
Matthew Thomas
http://mpt.net.nz/