- From: Matthew Thomas <mpt@myrealbox.com>
- Date: Wed, 17 Nov 2004 23:08:31 +1300
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/
Received on Wednesday, 17 November 2004 02:08:31 UTC