Re: Links and stylesheets

Jon Bosak wrote:
> 
> [Len Bullard:]
> 
> | Because I wasn't involved in the discussion of the decision to stick
> | to the schedule and not do these in parallel, please provide the
> | rationale for that
> 
> Because we can't do everything all at once.

hehe. So much for creation by "Be!"

> By providing a general link mechanism that points to one or more
> stylesheets and says "hey, these are stylesheets".  We will have a
> link mechanism that can point to multiple targets (or we're just
> screwing around, in my opinion), and I don't know any reason a priori
> why a document couldn't point to stylesheets of several different
> types 

negotiation?

> The tricky part is whether the behavior specifications go in the
> stylesheet language or not.  As you rightly say,
> 
> | a reply to a question on a design vote by the ERB of "oh don't worry,
> | the stylesheet will handle that" will be unacceptable rationale
> 
> and I think that it's in the area of behavioral specifications that
> this kind of question will arise.  By "behavior" I mean, for example,
> the specification that this particular link right here will pop up a
> single scrollable child window that contains just the content of the
> element pointed to in the target document, while that other five-ended
> link over there will pop up five tiled areas in my current view port
> each of which allows me to view the entire document containing the
> element pointed to.  Or whatever.

Interface specification.  We struggled in MID on the idea 
of logical vs explicit behavior in the widgets.  It is easy to
just say, three radiobuttons, and most people will know what 
you intend it to do.  OTH, if you say, pickOne, they do as 
well but rather than radio buttons, you might have three 
big birds hollering at you and you pick one and they fly away.
It is almost funny after a while and the reason Dave Cooper 
had the More Meta Than Thou posters made.

There are problems just labeling it behavior but it 
is a place to start.
 
> I believe that there are basically two ways to provide for such
> specifications: you either consider them to be part of the stylesheet
> (the way that DynaText does it) or you provide some kind of
> architectural form mechanism that allows the behavior to be attached
> to the link element.  Deciding which way to go will indeed involve us
> in some discussion of stylesheets, but the goal here is to keep
> ourselves sane by getting into this area as little as possible and as
> late as possible.

Ok.  This phase is quite hard to do without a notion of implementation 
and further definition of system design instead of abstract markup.

> In today's ERB conference, we decided to divide Phase II (hypertext)
> into three subphases:
> 
>    1. Addressing

Locations?  Resource resolution?

>    2. Typing

Semantic linking?  Reference types for linkends?

>    3. Behavior

Scripts, protocols, light (internal) vs heavy (java, etc) languages.
These seem to come up often.  The behavior problem has been 
discussed many times.

> The first phase of this effort has shown us the virtue of putting off
> the hardest questions until the end: you understand more by the time
> you get there.  It is hoped that in the process of solving the link
> addressing and link typing problems we will learn enough to do the
> right thing when it comes time to deal with behavior.

I think this is a good idea.  Behavior is tricky and a more 
religion-riddled topic you won't find in computer science.
This is tough.  Probably half of the WG has been involved 
in a project that set out to define this in a *standard* way, 
so there are lots of ideas, and lots of compromises ahead.

sigh... another winter here by the sliding glass doors...

happy thanksgiving! all!

len

Received on Wednesday, 27 November 1996 23:11:14 UTC