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

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

From: Anton Prowse <prowse@moonhenge.net>
Date: Mon, 14 Mar 2011 23:07:08 +0100
Message-ID: <4D7E918C.6040005@moonhenge.net>
To: "www-style@w3.org" <www-style@w3.org>
CC: Sylvain Galineau <sylvaing@microsoft.com>
I'm surprised by the decision to postpone some of issues #2-#10.  (Note 
that #1 is treated separately as Issue 271.)  In the case of #5 and #8 
the spec is wrong or genuinely ambiguous as it stands.  And as for #9, 
the spec is going to look pretty amateurish without cleaning up that 
example!  Postponing the rest of them seems OK though.

Cheers,
Anton Prowse
http://dev.moonhenge.net


On 11/03/2011 19:17, Sylvain Galineau wrote:
> Anton,
>
> The CSSWG resolved not to make these changes to the CSS 2.1 specification [1]. We will be
> reevaluating this issue for errata and future versions of CSS.
>
> Please respond before 14 March, 2011 if you do not accept the current resolution.
>
> [1] http://w3.org/TR/CSS
>
> Original message: http://lists.w3.org/Archives/Public/www-style/2011Jan/0087.html
> ISSUE-271: http://wiki.csswg.org/spec/css2.1#issue-271
>
> From: Anton Prowse<prowse@moonhenge.net>
> Date: Fri, 07 Jan 2011 22:15:28 +0100
>   Message-ID:<4D278270.9070009@moonhenge.net>
> To: "www-style@w3.org"<www-style@w3.org>
>
> Issue 1: 9.2.1 (Block-level elements and block boxes) currently says:
>
>     # [...]. Some block-level elements may generate additional boxes in
>     # addition to the principal box: 'list-item' elements. These
>     # additional boxes are placed with respect to the principal box.
>
> I've never liked this part.  Tables also generate an additional box.
> What's more, all block-level elements are capable of generating
> anonymous boxes, depending on their contents.
>
>
> 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.
>
>
> Issue 3: 9.2.1.1 (Anonymous block boxes) says:
>
>     # The properties of anonymous boxes are inherited from the enclosing
>     # non-anonymous box (e.g., in the example just below the subsection
>     # heading "Anonymous block boxes", the one for DIV). Non-inherited
>     # properties have their initial value. For example, the font of the
>     # anonymous box is inherited from the DIV, but the margins will be 0.
>
> "(e.g., in the example just below the subsection heading "Anonymous
> block boxes", the one for DIV)"?  Seriously?  Let's give that example a
> name!
>
>
> Issue 4: 9.2.4 (The 'display' property) says:
>
>     # The computed value is the same as the specified value, except for
>     # positioned and floating elements (see _Relationships between
>     # 'display', 'position', and 'float'_) and for the root element. For
>     # the root element, the computed value is changed as described in the
>     # section on the _relationships between 'display', 'position', and
>     # 'float'_.
>
> Both links are to the same place.  Wouldn't it be better to simply add
> the root element to the first sentence and drop the second sentence
> altogether?
>
>
> 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'?
>
> Also, this information could ideally be repeated in 9.7 (Relationships
> between 'display', 'position', and 'float').
>
>
> 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/
>
>
> 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/
>
>
> 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/
>
> 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.)
>
>
> Issue 9: In 9.5.2 (Controlling flow next to floats: the 'clear'
> property), a new Example 1 has been added - lifted word-for-word from
> [1].  This is a welcome addition, but it needs some proofreading:
>
>     # (B1 has no children and no padding or border)
>
> But it does have positive height, right?  Let's state this.
>
>     # [...]: block B2 with a top margin of M2 (no padding or border, no
>     # children). B2 has 'clear' set to 'both'. We also assume B2 is not
>     # empty.
>
> Really? Non-empty yet with no children?  It could be replaced, I
> suppose, but it's better to say that it has positive height.
>
>     # [...], we are in the situation described in the spec where we need
>     # to add clearance
>
> This needs cleaning up with a proper cross-reference!
>
> We also need to refer to the hypothetical position at some point in this
> example.
>
> In general, the style of this example is far too informal.
>
>
> 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/
>
>
> [1] http://lists.w3.org/Archives/Public/www-style/2009Feb/0108.html
>
> Cheers,
> Anton Prowse
> http://dev.moonhenge.net
>
>
Received on Monday, 14 March 2011 22:08:12 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:38 GMT