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