> I like the functionality of Marc's proposal. (I am indifferent
> to the syntax, so long as we get a standard.) While I daresay
> that HTPP2 and Mime will oneday achieve the same power and more,
> I like the idea of getting it soon.
>
> Note that Tim's proposal
>
> <a name=fig1 href="fghjkdfghj" REL="EMBED, PRESENT">Figure </a>
>
> is less general, since it can only be used inside anchors.
No ... it is just that the thing is seen as a type of link rather
than something totally new. Note that in the Microsoft world the
work "Link" always mean "embed the thing referred to here" --
this explains much of the confusion when explaining W3 to windows
users.
If you consider that often the reader (rather than the author) might
want to chose which figues are expanded inline rather than put in a
separate window, and also that the reader (rather tham the author)
might want to chose whether related things are PRESENTed
automatically or not, then the use of <A> with switches looks
more appropriate. As Tony points out, an advantage is that it will
be handled relatively well by browsers which can't do it or
old ones which don't understand it.
> (Maybe
> I don't understand it, though... do you have to click on the
> anchor, or does PRESENT mean that it is "automatically" clicked?
You didn't quite but you do now. yes ... PRESENT means
CONSIDER-THIS-CLICKED.
> If so, what happens to the text between the A and /A ?
It is replaced by the object because of the EMBED relationship.
> As I understand it, I can use Marc A's scheme for inline pictures
> (which might be big) or icons in anchors.
If you allow an image, then suppose we also allow some content which
includes anchors with x,y coordinates within the image. Then the
document can intercept mouse clicks and allow hypergraphics
I don't want to change HTML now if I can help it, until it has gone
to RFC track
Tim