3.1 b-h: BEHAVIOR
Dimension 1: Which pieces of information should be specified for
possible inclusion in linking elements?
This one has been tough. Since we put in immense amounts of time, I will
try to reproduce some of our discussions.
Some of the options:
a. say nothing about behavior; leave it to the apps and to stylesheeting
b. provide a behavior bucket; an attribute in which to pass behavior info,
but specify nothing about what goes in there
c. provide one or two attributes governing simple abstract axes of link
behavior policy, with lots of room for user-agents/clients to devise
mechanisms to meet the policies
d. provide a rich, detailed, set of behavior specification rules that
people such as users of EBT products, TEI, and HyTime have come to
(a) and (b) seem the safest in terms of avoiding doing something really
stupid. However, there was stringent opposition from those speaking
on behalf of the authors, who wanted some (even if only abstract) way
to signal whether a link, when activated, should cause the replacement
of the current display, or transclusion behavior; they claimed that without
this, there was no interoperability. It is also material that on the WWW,
there are at least two well-defined link behaviors, that of the <A HREF=
and that of the <IMG SRC= in the HTML case, accomplished by associating
application semantics with well-known GI's. Also, perhaps <FORM ACTION=
is really a link?
(d) is probably the right thing to do, had we but world enough and time,
but also carries a lot of risk in terms of overspecifying and getting
So, we ended up with (c). The ERB consensus is that there will be two
attributes specified to control behavior; the names and values given
below are provisional.
Each attribute may be provided per-linking-element or per-resource; while
there was a sense that per-linking-elements could probably be used to
provide defaults, and be overriden by per-resource elements, this was
not discussed thoroughly, nor really voted on.
There will be an attribute named SHOW, which may have one of three values:
INCLUDE - means that upon traversal of the link, the indicated resource
should be embedded, for the purposes of display or processing, in the body
of the resource where the traversal started. (e.g. like HTML <IMG)
REPLACE - means that upon traversal of the link, the indicated resource
should, for the purposes of display or processing, replace the
resource where the traversal started. (e.g. like HTML <A)
NEW - means that upon traversal of the link, the indicated resource should
be displayed or processed in a new context, not affecting that of the
resource where the traversal started (e.g. like HTML <A TARGET="NEW" [I
There will be an attribute named ACTUATE, which may have one of three values:
AUTO - means that the link should be traversed and used when encountered;
that the display or processing of the resource where the traversal
started is not considered complete until this is done (e.g. HTML <IMG)
USER - means that the link should not be traversed until there is an
explicit external request for this to happen (e.g. HTML <A)
PUSH - means that the resource is volatile, subject to change, and
should be processed immediately and continuously.
a. HTML <A is equivalent to SHOW="REPLACE" ACTUATE="USER"
b. HTML <IMG is equivalent to SHOW="INCLUDE" ACTUATE="AUTO"
c. Obviously, it is legal for user-agents to ignore these settings and
do as they will; for example, turning image loading off.
With reference to the values of the ACTUATE element, it may be
possible to use the event names that are being proposed for use in
the W3C's work in progress on the "Document Object Model"; we have
an action item to check this out and do so if possible.
Cheers, Tim Bray
email@example.com http://www.textuality.com/ +1-604-708-9592