W3C home > Mailing lists > Public > www-style@w3.org > January 2011

Re: [CSS21] Miscellaneous editorial issues - comments on Working Draft

From: Alan Gresley <alan@css-class.com>
Date: Sun, 09 Jan 2011 01:14:18 +1100
Message-ID: <4D28713A.7050209@css-class.com>
To: Anton Prowse <prowse@moonhenge.net>
CC: "www-style@w3.org" <www-style@w3.org>
On 8/01/2011 8:15 AM, Anton Prowse wrote:
> Issue 2: 9.2.1 goes on to say:
> # Except for table boxes, which are described in a later chapter, and
> # replaced elements, a block-level box is also a block container box.
> # [...] Not all block container boxes are block-level elements: [...]
> s/block-level elements/block-level boxes/
> since the sentence doesn't currently make sense.

What about an inline-level element with a display value of block? An 
inline-level element is not a block-level element so saying boxes covers 
both situations.

> Issue 5: 9.3.1 (Choosing a positioning scheme: 'position' property) says:
> # User agents may treat position as 'static' on the root element.
> What does this actually mean? That the used value is 'static'?

I think it means that the used value for position is static.

> Also, this information could ideally be repeated in 9.7 (Relationships
> between 'display', 'position', and 'float').

What information?

> Issue 6: 9.4.1 (Block formatting contexts) says:
> # Vertical margins between adjacent block-level boxes in a block
> # formatting context _collapse_.
> where _collapse_ links to 8.3.1. It's not true though when those boxes
> themselves establish block formatting contexts. (Think table wrappers,
> even if you feel there's a strong argument for saying that floats and
> absolutely positioned elements don't participate in a BFC.)
> I suggest:
> s/collapse/typically collapse/

No, the part you quote says adjacent. This is describing a adjacent 
sibling elements, not adjacent as in adjacent margins between a parent 
and child element.

> Issue 7: Along the same lines, 9.4.1 goes on to say:
> # In a block formatting context, each box's left outer edge touches
> # the left edge of the containing block (for right-to-left
> # formatting, right edges touch).
> s/box's/in-flow box's/

No, the box can be block-level with line boxes. It is the line boxes 
that may shorten (the spec has shrink).

> Issue 8: 9.5.1 (Positioning the float: the 'float' property) says:
> # Applies to: all, but see 9.7
> # This property specifies whether a box should float to the left,
> # right, or not at all. It may be set for any element, but only
> # applies to elements that generate boxes that are not absolutely
> # positioned.
> However, 9.5.2 (Controlling flow next to floats: the 'clear' property)
> # Applies to: block-level elements
> s/block-level elements/block-level elements other than absolutely
> positioned elements/

9.5.2 is title "Controlling flow next to floats". Doesn't that exclude 
absolutely positioned elements?

> and follow the property definition with an analogous sentence for that
> for floats:
> | It may be set for any element, but only applies to block-level
> | elements that generate boxes that are not absolutely positioned.
> (Note that in both cases, the "It may be set for any element" is
> superfluous and should be removed, since this is axiomatic to CSS21.)

The reason why you see mention of absolutely positioned in 9.5.1 is that 
boxes that have both float: left and position: absolute declared on them 
are only absolutely positioned and the use value for float is none.

> Issue 10: 10.3.7, 10.3.8, 10.6.4, 10.6.5 all say:
> # [ignore the value for 'bottom/top/left/right'] and solve for that
> # value.
> (Appears once per section).
> s/solve for that value/solve for that property/

I think "and solve for that value" is sloppy but it is a value for 
either bottom/top/left/right.

> [1] http://lists.w3.org/Archives/Public/www-style/2009Feb/0108.html
> Cheers,
> Anton Prowse
> http://dev.moonhenge.net

Alan http://css-class.com/

Armies Cannot Stop An Idea Whose Time Has Come. - Victor Hugo
Received on Saturday, 8 January 2011 14:14:56 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:07:54 UTC