Re: CSS draft 4.0

Thanks to Evan Kirshenbaum, Gerald Oskoboiny and Scott Bigham for
digging into the latest CSS draft.

Scott ( > > ) and Evan ( > ) write:

 > >  o The element declaration "(X)Y,Z" would appear to be ambiguous.
 > >    I'd suggest that it might be worth changing the notation to use
 > >    "::" for scoping a la C++ and Perl.  This would allow you to
 > >    disambiguate between "X::Y,Z" and "X::(Y,Z)".
 > 
 > Or perhaps two grouping connectors:  ',', which binds tighter than
 > patterns, and ';', which binds looser.  Thus `(X) Y,Z' would be
 > equivalent to `(X) Y; (X) Z'.

The ambiguity should be removed, but is the increased complexty in
notation worth it? I would suggest interpreting (X)Y,Z { A = B } as

  (X) Y { A = B }
  Z { A = B }

 > >  o I'm a little unclear as to why "*" is a synonym for "HTML". [...]
 > 
 > Indeed.  In fact, I was under the impression that "*" was originally
 > intended to be a wildcard representing _all_ classes.

"*" is not a synonym for "HTML", it's a synonym for the top-level
element. In HTML, this happens to be "HTML", but many authors omit it
and I believe "*" is more intuitive. And shorter. Due to inheritance,
it will often behave like a wildcard, but technically it isn't. E.g.:

  * { background = "texture.gif" }

will set the backround image of the top-level element and leave the
other elements' backgrounds transparent (unless otherwise specified).
I believe this is what the user will expect.

However,

  *.CLASS { .. }

will probably no give the user the expected result. Instead, only the
CLASS should be used as a selector:

  CLASS { .. }

 > >    I would suggest allowing "define color", "define size", and
 > >    "define font" in level one, and perhaps "define effect", which
 > >    takes a brace-delimited set of attributes which are all applied
 > >    unless explicitly overridden.
 > 
 > Hmm.  How exactly would "define color fred = red" differ from
 > "define fred = red"?

It was put into level 2 to simplify initial implementations. I'd
rather use the grouping syntax to save typing.

 > >  o There is syntax for "A.link" and there is syntax for "A.CLASS".
 > >    Is it possible to say "A.CLASS.link"?. [...]
 > 
 > Similarly, what of <P CLASS=STANZA.COUPLET>, which appears as an example
 > in <URL:http://www.w3.org/hypertext/WWW/MarkUp/html3/docbody.html>?  The
 > syntax doesn't seem to allow `P.STANZA.COUPLET {...}'.

The proposed syntax only allows addressing based on one class. Until
we know more about the use of CLASS, I'm a bit reluctant to complicate
the syntax.

 > >  o In order to be able to correctly customize BIG, SMALL, SUPER, and
 > >    SUB, font-size-index needs to be able to be specified to be a
 > >    relative value such as "+2", "-1" or (my preference) "up two" and
 > >    "down one".
 > 
 > In previous versions of this draft, this was expressed as
 > `font-size-index = font-size-index + 2' or `font-size-index -= 1'.

Yes, this was moved to level 2. 

 > >  o I notice that for text-color, there is no way to override the
 > >    context's choice to go back to the user default.  Perhaps "none"
 > >    should be allowed.

You mean, go back to what it was at a previous point in the
hierarchy? If so, how far back should you go? 

 >   - When was the cascade order changed so that `author important'
 >     overrides `reader important'?  This is IMHO horribly wrong; the
 >     reader should always have ultimate say in matters of rendering.

This is an issue of much debate. Before, the author was not allowed to
specify "!important". That was changed to make the syntax fully
symmetrical. Note, however, that the specification describes how style
sheets can be turned on and off in e.g. a pulldown menu. So if the
incoming style sheet abuses its powers, one could turn it off (and
acknowledge the warnings that come through the !legal construct). Does
this make you happier?

 >   - On a similar note, and though this may just be an implementation
 >     issue, Arena's method of using the initial page's style sheet as the
 >     default style causes problems with the "!important" reader/author
 >     symmetry.  That is, if I put `body {background = white !important}'
 >     in my home page's style sheet to override backgrounds from incoming
 >     style sheets, then anyone viewing my home page will receive that
 >     setting as `author important', which is not what I want.

So, your startup page and home page are the same? If so you'll have a
problem, yes. A simple command-line argument in Arena should allow you
to change this behavior in the future.

 >   - Something I've often though would be useful would be a way to say in
 >     a style sheet, "don't accept settings of (this style parameter/any
 >     style parameters) for this element from incoming style sheets".  For
 >     instance, I use the setting `A {text-background = light-grey}',
 >     which I think looks nice against Arena's sandy-yellow background.
 >     On the other hand, most people seem to use something like
 >     `A {text-color = blue}', which mixes with my own setting and looks
 >     pretty strange.  I'd like to be able to say something like
 >     `A {text-color = default !important}' so that the browser would
 >     ignore A:text-color settings in incoming style sheets.

In a sense, add weight to the existing value. Interesting.

 >   - Are `color' and `background' now aliases for `text-color' resp.
 >     `text-background', or is this just a typo?  I like this; using
 >     `text-background' to set the background of, say, a table always
 >     struck me as a little wrong.

I meant to change "text-color" into "color" throughout the document
exactly for this reason. It only happened in the list of properties,
thought, but will be updated in the next release. Similarly,
"background" is the preferred way of referring to the background. Do
we need aliases?

 >   - Thanks for the yacc grammar; that will be a great help.

Courtesy of Bert Bos.

 >   o I like the notion of allowing there to be a preset list of colors.
 >     I'd encourage the draft to abstract colors in the same way that it
 >     does font families.  That is, attributes like "text-color" should
 >     take a list of colors.  This would allow specification of a set of
 >     fallbacks:
 > 
 >       text-color = pantone(542) firebrick #fe0705 dark-red red

The comparison with font-family is a good one, and a list of color
values would have the same basic problem: how do you determine success
or failure? For font-family, this problem is left to the UA, and the
same could be done for text-color, yes.

 [on the issue of font-size vs. font-size-index]

 >   o Come to think of it, since the sets are nearly disjoint, I don't
 >     see any real reason not to dispense with font-size-index
 >     altogether and just define font-size to take
 > 
 >          <length> | #<number>| up <number> | down <number> |
 >          xx-small | x-small | small | medium | large | x-large |
 >          xx-large
 > 
 >     This would get rid of the ambiguity that arises when both are
 >     specified.

Good point. There doesn't seem to be much left of the argument for
having them separate.

 > So, did anybody make it this far?

Yes. Thanks for digging this deep into the spec.

Regards,

-h&kon

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

Received on Monday, 16 October 1995 19:23:59 UTC