- From: Bert Bos <bert@let.rug.nl>
- Date: Fri, 28 Jul 1995 11:47:00 +0200 (METDST)
- To:
- Cc: www-style@www10.w3.org, www-html@www10.w3.org
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