- From: Ian Hickson <ian@hixie.ch>
- Date: Tue, 10 May 2005 07:58:03 +0000 (UTC)
On Mon, 9 May 2005, Dean Edwards wrote: > > > > Unless someone can come up with a way to make discoverability > > practical and usable, there is no point us having [help]. > > It is not all about user agents. I once had to build a web application > with extensive context sensitive help. The app even recalled common > entries for data fields. To make it work we invented an attribute called > "helpID". If the "help" attribute were defined we would have used that > instead. I don't see anything wrong with a Web application using custom attributes (preferably clearly prefixed or in a custom namespace) to store information like this. But I don't see the value in making the attribute for such a case standard. It would restrict what you could do with it, for one -- say the Web app wanted to store just a number for the help. Or just a URI. Or two URIs. Or an IDREF. Or a string. If we had an attribute, we'd have to define what it was, thus either blocking innovation, or using up an attribute for no good reason. > [...reasons why the things I listed might work sometimes...] Yes, all the things I listed are plausible solutions, that's why I listed them. But they're not good _enough_, IMHO. > I think that a help attribute is useful in the realm of web > applications. Applications tend to be more complex than web documents. A > good application is sometimes only as good as its help system. Even if > UAs make nothing of it, web developers would have a standard attribute > to hook their own help systems from. I don't see the advantage of having a standard way of doing something non-standard. It wouldn't improve interoperability. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Tuesday, 10 May 2005 00:58:03 UTC