Some comments on Style sheet syntax.

Peter Collinson writes:

 > I have been encouraged to post to this list by Hekon Lie. I doubt
 > that I can spare time to join your discussions.

Thanks for posting. My comments follow:

 > I think that the current syntax is far too weak and will be easy to get
 > wrong. It's also fussy and not easy to use. I dislike the colon syntax -
 > it's going to be hard to implement because you have to keep a definition
 > 'open' because you can add to it at any time. It's going to be
 > impossible for the writer to KNOW what is on force at any one point in
 > the document anyway.

One of the fundamental features of the Cascading Style Sheet proposal
is that several style sheets may influence the presentation. So, the
writer (I assume you refer to the style sheet writer) will never "KNOW
what is on force", but is given a reasonable chance to influence it.

The little language we're descibing is not a programming language. I
like to think of the style sheet mechanism as a constraint solver: one
throws weighted wishes into it, it resolves any conflicts and outputs
a value for the browser to use. So, to a certain extent it's
fussy, yes. But:

  "Traditionally, ambiguity in parsing is something to be
  avoided. However, to support a creative process, this may not be the
  case. Ambiguity should be viewed as beneficial and something that
  needs to be maintained until later design decisions have been able to
  disambiguate the designer's intention."

  (From Kent Wittenburg and Louis Weitzman's paper: Automatic
   Presentation of Multimedia Documents Using Relational Grammars
   ftp://flash.bellcore.com/pub/rl/docs/rg-for-ap5.ps.Z)

 > So the notion of
 > 
 > 	HTML_ELEMENT : SPECIFICATION
 > 
 > would be better rendered as
 > 
 > 	CLASS_NAME { SPECIFICATION }
 > 
 > where SPECIFICATION may be a multi line set of elememts. This makes
 > a complex element like the EM.first much more intuitive (and easier
 > to parse too). The use of braces is important psychologically for
 > the writer - and will also aid in parsing the specification.
 > 
 > first {    font.style = dropped big-initial small-caps
 > 	   font.size = 12pt
 > 	   undersize.font.size = 12pt
 >    	   oversize.font.size = 24pt   // assuming leading is zero
 > 	}
 > 
 > Now I can use the 'first' class anywhere - and that's the next key
 > point---
 > 
 > The style sheet should ONLY defines CLASSES - how they are applied
 > should be left to the document.  If the attributes are not relevant then
 > they can be ignored.

If I understand you correctly, you propose to take out the addressing
part of the style sheet language and use the CLASS attribute in the
HTML document to select a group of style properties. This could work,
yes, but you don't simplify the mechanism -- you just move markup into
the HTML. One of the goals of the CSS proposal is to minimalize
interference with HTML, and to be able to apply a style sheet to an
existing document without changing it. You open up for a similar
functionality by addressing a default class:

 > If I set a CLASS then that class should remain in force until
 > explicitly reset - you need to adopt some syntax like
 > <P CLASS=default>
 > to reset things back to the currently prevailing defaults. Maybe
 > default should be an addressible class anyway so that that can be
 > altered.

However, if there is only one default class, all elements will look
the same (unless, of course, you subclass them). No? I you, on the
other hand, have several default classes, on what basis will you pick
one?

Instead of making subclassing mandatory, the CSS proposal takes
advantage of the existing "subclasses" (H1, P etc) and overlays styles
based on these. For me, that's intuitive, and Peter's extra level of
indirection is not. What do other people think? (I fear my intuition
is somwhat damaged after thinking about these issues for some time :-)

 > Peter Collinson

-h&kon

Hakon W Lie, W3C/INRIA, Sophia-Antipolis, France
http://www.w3.org/hypertext/WWW/People/howcome/

Received on Wednesday, 26 July 1995 06:02:14 UTC