Comments on Draft 5 (was Re: STYLE attributes)

> First, yes, there is a new CSS draft document out (v5.0 dated 1
> November). The version was put out right before the Style Sheet
> workshop from which I'm slowly getting back to life.
> The changes from 4 to 5 include:
>  - equal sign replaced by colon in declarations
>  - what was previously called "assignements" are now called
>    "declarations"
>  - font-size and font-size-index have merged into one property
>  - a scaling facton of 1.44 (instead of 1.2) is now suggested between
>    adjacent font-size indexes
>  - display-area is a new level 1 property
>  - "bg-style" is a new propety that describes how the background image
>    is to be laid out

All good changes.

> Currently, I'm working on incorporating more of the comments from this
> is (especially from Evan) as well as the feedback from the
> workshop. The document is likely to split into two: level 1 and level
> 2. The first of will be submitted as an I-D ASAP.
> Changes that we are considering in level 1:
>  - dropping context sensitivity: this will lower the threshold for
>    implementors as well as keeping the syntax open.

I don't think that this is a good idea.  The implementation overhead
isn't *that* great, and people are going to want to distinguish things
like EM within H1 from EM within P.  (I still recommend that the syntax
be changed from "(H1)EM" to something like "H1::EM" or "H1/EM",

>    Lists can be
>    discribed using a new-non-inherited property, list-style, that
>    applies only to the children of the element:
>      OL { list-style: upper-alpha }
>      UL { list-style: "red-bullet.gif" }

I think that something like this is needed.  I still lean toward the
template notation I suggested before ["%a. ", "%1)", "(%A)"], as it
allows specification of the punctuation to go around the numbering as

>  - replacing "," with ";" as the declaration delimiter -- it matches
>    the '{}'s better

Please do.  This will make it easier to use comma separated lists in

[other good suggestions deleted]

> As always, comments welcome.

Since you asked...

    o I'd recommend that comments be changed to terminate on EOL.
      HTML has shown that it's tricky to try to get people to worry
      about the parity of the number of dashes.  At the very least you
      may want them to start with "--<ws>" and end with "<ws>--".
      Languages with EOL-terminated comments tend to be easier to
      develop in, since you can more safely comments out blocks of
      code which contain comments.  This is especially true when the
      same delimiter is used for both the start and end.

    o I like the notion of allowing specification by class independent
      of tag, but you run into two problems by using the same notation
      for both classes and tags:  1) the set of tags will grow over
      time and may collide with user-defined classes in legacy
      documents, and 2) classes are not (IIRC) restricted to being
      single tokens.  That is, <P CLASS="Important Stuff"> is legal.
      Since you are already allowing [ID="abcd"] in level one, why not
      just use the same mechanism and say that [CLASS="Important
      Stuff"] is level one as well?

    o I don't like the fact that the document's "important" assertion
      is to be given more weight than my "legal" one.

    o I still think that color needs to take a precedence list, and
      I'd say the same for background.  There will be clients which
      can change color but not import a background, and it should be
      possible to say

           background:  "bg.gif" dark-blue

    o I like the collapsing of font-size-index into font-size.  Is
      there any reason to retain "<number>" as one of the possible
      values?  Since you're not even keeping the Netscape range of
      0..7, with 3 being "medium", it would seem that the enumerated
      tokens would be sufficient.  I'd certainly recommend adding
      "[<number>] larger | [<number>] smaller" to the set of possible
      values, though.  You might also want to put a note to the effect
      that an implementation may (or should?) refuse to go larger than
      "xx-large" or smaller than "xx-small".

    o font-family needs a generic value of "fixed" or "typewriter" to
      handle PRE and TT.  Alternatively, perhaps font-spacing with
      values "fixed" and "variable".

    o For font-weight, I am again not sure what value the number is
      playing, and I would suggest "[<number>] lighter" and
      "[<number>] bolder".

    o For bg-style, I like the idea, but I am uncomfortable with a
      value that begins with "x-", as that space is generally reserved
      for experimental extensions.  Perhaps "repeat-x" and "repeat-y"?

    o I think I've figured it out, but perhaps it would be a good idea
      to put in some words explaining the interaction between
      font-leading and text-spacing.

    o text-decoration should probably be multi-valued, as, e.g.,
      "blink" and "line-through" seem as though they could peacefully
      coexist.  I'm also not sure why the color of the decoration is
      based on the color of the text. (aside: what do you mean by
      "based on"?  the same? contrasting?)  I see that the common case
      may well be to have text and decoration the same, but consider

                    P {color: black}
                   EM {color: red}
         [class="so"] {text-decoration: line-through}

         <span class=so>Here is some <em>struck out</em> text</span>

      I don't think that it makes sense for the line to change color
      for the emphasized words.  On the other hand, I can see wanting
      to say that "this style has words struck out with a red line".
      Perhaps, at least it should be specified that when the
      text-decoration is inherited, its color is inherited as well.

    o What does the <number> in text-position mean?  Perhaps allowing
      "sub" and "sup" to be followed optionally by <length> or
      <percent> might make more sense.

    o I'm a little uncomfortable with "text-transform: capitalize".
      The only place that I can really see it being useful is in
      contexts like <CITE class=book>, but even here not *all* words
      get capitalized.  (Short words like "of" and "the" tend not to,
      unless they're at the beginning of the title, or the beginning
      of an embedded quotation, or ...)  Also, in multi-lingual
      contexts, the notion of what is a word is problematic.  I'd
      recommend just sticking with "uppercase", "lowercase", and
      "none".  Even these can be troublesome, as, for instance, I
      believe that French French capitalizes "" as "A", while
      Quebequois French capitalizes it as "".  What exactly is the
      rationale for this attribute?

    o text-effect would seem that it could reasonably be multi-valued,
      as "drop-cap" and "alt-firstline" work well together, and indeed
      are often seen together in print.  Of course, this opens up the
      problem that they both reference the same properties (alt-font,
      etc.)  Perhaps these should be changed to "cap-font", etc. and
      "first-line-font", etc.  The same question arises for the font
      used for the numbers referenced by "list-style" and will be for
      "insert-before", "insert-after" (and their needed cousins
      "before-line" and "after-line").  Perhaps some more general
      mechanism should be designed at this stage.

    o Also, the discussion of text-effect talks about "the first
      alphabetical letter".  Leaving aside the question of what a
      non-alphabetical letter might be (you probably meant
      "alphabetical character"), this leaves open the question of what
      a browser is supposed to do with

          [class=dc] {text-effect=drop-cap}

          <p class=dc>15 June 1968 was my brother's birthday...
          <p class=dc><q>What?</q> asked Alice...

Evan Kirshenbaum                       +------------------------------------
    HP Laboratories                    |Politicians are like compost--they
    1500 Page Mill Road, Building 4A   |should be turned often or they start
    Palo Alto, CA  94304               |to smell bad.


Follow-Ups: References: