Re: CSS draft 4.0

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

Here are mine, in no apparent order.  First, overall, it's coming
along nicely.

But on to the nits and suggestions :-) :

  o I think that it is going to be necessary to add at least
    rudimentary  numbering style for lists to level one.  People keep
    asking "how do I get unbulleted lists", "how do I substitute my
    own URL for the bullet", etc.  With HTML 3 now pretty much
    officially dead, it is unclear when the extra attributes on UL,
    LI, etc. will be added, and they clearly belong in a style sheet
    anyway.  Perhaps something like

       number-form = uppercase alpha | lowercase alpha |
                     uppercase roman | lowercase roman |
                     decimal |
                     url : <url> |
                     char : <char>

    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.

  o I think that it will be important to allow specification by a
    particular id even in level one.  Perhaps something like
    "TAG(id)".  (This is unambiguous even with the current scheme,
    because context sensitive definitions cannot have an
    unparenthesized tag before a parenthesized one.)

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

  o I'm a little unclear as to why "*" is a synonym for "HTML".  I
    realize that it was in the past, but we're already breaking all
    old parsers by adding the braces.  On second thought, I suppose
    that it will be useful to be able to specify "*.CLASS".  Is this
    the reason for retaining it?

  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

  o On the subject of colors, since lists tend not to be delimited,
    there is a potential problem with the "3 number" rgb form.
    Perhaps this should become "(255 0 0)" so that it could be seen as
    one element.

  o On the subject of preference lists, perhaps it would be a good
    idea to add a delimiter, as

      text-color = pantone(542) | firebrick | #fe0705 | dark-red | red
      font-family = new-century-schoolbook | serif

  o I'm not sure I see why definitions need to be punted to level 2,
    and I see a considerable maintenance simplification by allowing
    them.   It would seem to be relatively straightforward to say
    something like

       define color important =
           pantone(542) | firebrick | #fe0705 | dark-red | red;

    and then say

       text-color = $important

    in several places.  This would allow a single change if the
    desired color changes.

    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.

  o There is syntax for "A.link" and there is syntax for "A.CLASS".
    Is it possible to say "A.CLASS.link"?  Perhaps rather than
    "A.link", what we want is a pseudo *tag* "A-unvisited" and
    "A-visited".  The semantics would be that the "A-(un)visited"
    attributes override the "A" attributes.

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

  o "font" is specified to include a "font-size".  It would be useful
    if this could be allowed to be a font-size-index (since the two
    sets are disjoint, or would be if the index numbers were preceded
    by a character such as "#").  This would allow you to talk about

         font = large helvetica bold

  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.

  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.

  o Since "text-line" became "text-decoration", the values "under",
    "over", and "through" are unintuitive.  Perhaps they should be
    renamed "line-over"/"overbar", "line-under"/"underbar" and
    "line-through".

  o Also, text-decoration should probably allow more than one to be
    specified, as it is reasonable to have boxed, struck-out text, for
    example.

  o For text-transform, "capitalize" should probably be "capitalized"
    for symmetry with "uppercase" and "lowercase".  Unless there are
    other transformations you have in mind, this should probably be
    changed to text-case taking "initial-caps | upper | lower | none".
    Also, should there be a note here reminding implementers that such
    transformations should be relative to the current value of the
    LANG attribute.  (Capitalization only makes sense with respect to
    a particular language.)

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

  o On the subject of prefixes, the fact that it looks as though
    Netscape is likely to be about to unleash the ability to post HTML
    usenet messages on the masses, it will probably be necessary to be
    able to specify something like

       BLOCKQUOTE { line-prefix = "&gt; " }

  o The set of generic font families almost certainly needs "fixed".

  o In the "Level 1 ambitions" section, you talk about recommending a
    "C" tag.  The i18n draft introduces a tag for this purpose, called
    "SPAN".  It's primary use is to hold LANG and DIR attributes, but
    it is expected to hold CLASS attributes when they are added.

So, did anybody make it this far?









----
Evan Kirshenbaum                       +------------------------------------
    HP Laboratories                    |Voting in the House of
    1500 Page Mill Road, Building 4A   |Representatives is done by means of a
    Palo Alto, CA  94304               |little plastic card with a magnetic
                                       |strip on the back--like a VISA card,
    kirshenbaum@hpl.hp.com             |but with no, that is, absolutely
    (415)857-7572                      |*no*, spending limit.
                                       |                  P.J. O'Rourke

Received on Wednesday, 11 October 1995 19:55:54 UTC