[Prev][Next][Index][Thread]

Re: 3.1 b-h: BEHAVIOR



At 6:29 PM -0800 3/1/97, Tim Bray wrote:
>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
> think])
>
>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.
>
>Notes:
> 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.

having argued vocifersously against anything like this, I would like to
note that I find this an acceptable compromise... One thing that this does
seem to imply for the future is that processing specs. need to be able to
dispatch on these behavior attributes, so that sepcific renderings may be
associated with them.


This means that the processing spec. (stylesheet) needs the following hooks:
   1. Attach default behavior for al links with specified ACTUATE/SHOW
combinations.

   2. Attach specific behaviors to specific elements with specific
ACTUATE/SHOW combinations.

   Allow each of these sepcifications to include wildcards or sets of
behaviors -- if we extend this to the element type, we can merge 1 + 2 into
one kind of specification, with possible wildcards in any of its 3
"dispatch fields".

    This will imply some kind of resolution hierarchy for deciding which
defaults apply where -- but we will probably need something similar for
processing specifications (stylesheets) anyway.

  -- David "indirection 'til I die" Durand


_________________________________________
David Durand              dgd@cs.bu.edu  \  david@dynamicDiagrams.com
Boston University Computer Science        \  Sr. Analyst
http://www.cs.bu.edu/students/grads/dgd/   \  Dynamic Diagrams
--------------------------------------------\  http://dynamicDiagrams.com/
MAPA: mapping for the WWW                    \__________________________



References: