[whatwg] Suggestion for Menus in Web Forms 2.0
mpt at myrealbox.com
Wed Nov 17 02:08:31 PST 2004
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
> 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
> 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
>> 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
> 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
More information about the whatwg