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

On 8/01/2011 8:15 AM, Anton Prowse wrote:
[snip]
> 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.


[snip]
> 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