Some comments on Style sheet syntax.

I have been encouraged to post to this list by Håkon Lie. I doubt
that I can spare time to join your discussions.

However, the text below was written in response to reading your current
draft style sheet specs which I think are overcomplicated, hard to
explain and hard to grasp by naïve users. My background is Computer
Science and in my 25 years of computing life I have done tons of little
languages like the one you are describing. This sounds crass - but I
guess this is a fresh eye looking at what you are doing.

--------------------------------------------------------
I realise that I am coming into this somewhat late - and you may
have been through these issues.

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.

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 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. This would allow for the visually impaired to load
a local spec file in the browser - using the same style syntax
and also the same style reading code.

I think that you should only be able to define each class exactly once.
Any later definitions will revert the class back to the default
and reload new specifications. The other alternative is to make a
new definition ADD to a class - but I think in the long run this
will be confusing.

A CLASS Spec should be able to contain other classes:

first_red { class = first
            font.color = red
	  }

This is a MUCH more general and simple syntax - and side steps all the
special case issues of whether links should have different properties
etc etc. It DOES mean that link colours (selected, unselected) will need
to become properties. I can now write a single class spec that applies
to the whole document - independent of any HTML constructs in that
document.

Perhaps in a further simplification, one should remove the dot syntax and
build font specs up from simpler elements:

big_font { font = times
	   style = bold
	   size = 60pt
	   colour = green
	   selected = red
	 }

Then use it as

first_big { class = first
	  font = big_font
	  }

The contents of the braces should be
	property = value <NEWLINE>
where value can be a constant, a class or an expression. Expressions should
always be enclosed in round brackets - again for parsing speed reasons.

I believe that this is will be MUCH easier to implement and comprehend
by non-programmers. The parsing engine should be not too many lines.
What you are doing for the implementation is building a list of
attributes. It will be independent of existing HTML and will remove the
need for typing of HTML objects.

Just a thought or so - intended to be constructive though :-)

Peter Collinson

Received on Tuesday, 25 July 1995 14:19:11 UTC