RE: CSS1, new draft specification

Hakon wrote:
> As always, comments are welcome.

Here are a few of my own:
I don't like the disappearance of the $CANVAS.  Saying that "In HTML, the 
BODY element is given this role" (of acting as the container for all 
elements) falls down when you think about the effects of the default 
stylesheet on HTML 2.0 documents that do not have a <BODY> (or a <HEAD>, or 
an <HTML>).  Following this mechanism, I could for example only set the 
background color for documents which had a <BODY>.  Blech.  I vote to keep 
the $CANVAS notation from the last draft.

The "sidehead" and simple multiple-column effects are an ugly way to achieve 
that effect.  I'd be much more comfortable ditching the section explaining 
how to do this and instead pointing people to the CSS Layout work you 
(Hakon) mentioned earlier.  Contrary to what you suggested in some email, 
this doesn't just fall out of the support of flushed images.  I'm not saying 
explicitly disallow it, just not suggest it as a solution for multicolumn 

I don't think "indicates to the reader when style sheets are in effect, and 
allows the reader to turn individual style sheets on and off" should be a 
conformity requirement.  This is a user interface issue, if you ask me. 
 Desirable, perhaps; definitely required for accessibility concerns - but 
(IMO) not of higher priority than "making efforts to format documents based 
on the rules in style sheets."  I think this should be a suggestion (as it 
is elsewhere in the spec), not a requirement.

Evan wrote:
>  - 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 }

Much as I hate to add more complexity to CSS1, this could be valuable.  As 
an author, I'd certainly want to be able to control the appearance of the 
labels independently from the content text, for example to make them stand 
out more.

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

I vote for the second option: relative numbers should be required to be 
prefixed with + or -.

>  - is text-indent necessary anymore?  Can't we just say
>         X:first-line { margin-left: 3em }

I agree, but text-indent is a much clearer way of stating this.  Internal to 
an implementation, it would probably make more sense to convert text-indent 
to the above.

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

I'd like to keep away from adding lots of pseudo-classes.  I thought the 
original definition worked fine, anyway - very few stylistic properties 
would make sense on the padding pseudo-class.

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

The traditional treatment of HTML content by a formatter is as one long 
flow, which grows in height (but NOT in width) as needed.  As such, scaling 
to height is difficult if not impossible, since the height can change.