Subject: The style agenda

From: Bert Bos <[email-masked]>
Date: Tue, 30 May 1995 18:26:58 +0500

Now that the style list is officially open, it is time to think about
its agenda. Style sheets are very much needed on the Web, so we should
be very careful that we don't make any mistakes, because we probably
can't fix them later.

My intuition says that Arena's style sheets are heading roughly in the
right direction, although a number of details will need to change. But
I'd rather not trust intuition.

So I suggest that we collect some arguments pro and con the following
issues, before we start with the details of syntax and the list of
style properties. Now that the mailings are archived (thanks, Nick!),
we can refer back to those arguments when the full proposal is
written.

  1. Are we sure there is no existing language that we can copy?

  2. Do we agree on the goals as stated in the Cascading Style Draft[1]
     and the `Charter'[2]?

     For example: do the phrases "not SGML-complete" from the former
     and "useful subset of all possible SGML" from the latter
     contradict each other or not?

     In particular, do we agree on the fifth goal in the `Charter'[2],
     which states that the style language does not depend on the
     particular names of elements & attributes of HTML?

And, if we agree that a new language is needed:

  3. What is the (abstract) formatting model that we assume?

     For example: TeX uses `boxes & glue', DSSSL has a `page model &
     flow ojects', the simple model that I described[3] has a page
     model with five areas each of which is filled with a continuous
     stream of words. And how about non-visual media?

     A relatively high-level model is dangerous ("doesn't it exclude
     something important?") but useful, since it allows us to write
     translators to lower-level languages such as TeX.

  4. How powerful can/need we make the addressing scheme?

     Although the difference is small, I think my proposal[4] is more
     elegant, more powerful, and not more complex then H=E5kon's[5].

  5. How many levels of cascading priorities do we need?

     As a computer scientist, I would say that H=E5kon's three[6] is a
     strange number, I would rather have either two[7] or very
     many. (I consider `default' and `lens' as outside this range,
     since they need not use the same language.)

  6. How powerful can/need we make the expression language?

     We probably don't need things like macros right away, but
     numerical and other operators might be useful.[9]

And finally, we can invent a syntax (context-free, of course) and draw
up a list of style properties, being careful that we don't include
things that will make it impossible to add more powerful properties
later.

I'm sure we will encounter difficult decisions along the way. I've
already started a collection[8], though I hope that they will turn out
to be not so difficult after all.

Bert

[1]: http://www.w3.org/hypertext/WWW/Style/css/draft.html#goals
[2]: http://grid.let.rug.nl/~bert/Stylesheets/charter.html
[3]: http://grid.let.rug.nl/~bert/Stylesheets/model.html
[4]: http://grid.let.rug.nl/~bert/Stylesheets/addressing.html
[5]: http://www.w3.org/hypertext/WWW/Style/css/draft.html#addressing
[6]: http://www.w3.org/hypertext/WWW/Style/css/draft.html#cascading
[7]: http://grid.let.rug.nl/~bert/Stylesheets/cascading.html
[8]: http://grid.let.rug.nl/~bert/Stylesheets/unsolved.html
[9]: http://grid.let.rug.nl/~bert/Stylesheets/expr.html

-- =

                          Bert Bos                      Alfa-informatica
                 <[email-masked]>           Rijksuniversiteit Groningen
    <http://www.let.rug.nl/~bert/>     Postbus 716, NL-9700 AS GRONINGEN

---

From: Terry Allen <[email-masked]>
Date: Tue, 30 May 1995 19:45:29 +0500

Thanks for opening the discussion, Bert.  

| Now that the style list is officially open, it is time to think about
| its agenda. Style sheets are very much needed on the Web, so we should
| be very careful that we don't make any mistakes, because we probably
| can't fix them later.

No.  We will make mistakes, and we must then fix them.  We should
still be very careful, though.  But there's some confusion about
who we are and what we're doing.

| My intuition says that Arena's style sheets are heading roughly in the
| right direction, although a number of details will need to change. But
| I'd rather not trust intuition.
| 
| So I suggest that we collect some arguments pro and con the following
| issues, before we start with the details of syntax and the list of
| style properties. Now that the mailings are archived (thanks, Nick!),
| we can refer back to those arguments when the full proposal is
| written.

What proposal is that, specifically?  Hakon's?

|   1. Are we sure there is no existing language that we can copy?

We can inquire about the status of the DSSSL-Light work.

|   2. Do we agree on the goals as stated in the Cascading Style Draft[1]
|      and the `Charter'[2]?

The Charter reads like an IETF WG charter, but this is only a news
group.  Was it your intention to move this effort out of HTML-WG?
Is this really a W3 equivalent of an IETF WG?  If not, language such as,

"The goal of the mailing list is to create or standardize on one or more
languages for specifying the lay out of data that is marked up in SGML"

is improper.  I would prefer,

"This mailing list is intended for discussion of one or more ..."
perhaps with some reference to HTML-WG.  (btw, layout is one word.)

Furthermore,

	http://www.w3.org/hypertext/WWW/Style/css/draft.html

is called a "Draft Specification," yet remarks

"The purpose of this document is to keep track of ideas and suggestions
   related to the cascading style sheet proposal. It's a scratchpad."

which is not the same thing, and

	http://www.w3.org/hypertext/WWW/Style/Welcome.html

says bluntly, "Discussions take place in [email-masked]."
So what's going on?  Hakon, do you intend your work to become an
IETF I-D, RFC, etc.?  Is this to be an independent effort of W3?
What's the relationship to HTML-WG if any?  If none, who are we
and to what extent is W3 going to pay any attention to what we
say?  What's the W3 framework for independent efforts, if that's
what this is?

|      For example: do the phrases "not SGML-complete" from the former
|      and "useful subset of all possible SGML" from the latter
|      contradict each other or not?

Hakon might expand the first phrase so that it says
what he means to convey.

|      In particular, do we agree on the fifth goal in the `Charter'[2],
|      which states that the style language does not depend on the
|      particular names of elements & attributes of HTML?

why should it?

| And, if we agree that a new language is needed:
| 
|   3. What is the (abstract) formatting model that we assume?
| 
|      For example: TeX uses `boxes & glue', DSSSL has a `page model &
|      flow ojects', the simple model that I described[3] has a page
|      model with five areas each of which is filled with a continuous
|      stream of words. And how about non-visual media?

Yes, well, who are we and what are we doing?  I don't need a style
sheet for nonvisual media, but if "sound alternatives" could be
specified in a graphical style sheet that presumably would be a
plus for the blind (in the manner of ALT).

|      A relatively high-level model is dangerous ("doesn't it exclude
|      something important?") but useful, since it allows us to write
|      translators to lower-level languages such as TeX.
| 
|   4. How powerful can/need we make the addressing scheme?
| 
|      Although the difference is small, I think my proposal[4] is more
|      elegant, more powerful, and not more complex then H=E5kon's[5].

Dealing only with yours, Bert, I'd like the ability to make reference
by ID as well as GI and attribute value.  I am also absolutely 
certain that

       Information about elder siblings of each open element need to be
       available only up to a certain fixed depth, so that a fixed amount of
       space can be reserved for this information in the stack frame.

is a concept that will come back and bite you.  I might need to know 
any arbitrary parent element to format an element in context correctly.

Also, how can I address by GI and attribute value if

	No knowledge of the DTD is assumed.
?

|   5. How many levels of cascading priorities do we need?
| 
|      As a computer scientist, I would say that H=E5kon's three[6] is a

Did not find 3 mentioned there.  From what follows I assume you mean
"insist, important, normal."  I agree I don't see the point of 
normal.

|      strange number, I would rather have either two[7] or very
|      many. (I consider `default' and `lens' as outside this range,
|      since they need not use the same language.)
| 
|   6. How powerful can/need we make the expression language?
| 
|      We probably don't need things like macros right away, but
|      numerical and other operators might be useful.[9]
|
| And finally, we can invent a syntax (context-free, of course) and draw
| up a list of style properties, being careful that we don't include
| things that will make it impossible to add more powerful properties
| later.

Um, why do we have to write a programming language for this?  
and agree upon it, and standardize it?  it's the content we want
to discuss, right?  DSSSL didn't create a new programming
language (if I have this straight), and there are various SGML
style DTDs (FOSI, Synex's version now available in Panorama);
I'll bet there are yet other languages in use for this purpose.
What's to be gained by inventing another?

| I'm sure we will encounter difficult decisions along the way. I've
| already started a collection[8], though I hope that they will turn out
| to be not so difficult after all.

Wishful thinking.  Typography is not easy.  Typography for online 
presentation is a topic barely scratched by practice as yet (look
at all the presentational devices people want to have in HTML).
Let me suggest that a good thread would be

|   3. What is the (abstract) formatting model that we assume?
|      For example: TeX uses `boxes & glue', DSSSL has a `page model &
|      flow ojects', the simple model that I described[3] has a page
|      model with five areas each of which is filled with a continuous
|      stream of words. And how about non-visual media?

You admit that your model is insufficient for tables; why shouldn't
we discard it, and what is Hakon's formatting model (it isn't obvious
from his TOC)?  what mods to DSSSL's model have the DSSSL-Light folks
determined necessary?  your model has among its five areas header and
footer; is this enough special-purpose-online-presentational areas?
won't somebody be asking for "left-margin-banner" and "wrap-around-
the-whole-frame-banner" soon?

-- 
Terry Allen  ([email-masked])   O'Reilly & Associates, Inc.
Editor, Digital Media Group    101 Morris St.
			       Sebastopol, Calif., 95472
occasional column at:  http://gnn.com/meta/imedia/webworks/allen/

A Davenport Group sponsor.  For information on the Davenport 
  Group see ftp://ftp.ora.com/pub/davenport/README.html
	or  http://www.ora.com/davenport/README.html

---

From: Bert Bos <[email-masked]>
Date: Wed, 31 May 1995 08:12:40 +0500

Terry Allen writes:
 |
 |Thanks for opening the discussion, Bert.  
 |
 || Now that the style list is officially open, it is time to think about
 || its agenda. Style sheets are very much needed on the Web, so we should
 || be very careful that we don't make any mistakes, because we probably
 || can't fix them later.
 |
 |No.  We will make mistakes, and we must then fix them.  We should
 |still be very careful, though.  But there's some confusion about
 |who we are and what we're doing.
 |
 || My intuition says that Arena's style sheets are heading roughly in the
 || right direction, although a number of details will need to change. But
 || I'd rather not trust intuition.
 || 
 || So I suggest that we collect some arguments pro and con the following
 || issues, before we start with the details of syntax and the list of
 || style properties. Now that the mailings are archived (thanks, Nick!),
 || we can refer back to those arguments when the full proposal is
 || written.
 |
 |What proposal is that, specifically?  Hakon's?

I expect that eventually the style language will be specified in an
RFC. I'm willing to help write it and I hope Hakon is. It will not be
the same as any of the current proposals, but my expectation is that
it will be recognizably a descendant of Hakon's ideas. I also think
that we should wait and watch this mailing list for a few weeks,
before commiting any resources to this effort.

 ||   1. Are we sure there is no existing language that we can copy?
 |
 |We can inquire about the status of the DSSSL-Light work.
 |
 ||   2. Do we agree on the goals as stated in the Cascading Style Draft[1]
 ||      and the `Charter'[2]?
 |
 |The Charter reads like an IETF WG charter, but this is only a news
 |group.  Was it your intention to move this effort out of HTML-WG?
 |Is this really a W3 equivalent of an IETF WG?  If not, language such as,
 |
 |"The goal of the mailing list is to create or standardize on one or more
 |languages for specifying the lay out of data that is marked up in SGML"
 |
 |is improper.  I would prefer,
 |
 |"This mailing list is intended for discussion of one or more ..."
 |perhaps with some reference to HTML-WG.  (btw, layout is one word.)

You're probably right that the weaker goal of "discussion" is better,
though I hope that the discussion will eventually help to create some
product (i.e., a specification).

It *is* my intention that style specifications are independent of HTML
(and hence the HTML WG), though one of the goals is, of course, that
the styles work well with the particular dialect of SGML called
HTML. I don't know if we need an IETF Working Group for this, I've no
experience in these matters.

 |Furthermore,
 |
 |	http://www.w3.org/hypertext/WWW/Style/css/draft.html
 |
 |is called a "Draft Specification," yet remarks
 |
 |"The purpose of this document is to keep track of ideas and suggestions
 |   related to the cascading style sheet proposal. It's a scratchpad."
 |
 |which is not the same thing, and
 |
 |	http://www.w3.org/hypertext/WWW/Style/Welcome.html
 |
 |says bluntly, "Discussions take place in [email-masked]."
 |So what's going on?  Hakon, do you intend your work to become an
 |IETF I-D, RFC, etc.?  Is this to be an independent effort of W3?
 |What's the relationship to HTML-WG if any?  If none, who are we
 |and to what extent is W3 going to pay any attention to what we
 |say?  What's the W3 framework for independent efforts, if that's
 |what this is?
 |
 ||      For example: do the phrases "not SGML-complete" from the former
 ||      and "useful subset of all possible SGML" from the latter
 ||      contradict each other or not?
 |
 |Hakon might expand the first phrase so that it says
 |what he means to convey.
 |
 ||      In particular, do we agree on the fifth goal in the `Charter'[2],
 ||      which states that the style language does not depend on the
 ||      particular names of elements & attributes of HTML?
 |
 |why should it?

One example of such an (unwanted, IMHO) dependency is the fact that
Hakon's style language currently presupposes the existence of an
attribute CLASS, because that's what the notation `H1.punk' means. To
fix this, I proposed a global declaration `@archform CLASS', to be
inserted at the start of the style sheet, so that applications would
now what the dot stands for. (Btw. a `.' is maybe not a good choice,
since the dot is often used a name character in SGML; that's why I
used `@' instead.)

 || And, if we agree that a new language is needed:
 || 
 ||   3. What is the (abstract) formatting model that we assume?
 || 
 ||      For example: TeX uses `boxes & glue', DSSSL has a `page model &
 ||      flow ojects', the simple model that I described[3] has a page
 ||      model with five areas each of which is filled with a continuous
 ||      stream of words. And how about non-visual media?
 |
 |Yes, well, who are we and what are we doing?  I don't need a style
 |sheet for nonvisual media, but if "sound alternatives" could be
 |specified in a graphical style sheet that presumably would be a
 |plus for the blind (in the manner of ALT).

There is more than `sound alternatives' isn't there? I suppose stress,
speed, pauses, alternating male/female voices, and bell signals can
also help to clarify the meaning of a text.

 ||      A relatively high-level model is dangerous ("doesn't it exclude
 ||      something important?") but useful, since it allows us to write
 ||      translators to lower-level languages such as TeX.
 || 
 ||   4. How powerful can/need we make the addressing scheme?
 || 
 ||      Although the difference is small, I think my proposal[4] is more
 ||      elegant, more powerful, and not more complex then H=E5kon's[5].
 |
 |Dealing only with yours, Bert, I'd like the ability to make reference
 |by ID as well as GI and attribute value.

The notation currently allows reference to an ID only if you also know
the GI (e.g., `P[ID=p349a]'). My previous proposal `stream based style
sheets'[10] allowed reference to an ID without knowing the GI. Maybe I
should reintroduce that feature.

 | I am also absolutely 
 |certain that
 |
 |       Information about elder siblings of each open element need to be
 |       available only up to a certain fixed depth, so that a fixed amount of
 |       space can be reserved for this information in the stack frame.
 |
 |is a concept that will come back and bite you.  I might need to know 
 |any arbitrary parent element to format an element in context correctly.

I wanted to restrict the amount of memory needed and also to simplify
the implementation. The idea is that you do not need the whole SGML
*tree*, but only a *stack* of currently open elements, plus for each
open element the GI (and only the GI) of its elder sister. The depth
of the stack is not limited.

For example, given the partial document

  <A attrA>
      <B attrB>
          <P>...</P>
          <Q>...</Q>
      </B>
      <C attrC>
          <D attrD>
              <R>...</R>
              <S>...</S>
          </D>
          <E attrE>
              You are here

The stack would contain

    +----------+-------------------+--------------+
    | GI = "E" | attribs = "attrE" | sister = "D" |   <-- top of stack
    +----------+-------------------+--------------+
    | GI = "C" | attribs = "attrC" | sister = "B" |
    +----------+-------------------+--------------+
    | GI = "A" | attribs = "attrA" | sister = 0   |
  --+----------+-------------------+--------------+--

Note that the nesting is still intact, but the attributes of D and B
are no longer available and all information about P, Q, R and S is
lost.

 |Also, how can I address by GI and attribute value if
 |
 |	No knowledge of the DTD is assumed.
 |?

So much of an SGML document can be parsed without the DTD (provided
the use of OMITTAG is restricted to some specific cases and SHORTREFS
and other things are expanded before the server sends the document to
the client), that it seems rather a waste of effort if the formatter
always had to retrieve and analyse a DTD for only a little gain.

The only thing (I think) that such an `SGML normal form' is unable to
(legally) express is empty tags and I'm willing to add that
information to the style sheet.

(It can be argued that the `normal form' is often longer than the
original, but it will usually be shorter than the original plus the
DTD, and it simplifies the parser tremendously.)

 ||   5. How many levels of cascading priorities do we need?
 || 
 ||      As a computer scientist, I would say that H=E5kon's three[6] is a
 |
 |Did not find 3 mentioned there.  From what follows I assume you mean
 |"insist, important, normal."  I agree I don't see the point of 
 |normal.
 |
 ||      strange number, I would rather have either two[7] or very
 ||      many. (I consider `default' and `lens' as outside this range,
 ||      since they need not use the same language.)
 || 
 ||   6. How powerful can/need we make the expression language?
 || 
 ||      We probably don't need things like macros right away, but
 ||      numerical and other operators might be useful.[9]
 ||
 || And finally, we can invent a syntax (context-free, of course) and draw
 || up a list of style properties, being careful that we don't include
 || things that will make it impossible to add more powerful properties
 || later.
 |
 |Um, why do we have to write a programming language for this?  
 |and agree upon it, and standardize it?  it's the content we want
 |to discuss, right?  DSSSL didn't create a new programming
 |language (if I have this straight), and there are various SGML
 |style DTDs (FOSI, Synex's version now available in Panorama);
 |I'll bet there are yet other languages in use for this purpose.
 |What's to be gained by inventing another?

(DSSSL borrowed from Scheme and I think a Scheme interpreter may be a
starting point for an implementation, but I don't think it can remain
unchanged.)

I believe we *do* need a language (although I've no objection to
extending an existing one, if a good candidate can be found; see item
1 above). Talking about content alone is not enough, we will have to
write that content down unambigouously and in such a way that a
computer program can understand it.

 || I'm sure we will encounter difficult decisions along the way. I've
 || already started a collection[8], though I hope that they will turn out
 || to be not so difficult after all.
 |
 |Wishful thinking.  Typography is not easy.  Typography for online 
 |presentation is a topic barely scratched by practice as yet (look
 |at all the presentational devices people want to have in HTML).
 |Let me suggest that a good thread would be
 |
 ||   3. What is the (abstract) formatting model that we assume?
 ||      For example: TeX uses `boxes & glue', DSSSL has a `page model &
 ||      flow ojects', the simple model that I described[3] has a page
 ||      model with five areas each of which is filled with a continuous
 ||      stream of words. And how about non-visual media?
 |
 |You admit that your model is insufficient for tables; why shouldn't
 |we discard it, and what is Hakon's formatting model (it isn't obvious
 |from his TOC)?  what mods to DSSSL's model have the DSSSL-Light folks
 |determined necessary?  your model has among its five areas header and
 |footer; is this enough special-purpose-online-presentational areas?
 |won't somebody be asking for "left-margin-banner" and "wrap-around-
 |the-whole-frame-banner" soon?

Excellent idea. Let's talk about this for a while. I'm not happy with
that model either. Maybe the page model should be parametrized, maybe
we need something different altogether.

Thanks, Terry. I hope more people will take the time to actually
compare the various documents and comment on them. (Everything is
linked from <http://www.w3.org/hypertext/WWW/Style/>.)

Bert

[10]: http://www.let.rug.nl/~bert/stylesheets.html

---

From: "H&kon W Lie" <[email-masked]>
Date: Wed, 31 May 1995 09:27:57 +0500

> What proposal is that, specifically?  Hakon's?

I have suggested teaming up to write a new, complete proposal -- but
not a completely new proposal. We have a number of proposals from
which we can do some cutting & pasting. I have started working on such
a document (http://www.w3.org/hypertext/WWW/Style/css/draft.html) and
will happily continue unless other people have better strategies.

 >    related to the cascading style sheet proposal. It's a scratchpad."

I imagine this document going through several phases. Starting as a
scratchpad, it should end up as an I-D. I've changed the wording on
the top to better reflect this, thanks!

 > says bluntly, "Discussions take place in [email-masked]."

Blunt it was. Rephrased.

 > say?  What's the W3 framework for independent efforts, if that's

The mailing was created to have a medium through which people
interested in style sheets & the web can communicate since none of the
existing mailing lists are fit for this purpose. I proposed an
informal charter (.. to support the specification and the
implementations of an HTML style sheet mechanism.) and gave a
reference to Bert's more specific wordings. All of this is open for
discussion, and I'm glad we've started!

The creation of this mailing list is not an official act of W3C or any
other organization. W3C has (as far as I know) not made any statements
with regard to the issues we will be discussing. W3C simply hosts the
disussions like it hosts www-talk, www-lib etc. Will W3C pay attention
in the end? I think so, if the end result is good. Will the commercial
browser vendors pay attention? I think so, if the end result is
good. Will HTTP-WG pay attention? Who knows?

Some people have privately suggested that we form a new working group
within IETF. This may be an option in the future, but for now I think
we should concentrate on finding/developing a commmon foundation.

 > Hakon might expand the first phrase so that it says

If conflicts arise between legibility and completeness, I may end up
on legibility's side. Also, the SGML community seems happy with
DSSSL-*, so why spend the extra x months of discussions that we'll
need to finalize an SGML-complete proposal? If (x<1) then..

 > |      particular names of elements & attributes of HTML?

Agree, in principle. Conflicts arise when you want to specify style
for non-HTML information, e.g.

 - the whole document: "doc: margin.left = 50pt" -- I'm not sure
   we can convince people to use "html of "body" instead of "doc".

 - browser buttons: "browser: button.save = off"

 - html source: "source: font.size = 14pt"

These conflicts will arrive when we try to handle a DTD with <SOURCE>.
So, an item for discussion should be to what extent, if any, the style
sheet should be able to influence non-HTML properties, or take
non-HTML information (like AGE and LANGUAGE) into account when
rendering. The author of a document shouldn't decide how e.g. the html
source should be displayed, but certainly the user should. And if it's
not in the style sheet, where will in be? I hate .Xdefaults!

Perhaps there are ways to cleanly avoid conflicts?

 > plus for the blind (in the manner of ALT).

One of the reasons why I like the term "style sheet" is that it's
neutral with regard to the visibility of the medium. 
"H1: speech.volume = 50db" should be within reach.

 > "insist, important, normal."  I agree I don't see the point of 

Hehe. We can discuss this issue till the web is dead. Initially I
wanted to give the author two levels (I've done some computer science
:-), but in order for the user to "wrap around" the author on both
sides, three was needed. Later, the "legal" flag came up (I'm still
not happy about pretending to give legeal guarantees in an optional
style sheet, though), and there are three on each side in the current
propsal. With plenty of room for discussion.

 > Um, why do we have to write a programming language for this?  

We shouldn't. We may need a little language, but not a programming
language. Simple, declarative statements will do just fine. If not,
use PDF or DSSSL. I vote for having +-/*, the ability to refer to
other properties, and simple constants.

When choosing the syntax for the declarative statements, user
legibility/writability should be #1.

 > we discard it, and what is Hakon's formatting model (it isn't obvious

I'm proposing a simple stream of boxes where the style sheet controls
the margins of each box. The boxes are stacked on top of each other
(perhaps with a page break here & there), and children inherit the
parent's horizontal boundry + margins (i.e. to do indented nested
list). Paper delivery will require some extensions to this model.

-h&kon

Hakon W Lie, WWW project CERN, CH-1211 Geneva 23
http://www.w3.org/hypertext/WWW/People/howcome/

---

From: Terry Allen <[email-masked]>
Date: Wed, 31 May 1995 10:53:14 +0500

A few procedural points, then on to the meat.

Hakon:
| Terry ( >) and Bert ( > |) write:
|  > | So I suggest that we collect some arguments pro and con the following
|  > | issues, before we start with the details of syntax and the list of
|  > | style properties. Now that the mailings are archived (thanks, Nick!),
|  > | we can refer back to those arguments when the full proposal is
|  > | written.
|  > What proposal is that, specifically?  Hakon's?
   ...
| I imagine this document going through several phases. Starting as a
| scratchpad, it should end up as an I-D. I've changed the wording on
| the top to better reflect this, thanks!

If it's going to be an I-D, does that mean it has to come under
the aegis of some WG?

|  > So what's going on?  Hakon, do you intend your work to become an
|  > IETF I-D, RFC, etc.?  Is this to be an independent effort of W3?
|  > What's the relationship to HTML-WG if any?  If none, who are we
|  > and to what extent is W3 going to pay any attention to what we
|  > say?  What's the W3 framework for independent efforts, if that's
|  > what this is?
| 
| The mailing was created to have a medium through which people
| interested in style sheets & the web can communicate since none of the
| existing mailing lists are fit for this purpose. I proposed an
| informal charter (.. to support the specification and the
| implementations of an HTML style sheet mechanism.) and gave a
| reference to Bert's more specific wordings. All of this is open for
| discussion, and I'm glad we've started!

As am I.

| The creation of this mailing list is not an official act of W3C or any
| other organization. W3C has (as far as I know) not made any statements
| with regard to the issues we will be discussing. W3C simply hosts the
| disussions like it hosts www-talk, www-lib etc. Will W3C pay attention
| in the end? I think so, if the end result is good. Will the commercial
| browser vendors pay attention? I think so, if the end result is
| good. Will HTTP-WG pay attention? Who knows?

It was W3's role in standardization that was confusing.  As I understand
your response, W3 is taking no such role; that's okay.

Okay.

|  > |      For example: do the phrases "not SGML-complete" from the former
|  > |      and "useful subset of all possible SGML" from the latter
|  > |      contradict each other or not?
|  > 
|  > Hakon might expand the first phrase so that it says
|  > what he means to convey.
| 
| If conflicts arise between legibility and completeness, I may end up
| on legibility's side. Also, the SGML community seems happy with
| DSSSL-*, so why spend the extra x months of discussions that we'll
| need to finalize an SGML-complete proposal? If (x<1) then..

Any proposal limited to a single DTD will have to be reworked later.
You might omit handling some SGML features, but we seem to have most
of them in HTML.  If x<1, then we'd still have spent x<1 months
discussing a proposal that might be bettered by DSSSL-L; I think
DSSSL would be a good point of reference here.

|  > |      In particular, do we agree on the fifth goal in the `Charter'[2],
|  > |      which states that the style language does not depend on the
|  > |      particular names of elements & attributes of HTML?
|  > why should it?
| 
| Agree, in principle. Conflicts arise when you want to specify style
| for non-HTML information, e.g.
|  - the whole document: "doc: margin.left = 50pt" -- I'm not sure
|    we can convince people to use "html of "body" instead of "doc".
|  - browser buttons: "browser: button.save = off"
|  - html source: "source: font.size = 14pt"
| These conflicts will arrive when we try to handle a DTD with <SOURCE>.
| So, an item for discussion should be to what extent, if any, the style
| sheet should be able to influence non-HTML properties, or take
| non-HTML information (like AGE and LANGUAGE) into account when
| rendering. The author of a document shouldn't decide how e.g. the html
| source should be displayed, but certainly the user should. And if it's
| not in the style sheet, where will in be? I hate .Xdefaults!

Margins aside, I think such things go in what I think of as another style 
sheet, though this could be info in HEAD or a part of the rendering style
sheet.  There's a large iceberg of nonrendering info people want to
convey to the browser (browser buttons being a good example).  

 ...
|  > |      As a computer scientist, I would say that H=E5kon's three[6] is a
|  > Did not find 3 mentioned there.  From what follows I assume you mean
|  > "insist, important, normal."  I agree I don't see the point of 
|  > normal.
| 
| Hehe. We can discuss this issue till the web is dead. Initially I
| wanted to give the author two levels (I've done some computer science
| :-), but in order for the user to "wrap around" the author on both
| sides, three was needed. Later, the "legal" flag came up (I'm still
| not happy about pretending to give legeal guarantees in an optional
| style sheet, though), and there are three on each side in the current
| propsal. With plenty of room for discussion.

I don't know about the current mechanism, but let me put the case for
something like "legal."  As a publisher, I may need to insist that 
my doc be read only according to a style sheet I supply.  I know that
I probably can't find a mechanism to enforce that on the browser,
but at least I have to be able to say it.  (Then if the user insists
on rendering Warnings as gray text on a grey background, fails to
read a Warning, and electrocutes himself, I'm in the clear.)

  ...
|  > we discard it, and what is Hakon's formatting model (it isn't obvious
| 
| I'm proposing a simple stream of boxes where the style sheet controls
| the margins of each box. The boxes are stacked on top of each other
| (perhaps with a page break here & there), and children inherit the
| parent's horizontal boundry + margins (i.e. to do indented nested
| list). Paper delivery will require some extensions to this model.

Could you compare this model to Tex's?  No glue, obviously ...

---

From: "H&kon W Lie" <[email-masked]>
Date: Thu, 1 Jun 1995 12:00:42 +0500

> before commiting any resources to this effort.

Agree. People with diverging ideas whould speak up.

 > now what the dot stands for.

This is where it starts to get hairy and perl-like. Myself, I enjoy
writing perl, but I would prefer the style sheet language to be a bit
more intuitive. "@archform" isn't.

 > of the stack is not limited.

Sounds reasonable, but you may need more that a fixed amount, no? This
is also why I dropped the idea of being able to combine hierarchical
and sequential search patterns.

 > we need something different altogether.

Grids! Let the style sheet carve up the canvas into golden rectangles,
and use an expert system to lay out the elements!! Ok, drop the expert
system and define a set of simple rules that we hardcode.. whoops! But
grids do look nice!

-h&kon

---

From: "H&kon W Lie" <[email-masked]>
Date: Thu, 1 Jun 1995 12:06:44 +0500

Terry,

 > If it's going to be an I-D, does that mean it has to come under

I would think so. Do you have a favorite?

 > your response, W3 is taking no such role; that's okay.

At this point in time, in this area, W3C hasn't taken on any
standardiszation role.

 > convey to the browser (browser buttons being a good example).  

Except for the button example, the others are rendering issues. As for
buttons, choosing to display or hide them is also a rendering issue
since you gain/loose screen real-estate depending on your choice. I
would hope the style sheet mechanism would convey rendering
information peripheral to HTML as well. Users will ask for it.

Are you suggesting we should have two style sheet mechanisms?

 > read a Warning, and electrocutes himself, I'm in the clear.)

This seems to be the prevailing view among publishers, and it makes
some sense. But, I don't think the style sheet mechanism is the best
legal cover you can find. Since style sheets can be LINKed from a
document (most proposals suggest this), it may or may not reach the
browser. So, should the browser refuse to show a document just because
the style sheet may include lagal hints? I don't think so. This is
just one of the questions that arise if we decide to deal with
legality.

 > Could you compare this model to Tex's?  No glue, obviously ...

No glue. And no nested boxes. Just a simple stack of boxes similar to
how current browsers format HTML (tables and images in text flow
excluded).

 _______________
|               |
|*P             |
|_______________|
|               |
|@@UL           |
|_______________|
   |            |
   |%LI         |
   |____________|
   |            |
   |%LI         |
   |____________|
   |            |
   |@@UL        |
   |____________|
      |         |
      | %LI     |
 _____|_________|
|               |
|*P             |
|_______________|

where: 

 '*'  = p  [margin.left]
 '@@' = ul [margin.left]
 '%'  = li [margin.left]

Children inherit their parent's x position + margin.left.

Thus, one can control list indentations by setting margins. 

Text flow around floating images does not fit well into this model,
e.g. you probably don't want to use the normal margins when placing
text next to an image.

One could add some extra properties if control at that level is
necessary.

-h&kon

---

From: "Terry Allen" <[email-masked]>
Date: Thu, 1 Jun 1995 13:43:00 +0500

Thanks, Hakon.

Hakon writes:
|  > | I imagine this document going through several phases. Starting as a
|  > | scratchpad, it should end up as an I-D. I've changed the wording on
|  > | the top to better reflect this, thanks!
|  > 
|  > If it's going to be an I-D, does that mean it has to come under
|  > the aegis of some WG?
| 
| I would think so. Do you have a favorite?

It's your choice, I'd say.  But HTML-WG would seem to be appropriate
(there's always MIMESGML).
 
  ...

|  > | Agree, in principle. Conflicts arise when you want to specify style
|  > | for non-HTML information, e.g.
|  > |  - the whole document: "doc: margin.left = 50pt" -- I'm not sure
|  > |    we can convince people to use "html of "body" instead of "doc".
|  > |  - browser buttons: "browser: button.save = off"
|  > |  - html source: "source: font.size = 14pt"
|  > | These conflicts will arrive when we try to handle a DTD with <SOURCE>.
|  > | So, an item for discussion should be to what extent, if any, the style
|  > | sheet should be able to influence non-HTML properties, or take
|  > | non-HTML information (like AGE and LANGUAGE) into account when
|  > | rendering. The author of a document shouldn't decide how e.g. the html
|  > | source should be displayed, but certainly the user should. And if it's
|  > | not in the style sheet, where will in be? I hate .Xdefaults!
|  > 
|  > Margins aside, I think such things go in what I think of as another style 
|  > sheet, though this could be info in HEAD or a part of the rendering style
|  > sheet.  There's a large iceberg of nonrendering info people want to
|  > convey to the browser (browser buttons being a good example).  
| 
| Except for the button example, the others are rendering issues. As for

Okay.  Let me put it differently.  I don't see the what the problem
is with margins for the whole doc and font size for the whole doc.
That info can be attached to HTML or BODY; what do you mean by
"non-HTML info" wrt these items?

| buttons, choosing to display or hide them is also a rendering issue
| since you gain/loose screen real-estate depending on your choice. I
| would hope the style sheet mechanism would convey rendering
| information peripheral to HTML as well. Users will ask for it.

You're assuming the buttons would be rendered in the text window,
which would not be a useful way to handle them (change the frame,
institute a toolbar; but these are choices for developers to make).
In any event, presentation of buttons is one of a large set of
ways people will want to affect browser behavior; that's why
I separate it from how the text itself is rendered.  For buttons
we don't have the issues of font and flow and so on (those are
presumably handled by the browser directly without instruction).

| Are you suggesting we should have two style sheet mechanisms?

I'm saying that we have different types of info we want to convey.
Text rendering is one.  Buttons+ is another; style sheets for
link behavior (if we get to them) might be another.  The mechanism
we use for text rendering may not be best for the other types 
of info; if it is, okay.

|  > I don't know about the current mechanism, but let me put the case for
|  > something like "legal."  As a publisher, I may need to insist that 
|  > my doc be read only according to a style sheet I supply.  I know that
|  > I probably can't find a mechanism to enforce that on the browser,
|  > but at least I have to be able to say it.  (Then if the user insists
|  > on rendering Warnings as gray text on a grey background, fails to
|  > read a Warning, and electrocutes himself, I'm in the clear.)
| 
| This seems to be the prevailing view among publishers, and it makes
| some sense. But, I don't think the style sheet mechanism is the best
| legal cover you can find. Since style sheets can be LINKed from a
| document (most proposals suggest this), it may or may not reach the
| browser. So, should the browser refuse to show a document just because
| the style sheet may include lagal hints? I don't think so. This is
| just one of the questions that arise if we decide to deal with
| legality.

Well, I might configure my server to send the style sheet first,
with some query (I don't know what) to see if the client has
received it.  Or I might rely on the HTML doc's instructions 
as to what style sheet was intended.  I would certainly want
to put up a text warning also ("use chair.sty or risk electrocution!").
But at the level of negotiation, I as publisher have to be able
to say no, whether or not I can enforce it.

|  > | I'm proposing a simple stream of boxes where the style sheet controls
|  > | the margins of each box. The boxes are stacked on top of each other
|  > | (perhaps with a page break here & there), and children inherit the
|  > | parent's horizontal boundry + margins (i.e. to do indented nested
|  > | list). Paper delivery will require some extensions to this model.
|  > 
|  > Could you compare this model to Tex's?  No glue, obviously ...
| 
| No glue. And no nested boxes. Just a simple stack of boxes similar to
| how current browsers format HTML (tables and images in text flow
| excluded).

With this model, how are we to handle the case (widely desired) of 
overlaying text on a graphic?

 ...

| Thus, one can control list indentations by setting margins. 
| 
| Text flow around floating images does not fit well into this model,
| e.g. you probably don't want to use the normal margins when placing
| text next to an image.

Could you expand on that?  Which margins become inappropriate?

---

From: "H&kon W Lie" <[email-masked]>
Date: Fri, 2 Jun 1995 12:25:46 +0500

Terry,

 > "non-HTML info" wrt these items?

We agree on margins, they can cleanly be attached to head or body. (The
objection there, though, is that most users don't user <HTML> or <BODY>
and would rather (I'm guessing) refer to an imaginary <DOC> element
or whatever.)

 > institute a toolbar; but these are choices for developers to make).

The most successful browsers allow the user to turn garniture on & off
through menus. I'm pretty sure you can set this in a defaults file as
well. Since this has to do with the rendering of the the browser
window (but not the HTML canvas), why not -- when designing a style
sheet mechanism -- include control for these "HTML-peripheral" items?

 > presumably handled by the browser directly without instruction).

If you're visually impaired, you want control over button fonts. For
the user, setting the fonts for the buttons is as natural as setting
the fonts for HTML elements, and the same mechanism should be
used. For browser implementors, reusing code to allocate fonts etc. is
feasible. 

I'm not sure where I want to draw the line in this issue. Disableing
one single feature (e.g. the save button) will be asked for by some,
but I think this is beyond a style sheet. Removing all garniture to
allow the maximum size HTML canvas isn't.

 > we use for text rendering may not be best for the other types 

I think we'll find a way. Who can come up with a good syntax?

 > to say no, whether or not I can enforce it.

We should also be able to come up with some finely tuned wording here,
Bert has a good start.

 > overlaying text on a graphic?

Are you referring to the current wave of background images, or to a
future extension to HTML? I presume the latter. I don't think the
style sheet mechanism should be used to merge the two. The style sheet
would see a simple box, just as it sees any other box. Part of the
trick in writing a successful proposal is to keep it simple. I'm
willing to cut corners for tables, maths, text overlays on graphic
etc.

 > Could you expand on that?  Which margins become inappropriate?

E.g.:
____________

 H1 has a 1 character left margin

 So does H2

      P starts here and could
      go on forever. Wow, a 5
      character left margin 
      sure looks great!
       _____ 
      | + + | Wow, you can do 
      |  @  | images as well?
      | --- | Then you'll 
      |_____| want a 1 character
      margin on the left side.
      Until, you're below the
      image that is.
_____________

This is where we the simple stacked box model is a bit too simple. Some
possible remedies are:

  P:  margin.left = 40pt
  P:  img.margin.left = 10pt

or 

  IMG: margin.right = 10 pt

I'm sure there are other ways as well.

As you know, the WWW project is being evacuated from CERN. My
transition period to INRIA has started, and I'll be mostly without net
access for the next couple of weeks. I've enjoyed, and learned from,
the discusssions so far, and hope they will continue.

-h&kon

---

From: "Terry Allen" <[email-masked]>
Date: Fri, 2 Jun 1995 17:54:14 +0500

Hakon writes:
 ...
| We agree on margins, they can cleanly be attached to head or body. (The
| objection there, though, is that most users don't user <HTML> or <BODY>
| and would rather (I'm guessing) refer to an imaginary <DOC> element
| or whatever.)

I don't quite see the problem in this context.  I should think that
a style sheet for HTML would use HTML rather than DOC.  The stylist
has to know at least the element names in the DTD.  For SGML
in general, there is another question.

Suppose I have an instance with a doctype that is not the most general 
possible element in the DTD.  (I use Docbook here rather than HTML,
because it's hard to find an element in HTML the use of which doesn't
imply HTML as the doctype, and because of the convention that you
throw away the doctype of an HTML instance.) For example:

<!doctype para system "docbook.2.2.1.dtd">
<para>a paragraph</para>

Now given a style sheet for Docbook that specifies formatting
for Set, Book, Chapter, etc., what expectation should there be
that the paras in this instance will inherit the formatting of
some parent (such as Chapter)?  Note that para can be the child
of various parents, and that if you're rendering Chapters 
differently from Appendices, you're up the creek here unless you
specify base font size, etc., on every element.  (I'm copying 
Eve Maler on this because I think this question must have cropped
up in her FOSI work.)

 ...
|  > You're assuming the buttons would be rendered in the text window,
|  > which would not be a useful way to handle them (change the frame,
|  > institute a toolbar; but these are choices for developers to make).
| The most successful browsers allow the user to turn garniture on & off
| through menus. I'm pretty sure you can set this in a defaults file as
| well. Since this has to do with the rendering of the the browser
| window (but not the HTML canvas), why not -- when designing a style
| sheet mechanism -- include control for these "HTML-peripheral" items?

Fine with me if we do it in the same style sheet where we specify
rendering.  But we ought to recognize the difference, so that when
and if we arrive at a point where we should modularize the style
sheet we'll recognize that these could be different modules, 
accepting different plug-ins.  I'll put in a plug here for the
need for a UA specification distinct from HTML, style sheets, HTTP,
etc.

|  > In any event, presentation of buttons is one of a large set of
|  > ways people will want to affect browser behavior; that's why
|  > I separate it from how the text itself is rendered.  For buttons
|  > we don't have the issues of font and flow and so on (those are
|  > presumably handled by the browser directly without instruction).
| 
| If you're visually impaired, you want control over button fonts. For

Yes, indeed.  I was thinking of it from the author's end.  I would
then also want control over other aspects of the GUI, for example,
to enlarge the fonts on all the buttons, not just those in the main
window.  Another item for a UA spec.

 ...
|  > | No glue. And no nested boxes. Just a simple stack of boxes similar to
|  > | how current browsers format HTML (tables and images in text flow
|  > | excluded).
|  > With this model, how are we to handle the case (widely desired) of 
|  > overlaying text on a graphic?
| 
| Are you referring to the current wave of background images, or to a
| future extension to HTML? I presume the latter. I don't think the

I haven't seen any text overlaid on a GIF, am I missing something?
Point me at it, please!  I think we're talking about the same thing,
although 

| style sheet mechanism should be used to merge the two. The style sheet
| would see a simple box, just as it sees any other box. Part of the
| trick in writing a successful proposal is to keep it simple. I'm
| willing to cut corners for tables, maths, text overlays on graphic
| etc.

Okay, good solution.  You do it in the markup.  Dave's current FIG
gives us, in relevant part:

<!ELEMENT FIG - - (OVERLAY*, CAPTION?, %body.content;, CREDIT?) -(FIG|IMG)>
<!ATTLIST FIG
        %attrs;
        %needs;                  -- for control of text flow --
        src  %URI;  #REQUIRED    -- URI of document to embed --
        %url.link;               -- standard link attributes --
        %block.align;            -- horizontal alignment --
        noflow (noflow) #IMPLIED -- noflow around figure --
        width  NUMBER #IMPLIED   -- desired width in units --
        height NUMBER #IMPLIED   -- desired height in units --
        units (em|pixels) pixels -- specifies units as em's or pixels --
        imagemap (%URI) #IMPLIED -- pass background clicks to server --
<!ELEMENT OVERLAY - O EMPTY -- image overlay -->
<!ATTLIST OVERLAY
        src  %URI;  #REQUIRED    -- URI of image overlay --
        %url.link;               -- standard link attributes --
        units (em|pixels) pixels -- specifies units as em's or pixels --
        x      NUMBER   0        -- offset from left in units --
        y      NUMBER   0        -- offset from top in units --
        width  NUMBER #IMPLIED   -- desired width in units --
        height NUMBER #IMPLIED   -- desired height in units --
        imagemap (%URI) #IMPLIED -- pass background clicks to server --

I note that OVERLAY is misnamed.  If I overlay a picture on text
(and it's FIG, not OVERLAY, that may contain text), it will obscure 
the text (except for any transparent or translucent part, but then if 
it's totally transparent it isn't worth much and if only translucency
is dealt with the model is incomplete).  This would better be called
BACKGROUND or BG.  But that's an issue for another list.

I'm sure there will be further discussion of FIG, but for the purposes
of this discussion, it would appear we need only be sure that we
can attach rendering info to the text contents of FIG.

|  > | Thus, one can control list indentations by setting margins. 
|  > | Text flow around floating images does not fit well into this model,
|  > | e.g. you probably don't want to use the normal margins when placing
|  > | text next to an image.
|  > Could you expand on that?  Which margins become inappropriate?
| E.g.:
|  H1 has a 1 character left margin
|  So does H2
| 
|       P starts here and could
|       go on forever. Wow, a 5
|       character left margin 
|       sure looks great!
|        _____ 
|       | + + | Wow, you can do 
|       |  @  | images as well?
|       | --- | Then you'll 
|       |_____| want a 1 character
|       margin on the left side.
|       Until, you're below the
|       image that is.
| _____________
| 
| This is where we the simple stacked box model is a bit too simple. Some
| possible remedies are:
| 
|   P:  margin.left = 40pt
|   P:  img.margin.left = 10pt
| or 
|   IMG: margin.right = 10 pt
| I'm sure there are other ways as well.

Glad you brought this up and provided so nice an example.  I recently
did a demo coded for Netscape (stop laughing) and made use of the 
hspace and vspace atts they've added to IMG:

<IMG align=right hspace=18 vspace=12
SRC="graphics/ueethumb.gif" ALT="book cover">

Now this is real crude (you can't vary the padding top/bottom
or left/right, and the padding appears to be added to the margin of the
column of text, exactly the wrong thing to do as a default).  But
the info is attached to the object, not its container (the para),
as the flow info is.  This is a sort of stones-in-the-stream model.

Elsewhere we seem to fall into a boxes-next-to- or -within-boxes
model, and it seems just slightly odd to me not to attach this
flow and margin info to the container (the para, its div, whatever),
saying, "within this div all IMGs in Ps get treated thus-and-such."

Which model is preferable, and under what circs?

| As you know, the WWW project is being evacuated from CERN. My
| transition period to INRIA has started, and I'll be mostly without net
| access for the next couple of weeks. I've enjoyed, and learned from,
| the discusssions so far, and hope they will continue.

Happy evacuation, and look forward to your return to emaildom.

---

From: David - Morris <[email-masked]>
Date: Thu, 8 Jun 1995 05:38:32 +0500

> institute a toolbar; but these are choices for developers to make).

Let me second and third Terry's observation. I can understand and
even tolerate the notion that there is some small subset of information
which the publisher has the right to insist I see it as intended or
a conforming user agent should refuse to present the information and
anything the publisher has 'bound' to the required material.  The legal
example and warnings about electrocution come to mind. *BUT* the appearance
of my user agent and the various features its developers have created
to differentiate it from its competition is none of the publishers
business. Rendering within the 'information window' should be 
controlled by the style sheet mechanism, the html or other data 
encoding/description language, etc. Anything external to the 
information (content? publishing? text seems to limiting) window is
negotiated between me the user and my user agent developers. I suppose
that the UA developers might choose to encode the result of that
negotiation in a syntax compatible with style sheets but as an
adjunct to a standards group, we shouldn't care.
 
> Could you expand on that?  Which margins become inappropriate?

Seems to me that if normal margins aren't appropriate, perhaps there
isn't enough space next to the image to flow text at all?

Dave Morris