W3C home > Mailing lists > Public > www-style@w3.org > May 1995

Re: www-style working

From: <wmperry@spry.com>
Date: Tue, 9 May 95 09:50 PDT
Message-Id: <m0s8sUE-00000HC@monolith>
To: www-style@w3.org
howcome@w3.org writes:
> The www-style@w3.org mailing list is now operative. You can subscribe
> and unsubscribe through the form interface at
> 
>   http://www.w3.org/hypertext/WWW/Mailing/Form.html
> 
> or by sending mail to listserv@w3.org.
> 
> I will announce the list when the archive is operative. Meanwhile, I'd
> like to test the list in a small scall by moving our until now proviat
> style disussions ont the list. So, feel free to join & post!

  Hello everyone!

  Just want to say hello and test the new list.  I've got most of the
current proposal implemented in Emacs-w3, and it will be part of the stock
2.2.0 release due out sometime this month.

  Looking pretty good, just have to get someone other than Arena and
Emacs-w3 doing it.  Chris and I are going to pummel the others here into
submission and get it into AIR Mosaic as soon as possible.

-Bill P.
eturn-Path: howcome@www4.cern.ch 
Return-Path: <howcome@www4.cern.ch>
Received: from www10.w3.org by www19 (5.0/NSCS-1.0S) 
	id AA16068; Wed, 10 May 1995 11:30:16 +0500
Received: from dxmint.cern.ch by www10.w3.org (5.0/NSCS-1.0S) 
	id AA02441; Wed, 10 May 1995 11:27:40 +0500
Received: from www4.cern.ch by dxmint.cern.ch
	id AA03649; Wed, 10 May 1995 17:27:07 +0200
Received: by www4.cern.ch (5.0/SMI-4.0)
	id AA02650; Wed, 10 May 1995 17:27:01 --100
Date: Wed, 10 May 1995 17:27:01 --100
Message-Id: <9505101527.AA02650@www4.cern.ch>
To: www-style@w3.org
Subject: www-style works!
From: "H&kon W Lie" <howcome@w3.org>
Content-Length: 657

The number of subscribers to this list is steadily increasing, so I
guess the subscribe mechanisms work. I'll make an anouncement as soon
as I have an archive secured. It's good to see that people who were
not explicitly invited also have found their way in.

Meanwhile, I have been upgrading arena to handle some of the new stuff
that is proposed in http://www.w3.org/hypertext/WWW/Style/css/draft.html, 
e.g. LINK and element groups

You will find binaries for sun, ibm, decstation, hp and sgi in 
http://www.w3.org/pub/arena/experimental

Regards,

-h&kon

Hakon W Lie, WWW project CERN, CH-1211 Geneva 23
http://www.w3.org/hypertext/WWW/People/howcome/
eturn-Path: wmperry@spry.com 
Return-Path: <wmperry@spry.com>
Received: from www10.w3.org by www19 (5.0/NSCS-1.0S) 
	id AA27729; Sun, 14 May 1995 18:15:04 +0500
Received: from monolith ([165.121.2.202]) by www10.w3.org (5.0/NSCS-1.0S) 
	id AA09223; Sun, 14 May 1995 18:14:56 +0500
Message-Id: <m0sAlwa-00000HC@monolith>
Date: Sun, 14 May 95 15:15 PDT
From: wmperry@spry.com
To: www-style@w3.org, howcome@w3.org
Errors-To: wmperry@spry.com
Reply-To: wmperry@spry.com
X-Face: O~Rn;(l][/-o1sALg4A@xpE:9-"'IR[%;,,!m7</SYF`{vYQ(&RI1&EiH[FvT;J}@f!4kfz
 x_!Y#=y{Uuj9GvUi=cPuajQ(Z42R[wE@{G,sn$qGr5g/wnb*"*ktI+,CD}1Z'wxrM2ag-r0p5I6\nA
 [WJopW_J.WY;
Subject: conversion chart for pixel->pica->inches->millimiters?
Content-Length: 162

H&kon, or anyone else listening:

  Do you have a handy conversion chart for the various 'spatial'
coordinates that we use in the style sheet proposal?

-Bill P.
eturn-Path: howcome@www4.cern.ch 
Return-Path: <howcome@www4.cern.ch>
Received: from www10.w3.org by www19 (5.0/NSCS-1.0S) 
	id AB01281; Sun, 14 May 1995 18:52:48 +0500
Received: from dxmint.cern.ch by www10.w3.org (5.0/NSCS-1.0S) 
	id AA09452; Sun, 14 May 1995 18:52:41 +0500
Received: from www4.cern.ch by dxmint.cern.ch
	id AA11333; Mon, 15 May 1995 00:52:35 +0200
Received: by www4.cern.ch (5.0/SMI-4.0)
	id AA00514; Mon, 15 May 1995 00:52:34 --100
Date: Mon, 15 May 1995 00:52:34 --100
Message-Id: <9505142252.AA00514@www4.cern.ch>
To: wmperry@spry.com
Cc: www-style@w3.org
Subject: conversion chart for pixel->pica->inches->millimiters?
In-Reply-To: <m0sAlwa-00000HC@monolith>
References: <m0sAlwa-00000HC@monolith>
From: "H&kon W Lie" <howcome@w3.org>
Content-Length: 770

Bill,

 >   Do you have a handy conversion chart for the various 'spatial'
 > coordinates that we use in the style sheet proposal?

1 in = 25.4 mm = 72 pt = 6 pa 

The naming of these will become an issue -- the less significant the
more discussions..

I enclose some code to do the pt to px conversion (which is the only
one I support so far). The source code of xdpyinfo.c has an
explanations of the issues.

  double display_pt2px;

  #ifdef X11
  display_pt2px =  (25.4 / 72.0) * 
	(((double) DisplayWidth(display,screen)) / ((double) DisplayWidthMM(display, screen)));
  #endif

  int pt2px(double pt)
  {
      return (int) ((display_pt2px * pt) + 0.5);
  }

-h&kon

Hakon W Lie, WWW project CERN, CH-1211 Geneva 23
http://www.w3.org/hypertext/WWW/People/howcome/
eturn-Path: howcome@www4.cern.ch 
Return-Path: <howcome@www4.cern.ch>
Received: from www10.w3.org by www19 (5.0/NSCS-1.0S) 
	id AA04736; Thu, 18 May 1995 09:48:53 +0500
Received: from dxmint.cern.ch by www10.w3.org (5.0/NSCS-1.0S) 
	id AA20006; Thu, 18 May 1995 09:48:44 +0500
Received: from www4.cern.ch by dxmint.cern.ch
	id AA26628; Thu, 18 May 1995 15:48:31 +0200
Received: by www4.cern.ch (5.0/SMI-4.0)
	id AA06441; Thu, 18 May 1995 15:48:25 --100
Date: Thu, 18 May 1995 15:48:25 --100
Message-Id: <9505181348.AA06441@www4.cern.ch>
To: www-style@w3.org
Cc: bert@let.rug.nl
Subject: style!
From: "H&kon W Lie" <howcome@w3.org>
Content-Length: 2311

Even without a formal announcement, the number of subscribers to
www-style keep growing. Welcome! 

If you're new to the field, please check the Style Sheet source page
(http://www.w3.org/hypertext/WWW/Style). I has been updated with some
new references, and is now linked to a style sheet through a 

  <LINK REL=STYLE HREF=style.css>

in the header. You'll need arena or emacs-w3 to see it, though. 

I put a new release of Arena (version 0.97c,
http://www.w3.org/hypertext/WWW/Arena/0.97) out today. It's not
stable, but will do for stylesheet hacking. While coding, a couple
of issues that I didn't resolve intuitively came up. I've described
one of them below. Input is welcome.

-h&kon

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



DOCUMENT-WIDE STYLE SETTINGS

Most style hints will be attached to a single or a small group of HTML
elements, e.g.:

H1, H2: font.family = helvetica

However, one also want to allow the style sheet writer to easily
address _all_ elements. One possibility is to use wildcards for this:

*: font.family = times

Another possibility is to let properties be inherited. E.g., since all
elements in an HTML document are surrounded by <HTML> .. </HTML>, one
could do:

HTML: font.family = times

This solution has some problems. First, not all HTML authors put in
<HTML>..</HTML>. Secondly, HTML is a rather flat language, and many
people don't think in terms of containers and inheritance. Perhaps
they should, but that's a different matter. So, let's stick to the
wildcard solution for now.

In addition, and here the problems start for me, a style sheet sould
be able to specify properties that don't necessarily fall well into
the scheme above, e.g.:

 - the outer margin of a document
 - the width of the browser window 
 - the font size of the HTML source view

One way to solve this problem would be to introduce "dummy elements"
that only exists in the style sheet notation, e.g.:

doc: margin.left = 20pt
window: width = 500px
source: font.size = 14pt

The problem with this solution is <DOC> or <SOURCE> may appear as real
HTML tags one day and the style sheet language will become ambiguous. 

If anyone has a clear vision of how one can get out of this with an
intuitive notation in place, please let me know!


eturn-Path: kevinh@eit.com 
Return-Path: <kevinh@eit.com>
Received: from www10.w3.org by www19 (5.0/NSCS-1.0S) 
	id AB27764; Mon, 22 May 1995 18:09:16 +0500
Received: from eitech.eit.com by www10.w3.org (5.0/NSCS-1.0S) 
	id AA09979; Mon, 22 May 1995 18:09:12 +0500
Received: from pacific.eit.com by eitech.eit.com (4.1/SMI-4.1)
	id AA03453; Mon, 22 May 95 15:09:07 PDT
Date: Mon, 22 May 95 15:09:07 PDT
From: kevinh@eit.com (Kevin Hughes)
Message-Id: <9505222209.AA03453@eitech.eit.com>
To: www-style@w3.org
Subject: CSS Draft Specification: More Notes
Content-Length: 3683


	Hakon, thanks for getting the list going! It was pretty
clear that style-sheet related discussion was not appropriate for
html-wg, and www-html is too general. I hope that good things come
out of here.
	Looking over the draft specification you've put up, here
is some more feedback:

	H1: oversize.font.size += 3

	The main reason for something like "oversize" is to allow
for large capitals. Howeverm I'm sure you can make something more
intuitive to allow authors to change properties of capitals. Maybe
something like:

	H1: font.size.capitals += 3
	H1: font.size.caps += 3

	These lines do the same thing.

	H1: font.size.firstcap += 3

	This only changes the size of the first letter in the element.
I think it would be better not to use the word "dropcap" since it's
too specific.
	Now, when it comes to doing things like this:

        ---- blah ---- blah
        |  | blah |  | blah
        ---- blah ---- blah
        blah blah blah blah

	Where the first element might be a dropcap, and the second may
be an image. I think a good place to start would be a "wrap" property:

	*.dropcap: align = top
	*.dropcap: wrap = on
	*.dropcap: wrap (not specifying a boolean is equivalent to ON).

	In this example, anything with the "dropcap" style is aligned
to the top of the line and the text wraps around the rest of the element.
I realize that wrapping may require a good deal of parsing lookahead,
for instance:

	IMG.wrapped: align = bottom
	IMG.wrapped: wrap = on

        blah blah blah
        blah ---- blah
        blah |  | blah
        blah ---- blah

	The above example might be what such an image might look like.

	P: back.color = "blue"

	I would avoid using "back" as a word for background, since
"back" may be used for something else in the future (as opposed to "next").

	txtlink.color = "red"
	imglink.size = 3px

	I agree that "txtlink" and "imglink", etc. are too specific.
This should instead just be "link", and allow the browser to make the
appropriate decisions depending on the context.

	*: numbering = on|off

	I like this, not because it can allow you to make numbered
lists, but it would be great if it could allow one to make numbered
elements - paragraphs, headers, etc.

	WIDTH: window width
	HEIGHT: window height
	DWIDTH: display width
	DHEIGHT: display height

	I think most authors will only be concerned with the display
width and the display height. Perhaps the display properties should
be renamed to WIDTH and HEIGHT to make them easier to remember, and
the window properties should be renamed to WINWIDTH and WINHEIGHT?
Alternates to WIDTH and HEIGHT could also be PAGEWIDTH and PAGEHEIGHT,
so:

	WINWIDTH: window width
	WINHEIGHT: window height
	WWIDTH: window width
	WHEIGHT: window height

	WIDTH: display width
	HEIGHT: display height
	PWIDTH: display width
	PHEIGHT: display height
	PAGEWIDTH: display width
	PAGEHEIGHT: display height

	"Dummy elements" like:

	doc: margin.left = 20pt
	window: width = 500px
	source: font.size = 14pt

	I think control over the source view format is best left to
the user, not authors.
	Instead of "doc", how about using the word "page" for everything
that refers to the document display area?
	Most people think of the Web as a collection of pages anyway.
And in place of "window", perhaps a good substitute may be "browser",
as window properties refer to the overall size of the browser.
	So you get:

	page: margin.left = 20pt
	browser: width = 500px

	...and it seems closer to the way people think about these
concepts.

	-- Kevin

--
Kevin Hughes * kevinh@eit.com
Enterprise Integration Technologies Webmaster (http://www.eit.com/)
Hypermedia Industrial Designer * Duty now for the future!
eturn-Path: howcome@www4.cern.ch 
Return-Path: <howcome@www4.cern.ch>
Received: from www10.w3.org ([18.23.0.20]) by www19 (5.0/NSCS-1.0S) 
	id AD14623; Mon, 29 May 1995 11:53:16 +0500
Received: from dxmint.cern.ch by www10.w3.org (5.0/NSCS-1.0S) 
	id AA05454; Mon, 29 May 1995 11:53:03 +0500
Received: from www4.cern.ch by dxmint.cern.ch
	id AA13636; Mon, 29 May 1995 17:53:01 +0200
Received: by www4.cern.ch (5.0/SMI-4.0)
	id AA06430; Mon, 29 May 1995 17:53:00 --100
Date: Mon, 29 May 1995 17:53:00 --100
Message-Id: <9505291553.AA06430@www4.cern.ch>
To: www-style@w3.org
Cc: dsr@w3.org, timbl@w3.org, narnett@verity.com
Subject: Welcome!
From: "H&kon W Lie" <howcome@w3.org>
Content-Length: 1532

Welcome to www-style!

More than 100 people have added themselves to the www-style list after
it was announced this weekend. The list should now be operating
properly, and Nick Arnett has volunteered to archive the discussions
at [1]. Thanks!

Style sheets is a way of specifying presentation properties for
documents, e.g. colors and font sizes. Today, most WWW browsers
support style sheets through platform-dependant files. This leaves
full control in the hands of the user, but prohibits the exchange of
style sheets over the web, and the ability for authors to add their
presentation preferences. Many authors want to be able to add style to
their document, and HTML is under constant pressure to add formatting
tags like <COLOR> and <FONT>. Many of us believe style sheets offer a
better solution than constantly extending HTML with new tags or
attributes.

Currently, there are a number of style sheet proposals on the table --
ehh, on the web that is [2]. None of them are
completed/implemented/deployed, and we will need some rounds of
discussions and implementations before we have style sheets on the
web. This list was created to host these discussions and to support
implementations. The floor is open.

[1] http://asearch.mccmedia.com/docs.html
[2] http://www.w3.org/hypertext/WWW/Style/

Disclaimer: On the topic of style sheets, I do not speak for w3.org or
any other organization. This is experimental stuff!

-h&kon

Hakon W Lie, WWW project CERN, CH-1211 Geneva 23
http://www.w3.org/hypertext/WWW/People/howcome/
eturn-Path: narnett@verity.com 
Return-Path: <narnett@verity.com>
Received: from www10.w3.org ([18.23.0.20]) by www19 (5.0/NSCS-1.0S) 
	id AD15177; Mon, 29 May 1995 12:18:51 +0500
Received: from mail.pilot.net (x15.pilot.net) by www10.w3.org (5.0/NSCS-1.0S) 
	id AA05603; Mon, 29 May 1995 12:18:25 +0500
Received: from verity.com (unknown-143-5.verity.com) by mail.pilot.net (4.1 1/7/93 /SMI-4.1)
	id AA10132; Mon, 29 May 95 09:18:24 PDT
Received: from [192.187.143.12] (portanick.verity.com) by verity.com (4.1/SMI-4.1_Verity-Main-950202)
	id AA05153; Mon, 29 May 95 09:16:52 PDT
X-Sender: narnett@hawaii.verity.com
Message-Id: <abefa22a000210046fa0@[192.187.143.12]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Mon, 29 May 1995 09:16:54 -0700
To: "H&kon W Lie" <howcome@w3.org>, www-style@w3.org
From: narnett@verity.com (Nick Arnett)
Subject: Re: Welcome!
Cc: dsr@w3.org, timbl@w3.org
Content-Length: 976

At 10:53 AM 5/29/95, H&kon W Lie wrote:
>Welcome to www-style!
>
>More than 100 people have added themselves to the www-style list after
>it was announced this weekend. The list should now be operating
>properly, and Nick Arnett has volunteered to archive the discussions
>at [1]. Thanks!

At the moment, we're set up to keep about 28 days' of messages in the menus
and searchable archive.  I can extend that easily, but we're also working
on a more permanent archive.  The URL you listed:

http://asearch.mccmedia.com/docs.html

is a menu item with links to several document and markup-related lists.  To
go directly to the default menu for www-style (messages sorted by date),
it'll be:

http://asearch.mccmedia.com/www-style/

Of course, the message will also be searchable.

Nick

P.S.  The archive system is also reachable as vlibmail.verity.com; same
machine, same documents.  mccmedia.com is my company; I brought the
prototype of this software from there to Verity.


eturn-Path: howcome@www4.cern.ch 
Return-Path: <howcome@www4.cern.ch>
Received: from www10.w3.org ([18.23.0.20]) by www19 (5.0/NSCS-1.0S) 
	id AB15546; Mon, 29 May 1995 12:33:40 +0500
Received: from dxmint.cern.ch by www10.w3.org (5.0/NSCS-1.0S) 
	id AA05694; Mon, 29 May 1995 12:33:31 +0500
Received: from www4.cern.ch by dxmint.cern.ch
	id AA18734; Mon, 29 May 1995 18:33:28 +0200
Received: by www4.cern.ch (5.0/SMI-4.0)
	id AA06478; Mon, 29 May 1995 18:33:28 --100
Date: Mon, 29 May 1995 18:33:28 --100
Message-Id: <9505291633.AA06478@www4.cern.ch>
To: www-style@w3.org
Subject: Arena 0.97e
From: "H&kon W Lie" <howcome@w3.org>
Content-Length: 742

Version 0.97e of Arena, W3O's testbed browser, was released today. It
extends its experimental style sheet notation to allow authors and
readers to specify preferred styles:

<STYLE>

h1        : font.color = DarkGreen; font.size = 22pt
h2        : font.color = DarkRed; font.size = 16pt
p         : margin.left = 40pt

# make paragraphs that follow h1 bold:

/h1 p/    : font.style = bold

# specify style for different levels of nested lists:

(ul(li    : font.color = DarkRed
(ul(ul(li : font.color = DarkGreen

</STYLE>

Arena 0.97e is offered in binary form for several unix platforms. See
http://www.w3.org/pub/arena/experimental

-h&kon

Hakon W Lie, WWW project CERN, CH-1211 Geneva 23
http://www.w3.org/hypertext/WWW/People/howcome/
eturn-Path: howcome@www4.cern.ch 
Return-Path: <howcome@www4.cern.ch>
Received: from www10.w3.org by www19 (5.0/NSCS-1.0S) 
	id AB11250; Tue, 30 May 1995 05:45:36 +0500
Received: from dxmint.cern.ch by www10.w3.org (5.0/NSCS-1.0S) 
	id AA10369; Tue, 30 May 1995 05:45:29 +0500
Received: from www4.cern.ch by dxmint.cern.ch
	id AA08031; Tue, 30 May 1995 11:45:16 +0200
Received: by www4.cern.ch (5.0/SMI-4.0)
	id AA07272; Tue, 30 May 1995 11:45:14 --100
Date: Tue, 30 May 1995 11:45:14 --100
Message-Id: <9505300945.AA07272@www4.cern.ch>
To: dba@althingi.is
Cc: www-html@www10.w3.org, www-style@w3.org
Subject: Re: page control in HTML
In-Reply-To: <9505291924.AA05183@freki.althingi.is>
References: <9505291924.AA05183@freki.althingi.is>
From: "H&kon W Lie" <howcome@w3.org>
Content-Length: 1331

dba@althingi.is writes:

 > Thanks to Andrew for his comments
 > he wrote
 > >>>>>>>>>
 > I think the simplest problem with this approach is that it clutters up
 > HTML with features that are relevant only to one specific style of output.
 > If tags or attributes are added specifically for printing, then what about
 > screen display?
 > <<<<<<<<<<
 > it seems to me that HTML only has features that are relevant to
 > screen display and I would like to have some very primitive control
 > over the page layout so I want need to keep duplicates or what ever

Ideally, HTML should be independant of output (and input!)  media. You
can only render <BLINK> on a visual, dynamic display, and that is why
it upsets a lot of people.

Style sheets offer a better way to handle these issues than adding
HTML tags. Unfortunately, HTML style sheets are still immature, and
the implementations we've seen so far are screen oriented. However,
multiple output media have been discussed in some of the proposals
that are out [1].

Recently, a style sheet mailing list -- www-style@w3.org -- has been
started. You can add yourself from [2].

[1] http://www.w3.org/hypertext/WWW/Style/
[2] http://www.w3.org/hypertext/WWW/Mailing/Form.html

-h&kon

Hakon W Lie, WWW project CERN, CH-1211 Geneva 23
http://www.w3.org/hypertext/WWW/People/howcome/
eturn-Path: bert%let.rug.nl@www10.w3.org 
Return-Path: <bert%let.rug.nl@www10.w3.org>
Received: from LCS.MIT.EDU (mintaka.lcs.mit.edu) by www19 (5.0/NSCS-1.0S) 
	id AA00641; Tue, 30 May 1995 16:36:06 +0500
Received: from www10.w3.org by MINTAKA.LCS.MIT.EDU id aa08170;
          30 May 95 15:20 EDT
Received: from freya.let.rug.nl by www10.w3.org (5.0/NSCS-1.0S) 
	id AA13981; Tue, 30 May 1995 15:15:43 +0500
Received: from grid.let.rug.nl by freya.let.rug.nl with ESMTP
	(1.37.109.15/16.2) id AA262011341; Tue, 30 May 1995 21:15:41 +0200
Message-Id: <199505301915.AA262011341@freya.let.rug.nl>
Received: by grid.let.rug.nl
	(1.37.109.16/16.2) id AA237661340; Tue, 30 May 1995 21:15:40 +0200
From: Bert Bos <bert@let.rug.nl>
Subject: The style agenda
To: www-style@w3.org
Date: Tue, 30 May 1995 21:15:40 +0200 (METDST)
X-Mailer: ELM [version 2.4 PL24]
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Length: 3637      
Content-Transfer-Encoding: quoted-printable

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
                 <bert@let.rug.nl>           Rijksuniversiteit Groningen
    <http://www.let.rug.nl/~bert/>     Postbus 716, NL-9700 AS GRONINGEN
eturn-Path: terry@ora.com 
Return-Path: <terry@ora.com>
Received: from www10.w3.org by www19 (5.0/NSCS-1.0S) 
	id AB06107; Tue, 30 May 1995 19:44:24 +0500
Received: from dmg.west.ora.com by www10.w3.org (5.0/NSCS-1.0S) 
	id AA15786; Tue, 30 May 1995 19:44:20 +0500
Received: (from terry@localhost) by dmg.west.ora.com (8.6.11/8.6.11) id QAA05934; Tue, 30 May 1995 16:41:33 -0700
Date: Tue, 30 May 1995 16:41:33 -0700
From: Terry Allen <terry@ora.com>
Message-Id: <9505301641.ZM5932@dmg.west.ora.com>
In-Reply-To: Bert Bos <bert@let.rug.nl>
        "The style agenda" (May 30,  6:26pm)
References: <199505301915.AA262011341@freya.let.rug.nl>
X-Mailer: Z-Mail (3.2.1 15feb95)
To: bert@let.rug.nl, Multiple recipients of list <www-style@www10.w3.org>
Subject: Re: The style agenda
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Length: 7437

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 www-style@w3.org."
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  (terry@ora.com)   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
eturn-Path: bert@let.rug.nl 
Return-Path: <bert@let.rug.nl>
Received: from www10.w3.org by www19 (5.0/NSCS-1.0S) 
	id AB03122; Wed, 31 May 1995 08:02:37 +0500
Received: from freya.let.rug.nl by www10.w3.org (5.0/NSCS-1.0S) 
	id AA19547; Wed, 31 May 1995 08:02:31 +0500
Received: from grid.let.rug.nl by freya.let.rug.nl with ESMTP
	(1.37.109.15/16.2) id AA276801748; Wed, 31 May 1995 14:02:29 +0200
Message-Id: <199505311202.AA276801748@freya.let.rug.nl>
Received: by grid.let.rug.nl
	(1.37.109.16/16.2) id AA146961747; Wed, 31 May 1995 14:02:27 +0200
From: Bert Bos <bert@let.rug.nl>
Subject: Re: The style agenda
To: terry@ora.com
Date: Wed, 31 May 1995 14:02:27 +0200 (METDST)
Cc: www-style@www10.w3.org
In-Reply-To: <9505301641.ZM5932@dmg.west.ora.com> from "Terry Allen" at May 30, 95 07:45:29 pm
X-Mailer: ELM [version 2.4 PL24]
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Content-Length: 12136     

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 www-style@w3.org."
 |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

-- 
                          Bert Bos                      Alfa-informatica
                 <bert@let.rug.nl>           Rijksuniversiteit Groningen
    <http://www.let.rug.nl/~bert/>     Postbus 716, NL-9700 AS GRONINGEN
eturn-Path: howcome@www4.cern.ch 
Return-Path: <howcome@www4.cern.ch>
Received: from www10.w3.org by www19 (5.0/NSCS-1.0S) 
	id AA05854; Wed, 31 May 1995 09:21:03 +0500
Received: from dxmint.cern.ch by www10.w3.org (5.0/NSCS-1.0S) 
	id AA22730; Wed, 31 May 1995 09:20:46 +0500
Received: from www4.cern.ch by dxmint.cern.ch
	id AA22093; Wed, 31 May 1995 15:20:42 +0200
Received: by www4.cern.ch (5.0/SMI-4.0)
	id AA08856; Wed, 31 May 1995 15:20:40 --100
Date: Wed, 31 May 1995 15:20:40 --100
Message-Id: <9505311320.AA08856@www4.cern.ch>
To: terry@ora.com
Cc: www-style@w3.org
Subject: Re: The style agenda
In-Reply-To: <9505301641.ZM5932@dmg.west.ora.com>
References: <9505301641.ZM5932@dmg.west.ora.com>
From: "H&kon W Lie" <howcome@w3.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Length: 7148

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 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.

 > 	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."

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!

 > 	http://www.w3.org/hypertext/WWW/Style/Welcome.html
 > 
 > says bluntly, "Discussions take place in www-style@w3.org."

Blunt it was. Rephrased.

 > 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!

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.

 > |      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..

 > |      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!

Perhaps there are ways to cleanly avoid conflicts?

 > |      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).

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.

 > |      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.

 > |      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?  

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.

 > 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

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/
eturn-Path: terry@ora.com 
Return-Path: <terry@ora.com>
Received: from www10.w3.org by www19 (5.0/NSCS-1.0S) 
	id AC01377; Wed, 31 May 1995 10:53:01 +0500
Received: from dmg.west.ora.com by www10.w3.org (5.0/NSCS-1.0S) 
	id AA26494; Wed, 31 May 1995 10:52:52 +0500
Received: (from terry@localhost) by dmg.west.ora.com (8.6.11/8.6.11) id HAA08282; Wed, 31 May 1995 07:50:10 -0700
Date: Wed, 31 May 1995 07:50:10 -0700
From: Terry Allen <terry@ora.com>
Message-Id: <9505310750.ZM8280@dmg.west.ora.com>
In-Reply-To: "H&kon W Lie" <howcome@w3.org>
        "Re: The style agenda" (May 31,  3:20pm)
References: <9505301641.ZM5932@dmg.west.ora.com> 
	<9505311320.AA08856@www4.cern.ch>
X-Mailer: Z-Mail (3.2.1 15feb95)
To: "H&kon W Lie" <howcome@w3.org>, terry@ora.com
Subject: Re: The style agenda
Cc: www-style@w3.org
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Length: 6426

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 ...


-- 
Terry Allen  (terry@ora.com)   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
Received on Tuesday, 9 May 1995 16:50:00 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 27 April 2009 13:53:42 GMT