Re: The style agenda

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

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