Re: CSS draft 4.0

Hakon Lie <howcome@w3.org> writes:
>> A new major revison of the Cascading Style Sheet's draft specification
>> is available from http://www.w3.org/pub/WWW/Style/css/draft.html
>
>...
>
>> As always, comments are welcome.

evan@poirot.hpl.hp.com (Evan Kirshenbaum) writes:
>Here are mine, in no apparent order. [...]

And here are some second-level comments, followed by a few first-level
comments of my own.

>  o I think that it is going to be necessary to add at least
>    rudimentary  numbering style for lists to level one. [...]
>
>       number-form = uppercase alpha | lowercase alpha |
>                     uppercase roman | lowercase roman |
>                     decimal |
>                     url : <url> |
>                     char : <char>
> [...]

Hmm.  Are you suggesting using a style parameter named `number-form' for
both ordered and unordered lists?  That seems counterintuitive.  I'd
suggest either using a more neutral name like `list-annotation' or
splitting it into `number-form' and `bullet-form'.

I'd also suggest instead of (or perhaps in addition to) `char : <char>'
the option `dingbat : <dingbat>', where <dingbat> picks up the iconic
entities from <UL DINGBAT=...>.  Perhaps also `none' for unbulleted
lists, and `normal' or `default' for whatever the rendering agent would
have put there anyway.

>    or perhaps better
>
>       number-pattern = <pattern>
>       number-url = <url>
>
>    where <pattern> is a string substituting "%A", "%a", "%I", "%i",
>    "%1", "%u" for the above.  This would allow specifying things like
>    "(%1)" or "%a.".  It would also allow the i18n extension to
>    "%&#1488;" to number in Hebrew, etc. once 10646 is accepted as the
>    document character set.

I like.

>  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'.

>  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.

>    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"?

>  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 {...}'.

>  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'.

>  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.

This might even answer a point of my own; see below.

>  o The introduction of the Q tag in the i18n draft will probably make
>    it desirable to be able to specify
>
>       Q { prefix = "&#171;" -- left guilmet --,
>           suffix = "&#187;" -- right guilmet -- }

Those would be `insert-before' and `insert-after' from level 2, I
believe.


And now a few of my own comments:

  - 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.

  - 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.

  - 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.

  - 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.

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

						-sbigham

Received on Thursday, 12 October 1995 11:31:11 UTC