Alex Hopmann (
Tue, 25 Apr 95 03:56:41 EDT

>But, this does not give any latitude to the placement of such a button on
>the page. In many instances, you will want such a button to be in a very
>specific place, not just at the top or the bottom in a button bar. If we
>are going to bother doing this, I'd want to see a generalizable solution,
>something that could be used for other browser specific functions. I could
>see a general purpose tag, like <BROWSER TYPE=BACKUP> for specifying such
>things, but again I want to be able to place this just SO.
>Thanks for your comments!
I think this actually gets to a deeper issue with HTML- It is great as a
publishing language but it lacks something when it comes to being an
"Interface Builder" toolkit which is exactelly what your seem to be seeking
in the above comment. We are working on a proposal for something to work in
conjunction with HTML (and possibly in conjunction to Java) that will
attempt to provide some of these capabilities. Unfortunatellyso far I have
not had any time to write this up so I appologize for adding this rather
unsubstantiative comment :). I did however demonstrate this technology to a
couple people at the San Jose IETF, and we are mostly waiting to polish it
up a bit and write it up.

Oh, and one other comment on the issue. I strongly support the comments
someone else made that it is easy and a good idea to makeup new URL types
when necessary (And of course document them for the internet community)-
URL's were designed as an extensible mechanism. Of course depending on the
application you may or may not need to worry about interoperability. In our
application we are designing a server and a client that go together so this
(so far) is not an issue to us. On the other hand I suppose you could point
out that backup is not really a URL (a resource location) but rather a "user
action", which leads me back to the "interface builder" issue.

Alex Hopmann
ResNova Software, Inc.