Re: A framework for style sheet experiments/subsets?

Andre Lunde writes:

 |http://www.w3.org/hypertext/WWW/Style/css/draft.html
 |
 |I guess this seems as reasonable as any other place to start.
 |
 |I'd suggest that before encouraging experimentation, a couple
 |of things should be addressed.
 |
 |If there are going to be multiple style-sheet languages or dialects
 |(as many suggest, though I have my doubts) we should try to make
 |clear how the correct style sheets and "dialect" can be determined
 |with HTML and HTTP. I'd like a consistent mechanism defined for this
 |early on if everything else is going to be babble.

In HTML, <link rel=style href="url"> has been suggested most
often (though personally I think a style sheet is not a hyperlink and
should be referenced via SRC= instead of HREF=).

In HTTP, nothing needs to change. Content negotiation may not be
implemented properly everywhere, but it is sufficiently well defined.

Something has to be added to MIME, either text/css-style-sheet,
style/css, application/css-style-sheet, sgml/css-style, or
whatever. But while we're debating that, we can temporarily use
text/x-css.

 |If we write up a subset of a style sheet language, we should try
 |to define a precise syntax/grammer (with BNF or whatever) for
 |parsing the language, and if possible make this general enough
 |to deal with the whole language. (Some other proposals may
 |address this, but I didn't see anything in the CSS document
 |about grammer.)

There will be.

 |We ought to address (as in HTML or more so) the question of dealing with
 |unknown extensions (and distingushing them from errors).

The easiest is the `ignore what you don't understand' approach. The
grammar is set up so even unknown properties can be parsed properly
and many formatters will have to ignore some properties anyway (page
breaks, running headers, voice output, colors, inline images).

 |It would also be good to consider language features that
 |make it easier to recover from/localize parsing errors.
 |
 |Either requiring a statement terminator like a semi-colon
 |or adopting a one-statement-per-line syntax with an explicit
 |continuation indicator would help in this context.

Despite what Peter Collinson set earlier about using a syntax with
braces {}, I think that non-programmers find it easier to deal with
one-statement-per-line and don't mind repeating the element or class
name a few times. I'm a programmer myself, so it is difficult for me
to judge, but at least error recovery becomes very easy: just skip to
the end of line and very little harm will be done.

The continuation character will be a backslash, I guess, but it
shouldn't be needed often.

 |And even though we may not want to encourage fancy stuff
 |in a simple subset, something may need to be said about
 |the processing model of the language to make conditional
 |or context-dependent features work consistently. I.e.
 |is this a purely declaritive language, a procedural language
 |or what?

Purely declarative would be my choice, after all, we want to encourage
non-programmers to become style designers. And we want hand-written
style sheets to be imported into interactive style editors and vice
versa.

I even want to keep the if-then out of the right hand side, but I'm
not sure if that can be maintained in future versions. (Btw., if it
were to be added, what would be the preferred syntax:
if-then-else-endif, @if(a,b,c), a?b:c,...)

 |(Pardon me if I'm going over old ground here: I just want
 |to stress that a well-defined framework is important when
 |we start talking about many implementations.)

Not old ground, these things haven't been discussed in any detail on
the list, but it just happens that Hakon and I have been discussing
them in private over the past fortnight or so, so that the next
version of the CSS document can contain proposals in that direction as
well.


Bert
-- 
                          Bert Bos                      Alfa-informatica
                 <bert@let.rug.nl>           Rijksuniversiteit Groningen
    <http://www.let.rug.nl/~bert/>     Postbus 716, NL-9700 AS GRONINGEN

Received on Friday, 28 July 1995 05:47:06 UTC