feedback on PR-CSS1

I'm doing a close reading of the PR-CSS1 to see if I can understand
it correctly, and although in some cases I wonder "why" certain choices
were made (such as why negative values are not allowed for IMG widths,
which would seem to allow "flopping" of images across mirror lines),
in general, I think the document shows that a lot of effort has
gone into it. A few impressions...

You may need to add some more text explaining what happens when a
rule using H1 alone is followed by a rule using H1.class1. Which
takes precedence? I suppose the latter, as it is more specific.
A few more examples of this would be useful, especially if style
sheets will be combined/merged.

Section 7.2 indicates that "values with unrecognized parts" are
treated as if the declaration weren't there. Does this mean that someone
who creates a style rule and by mistake includes one wrong part will
find that none of the style rule aspects are put into effect? This
seems quite harsh, especially to newbies.

I'm curious to know why East-West margins are not collapsed, but
North-South margins are collapsed. How do you know what designers
"expect"?

I'm curious to know why leading is added equally on the top and
bottom of the text height to form the line-height. I suppose one
outcome is that lines of text in a paragraph that get a special
font size inline will space themselves equally from the line above
and the line below. But typical typographic practice is to consider
base-to-base spacing to the line above an element, or to the line
below an element (or both, which gets confusing). It's going to be
difficult for authors to know how to get the right leading between
a H1 and a following P, for example. I have to subtract the 
font size of H1 from the line-height of H1, then divide by 2,
then add that to the resulof subtracting the font size of P
from the line-height of P. The result is the total leading between
the elements, to which I have to add the font-size of P to get the
traditional base-to-base leading from H1 to P. Am I right?
This "half-leading" concept will take some getting used to.

In 5.2.6 you suggest 1.5 as a scale factor between font sizes.
This may be too big. Consider that H1 is usually the largest item
on a page, and yet H6 needs to be legible. Since most web docs
use H1 and H2 and sometimes H3, but rarely H4, H5, and H6, this
means a default of HUGE letters for H1 and H2. I know that font-size
is independent of H attributes, but most UAs do use font-size as a
principal way of distinguishing H1-H6. I'd suggest a more modest
1.2 as a factor, since 1.2^6 << 1.5^6.

In 5.6.2, you suggest same values for keywords of list-style
that seem unnecessarily cumbersome. Why not use

[disc | circle | square | 1 | i | I | a | A | none]

instead of the values "decimal", "lower-roman", and so on? This
seems easier, and more akin to word processors with outline features.

Nowhere in the proposed recommendation do you truly define what
a "parent" element is. Is this something we are supposed to know
from the HTML spec? For example, what is the "parent" element of
a paragraph? I need to know that if I am to know what a percentage
value will do if I use it for a negative margin-top. Is it the
percentage of the width of the screen, or a percentage of the 
font-size of the paragraph itself, or of the font-size of the
BODY in which the P is inserted? Or something else?
The document refers to parent and child relationships throughout,
and I can only interpret this to mean the outer and inner items
of a nesting. Is there place for this in the glossary at the beginning?

Minor typo:

7.1 contains auxiliary definitions of hex that say '0' | ... | '7'
when I think it should be '0' | ... | '9' | 'A' | ... | 'F' .







 William I. Johnston
 Watertown, MA   USA
 mailto:wij@world.std.com
 http://world.std.com/%7Ewij/

"We should work toward a universal linked information
 system, in which generality and portability are more
 important than fancy graphics techniques and complex
 extra facilities."
                        --Tim Berners-Lee, March 1989
 http://www.w3.org/pub/WWW/History/1989/proposal.html

Received on Saturday, 16 November 1996 13:46:36 UTC