Re: The style agenda

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

Received on Monday, 23 January 2023 01:05:30 UTC