W3C home > Mailing lists > Public > www-style@w3.org > December 1995

Re: CSS1, new draft specification

From: Evan Kirshenbaum <evan@poirot.hpl.hp.com>
Date: Wed, 27 Dec 1995 11:38:55 -0800
Message-Id: <9512271138.ZM10243@poirot.hpl.hp.com>
To: Hakon Lie <Hakon.Lie@sophia.inria.fr>, www-style@w3.org
> A new version of the Cascading Style Sheets specification has been
> released. There have been a number of changes based on comments from
> implementors and participants on this list. Thanks! Some of the
> changes are:

> As always, comments are welcome.

By now, you're probably hoping I won't. :-)

Anyway, it's looking good.  Here's what I noted:

  - For lists, you say that "the label should use the font and color
    properties of the list element to which it belongs."  Wouldn't it
    make more sense to specify a "label" pseudo-class for this.  This
    would allow you to say:

       OL LI:label { font-weight: bold }

  - For font-weight and font-size, I appreciate that you've moved from
    absolute numbers to relative ones.  I'm a little concerned,
    though, that it may not be intuitive that a bare positive number
    means an increase.  I would suggest either requiring "1
    larger/smaller" ("1 bolder/lighter") or requiring that positive
    increments be prefixed by a plus sign ("font-weight: +2").

  - For font-style, would it be worth adding as a value something like
    "contrasting"?  By this I mean the "italics if you're in roman;
    roman if you're in italics" that LaTeX uses for "\em".  This is
    probably how I'd want to define <EM>.

  - For color, I'd still like to be able to specify a list of options
    (or hear an argument why this isn't a good idea).  Especially if
    you're allowing the possibility of multiple color models I can see
    people wanting to say

        .company { color: pantone(4231) indian-red dark-red black }

  - for background, what are the intended semantics if multile URIs
    are specified?  I presume that the first acceptable one found is
    used, but the spec should say.

  - for bg-position, you explain what "0% 0%" and "100% 100%" mean,
    but I still don't know what, e.g., "14% 84%" means.  My best guess
    is that the point 14% across and 84% down the image is to be
    placed at the point 14% across and 84% down the element.  If this
    is so, the spec should be clearer.  If it is not, then the spec
    should *certainly* be clearer.

  - for text-transform, could we note that the actual transformation
    in each case is language (and UA) dependent.  For example, whether
    "" uppercases to "" or "E" depends on the language (or even the
    particular dialect: "fr-CA" vs. "fr-FR").  Also a browser will
    probably want to have more complex rules for what "capitalize"
    means.  (e.g., in "en-US", I probably would have a list of words
    ("the", "a", "of", etc.) which would not be capitalized except at
    the beginning of the element, or following a colon or open quote.)

  - for text-align, we should note that the actual justification
    algorithm used is UA (and language) dependent.  A UA may justify
    by increasing word spacing, by letterspacing (reasonable in some
    languages), by stretching characters (common for Hebrew), and may
    even hyphenate.

  - is text-indent necessary anymore?  Can't we just say

         X:first-line { margin-left: 3em }

  - for padding, you say "the color of the padding area is controlled
    with the 'background' property".  Wouldn't it be reasonable to add
    a "padding" pseudo-class.

  - for margin, what does "auto" mean?

  - the width property takes a percentage, but the height property
    does not.  Is there a reason for this?

  - for the specification of colors, we now allow "rgb 1.0 0.0 0.0"
    with the note that "to have room for other color models in the
    future, the 'rgb' keyword is required in the latter notation."
    This implies that other color models may be added prefixed by a
    similar keyword.  Unfortunately, there is no way for a UA to know
    how many parameters a particular model takes, so it cannot skip
    over unknown values.  I would suggest that the rgb specification
    be changed to one of (in decreasing order of preference):

         rgb(1.0, 0.0, 0.0)
         rgb[1.0, 0.0, 0.0]
         rgb(1.0 0.0 0.0)
         rgb[1.0 0.0 0.0]

    with the specification that a keyword will be followed by a value
    contained in a balanced set of parentheses/brackets, not counting
    those in double-quoted strings (for the first four possibilities)
    or will be followed by a colon and delimited by whitespace (for
    the last).

Evan Kirshenbaum                       +------------------------------------
    HP Laboratories                    |Now every hacker knows
    1501 Page Mill Road, Building 1U   |  That the secret to survivin'
    Palo Alto, CA  94304               |Is knowin' when the time is free
                                       |  And what's the load and queue
    kirshenbaum@hpl.hp.com             |'Cause everyone's a cruncher
    (415)857-7572                      |  And everyone's a user
                                       |And the best that you can hope for
                                       |  Is a crash when you're through

Received on Wednesday, 27 December 1995 14:39:07 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:26:38 UTC