Re: 1.5: Discuss link characteristics?

At 15:50 11/2/97 -0500, Steven J. DeRose wrote:

>On the other hand, Martin wrote a distinction between behavior and
>presentation that I think wrongly conflates two axes: 
>
>   1) user vs. author control, and 
>
>   2) geometric layour versus what happens on mouse-click

I was not trying to make a case for user control v author control per se,
only using that idea to make a plea for not putting all of the control into
a single object that replaces the style-sheet. What I _was_ trying to make a
distinction between was what could be done at the client and what had to be
done through interaction with the server.

I agree that there a multiple axes, including time related ones. For
example, consider what happens if you call up an image map or a link
containing an image to a browser for which automatic image loading has been
disabled. For the image map you may need to force the first click call up
the image (which may cause the formatting to change on the client), and only
let the second click generate the query to send to the server. For the link
the first click could either go direct to the linked point or it could call
up the image.

Behaviour itself is a complex thing. I am currently using this generic term
as a place holder for all the things Netscape does with its OnMouseOver,
OnClick, OnSubmit... type options, some of which defined client-side
behaviour and some of which defined a server-side behaviour and some of
which can do both. How we segment this beastie is a problem, but if we mix
it up with style sheets we end up with an uncontrollable mush.

>You can't completely separate formatting behavior from interaction behavior,
>and you sure can't combine those two axes.
>
>Example: there's a quotation element. I, as a user, may want it:
>
>   * Displayed in a footer or sider pane

Formatting dependent on user preference
>
>   * Rendered as an inline block-quotish kind of layout

Formatting dependent on user/author preference (You can't choose to inline
material that the author has placed elsewhere easily, but an author can say
'this should be displayed in-line')
>
>   * Hidden behind something clickable like an icon or a footnote number,
>     and displayed on demand.

Formatting with behaviour attached
>
>   * Hidden per last point, but in big pink type if I reached it via a link
>     or type 'criticism' and small green if by a link of type 'support'.

Formatting with behaviour dependent on link type attached
>
>   * flagged for different indexing treatment, or extracted along with all
>     others of its kind to make a biblio.

Behaviour with subsequent formatting.
>
>Now try to pin down just which of those are presentation and which are
>behavior.

I've tried:-)

> And then convince all the users that they only ever want control
>of presentations, and convince all the authors that they only ever want
>control of behavior.

You can't convince anyone, you can only offer them more than one
alternative, and the key thing is where control of the alternatives lies -
at the delivery point or the consumer end of the the process.

>In *every* presentation, I may want to associate behavior. For example, when
>it's inline I may want to be able to click on it anyway, and retrieve the
>source being quoted. Or maybe I want my display of the quotation to have a
>scrollbar, so without following any link I can just scroll around to see its
>original context. 

Now thats what I call a real neat need, but it is based on the presumption
that the quoted text is a transclusion rather than a copy (which would form
the traditional type of 'quotation element' referred to above). The rules
for transclusions are necessarily behaviour driven rather than formatting
driven!

>I do not think it is possible to make a *principled* distinction between
>formatting behavior and interactive behavior. 

Agreed. The principled distinction must be between whether control is to be
placed with the document delivery server or the document receiving client.
However, I don't want to define my interactive behaviour in a style sheet -
I need a script element for this.

>And they do not correlate
>precisely with the entirely separate notion of user vs. author control. If
>we conflate those two separate axes, we'll just impose a needless limitation.

I agree that we should not coflate the axes, any more than we should
conflate the definitions that control the formatting and the interaction.

The author/user (or client/server) aspect brings in two points. Firstly you
need the ability to cascade both the options. The most important thing about
CSS is the C (the SS is a pain!). We need something like C-DSSSL-O and an
equivalent C-Interact. For the latter we need a way for servers to send down
a pointer to a default behaviour and have users say "replace the default
behaviour with this behaviour" (a catalog for Java applets?). If we can then
get DSSSL to call applets, and applets to call specific sets of DSSSL-O
formatting rules, we will get what is needed. DSSSL-O style sheets cannot
provide the behaviour, and applets cannot properly control formatting. There
must be an interaction between the two to define all the options you suggest
above.

----
Martin Bryan, The SGML Centre, Churchdown, Glos. GL3 2PU, UK 
Phone/Fax: +44 1452 714029   WWW home page: http://www.u-net.com/~sgml/

Received on Wednesday, 12 February 1997 10:06:55 UTC