Re: Some Comments on the RFCs

Rohit Khare (khare)
Fri, 17 Feb 1995 03:18:14 -0800


OK, I agree with Marco. I'm willing to strike the special treatment of HTML3
from the RFC suite.

Begin forwarded message:

Date: Fri, 17 Feb 1995 12:14:10 +0100
From: Marco Scheurer <marco@sentenext1.epfl.ch>
Subject: Re: Some Comments on the RFCs
To: khare@CALTECH.EDU
Cc: WebStep@xent.caltech.edu

I definitely think that no .html3 file extension or HTML3

pasteboard types are needed. The DOCTYPE comment, and the convention

to ignore unknown tags should do.

>! ! URIPboardType = "WebStep Universal Resource Identifier 1.0"
>! !
>!
>! [Can we have a] W3 prefix (W3URIPboardType)
>!
>
>Well, WebStep specifies the Ascii string, not the name of the

variable holding it.

Sure, but if you want to talk about it, document it, it would be

better to have a name everybody agrees on.

> ! URITitlePboardType = "WebStep URI Descriptive Title 1.0"
> [...]
>! If no <TITLE> is available (because for instance the destination

has not
>! been loaded), do you mean by "bookmark" the text of the anchor, ie
>! all text between the <A> and </A>?
>!
>
>No, I'd say Suggested Practice is to use the string *the user

sees*. For a title, use the "rendered Ascii", and only a few words

at that. If there's an A NAME=, use the NAME.
>

NAME= is not something the user normally sees.

It is nice to have on the pasteboard, along with the URI, a

descriptive, visible, text that can be pasted in your document.

However, there are many (non exclusive) possibilities as to what

this text can be:
- the <TITLE> of the link destination
- the "rendered ascii" of the anchor, for instance "THE Internet

Solution", if the anchor was something like <A HREF="..."><B>THE</B>

<I><Internet</I> Solution</A>. Note that in such a case it could be

nice to have also an HTML pasteboard, if you want to preserve all

information.
- the "alt text" if the anchor had an image with a descriptive "ALT="
- the "NAME="
- the "last component" of the URI

So what should we do if more than one possible text is available?

Shouldn't it be up to the app that pastes to decide what to use

(maybe with the help of the user) rather than to the app that puts

data on the pasteboard?

I think we have the following options:

1) ignore this and let the provider decide what to put on the pb.
2) specify an order of preference in the above
3) define more pasteboard types

Suggestions?

Marco