W3C home > Mailing lists > Public > www-style@w3.org > December 2010

[CSS21] Summary of my unfiled/disputed issues that still affect WD-2010-12-07

From: Anton Prowse <prowse@moonhenge.net>
Date: Wed, 15 Dec 2010 05:51:58 +0100
Message-ID: <4D08496E.90101@moonhenge.net>
To: "www-style@w3.org" <www-style@w3.org>
CC: fantasai <fantasai.lists@inkedblade.net>
The following is a summary of all of the CSS21 issues which I have 
raised in the past and which are still applicable to the current Working 
Draft, but which have either not yet been filed in the Issues list or 
which have been filed and resolved but whose resolution I am disputing.

This current post contains no additional information about the issues, 
with the exception of one of the Clearance issues (CL4) and two of the 
Inline Formatting issues (IF3, IF4).

A number of new review comments on the WD will follow in due course.

Margin collapsing

MC1) http://lists.w3.org/Archives/Public/www-style/2010Sep/0698.html

Tweaks required to margin collapsing wording.  In particular there is an 
important falsehood.

Status: I am disputing the resolution to accept the proposed new wording 
without addressing these issues.

MC2) http://lists.w3.org/Archives/Public/www-style/2010Jul/0024.html

There is a redundant sentence in 8.3.1.  Note, however, that this issue 
becomes obsolete with fantasai's proposed new wording of this section
assuming that that proposal is accepted.

Status: unfiled

Elements, boxes, properties

BOX1) http://lists.w3.org/Archives/Public/www-style/2010Jul/0437.html 
(Issue 2)

Whilst the main part of the issue raised has been resolved, there still 
remains the issue that 12.5 (Lists) doesn't fully specify the box 
generation; that is, one has to assume that the contents of a list item 
element participates in an inline formatting context within the 
list-item's principal block box:
   # An element with 'display:list-item' generates a principal box for
   # the element's content [...]
s/box/block container box/

BOX2) http://lists.w3.org/Archives/Public/www-style/2010Aug/0179.html 
(Issue 1)

Editorial issue with 9.2.1 (Block-level elements and block boxes): 
block-level elements which generate additional boxes.  We must note that 
tables are also block-level boxes which generate additional boxes.

Status: unfiled

BOX3) http://lists.w3.org/Archives/Public/www-style/2010Jul/0439.html 
(first half)

When an inline box contains a block box, it is split and the line boxes 
on either side of the break are enclosed in anonymous boxes, as per (Anonymous block boxes).  But precisely /which/ line boxes?

Status: unfiled

BOX4) http://lists.w3.org/Archives/Public/www-style/2010Aug/0036.html 
(Issue 3)

It's unclear where floats and APs live in the box tree.  Given that 
they're out of flow, one assumes that they have no influence on the 
generation of anonymous boxes

Status: unfiled

BOX5) http://lists.w3.org/Archives/Public/www-style/2010Aug/0006.html 
(Issue 5)

Anonymous block example in is incorrect; there is no anonymous 
block box around the P since prior to splitting the inline the BODY 
established an inline formatting context, and after splitting the BODY 
establishes a block formatting context with three block children (two of 
which, containing C1 and C2, are anonymous).

Status: filed as Issue 179 but not correctly resolved

BOX6) http://lists.w3.org/Archives/Public/www-style/2010Jul/0438.html 
(Issue 2)

Lack of clarity about whether a block-level box generated by a 
pseudo-element is a principal box, and whether it's an anonymous box.

Status: unfiled

BOX7) http://lists.w3.org/Archives/Public/www-style/2010Oct/0651.html

Problems with the containing block terminology throughout the spec

Status: unfiled

BOX8) http://lists.w3.org/Archives/Public/www-style/2010Nov/0096.html 
(middle part)

Trivial editorial issues concerning box types in 17.4 (Tables in the 
visual formatting model)

Status: unfiled

Block formatting contexts

BFC1) http://lists.w3.org/Archives/Public/www-style/2009Jan/0352.html

Editorial issue concerning the narrowing of BFCs next to floats.

Status: unfiled, but I assume the WG prefer to leave this undefined for 


P1) http://lists.w3.org/Archives/Public/www-style/2009Feb/0396.html

Editorial issue with 9.4.3 (Relative positioning) concerning the lack of 
consistency between the top/bottom and left/right cases when one 
property is 'auto'.

Status: unfiled

P2) http://lists.w3.org/Archives/Public/www-style/2010Apr/0529.html

Editorial issues in 10.3–10.7

Status: unfiled


FL1) http://lists.w3.org/Archives/Public/www-style/2010Sep/0053.html
see also:
Original post:
(Issues 2 and 3)

(a) Definition of floats "fitting" in 9.5 doesn't tie in with rules in 
9.5.1 (Issue 2)
(b) In reality, prior content either stays on the same line or isn't 
reflowed at all (Issues 2 and 3)

Status: Filed as Issue 192, but I am disputing the resolution

FL2) http://lists.w3.org/Archives/Public/www-style/2009Oct/0058.html

9.5 wording is wrong for RTL text next to floats.  (Issue raised by 
Øyvind Stenhaug)

Status: unfiled

FL3) http://lists.w3.org/Archives/Public/www-style/2010Mar/0366.html

Various ambiguities concerning how to flow line boxes "next to" floats 
in different containing blocks

Status: unfiled

FL4) http://lists.w3.org/Archives/Public/www-style/2010Sep/0130.html

Editorial issue: modification needed to new wording about "next to" floats

Status: unfiled

FL5) http://lists.w3.org/Archives/Public/www-style/2010Sep/0131.html 
(Issue 1)
(first half)
(first third)

No shortening of line boxes next to later floats

Status: unfiled

FL6) http://lists.w3.org/Archives/Public/www-style/2010Sep/0131.html 
(Issue 2)
(second third)

A left float can be to the right of a right float in certain situations

Status: unfiled


CL1) http://lists.w3.org/Archives/Public/www-style/2010Aug/0259.html 
(last part)

Editorial issue: the definition of clearance as spacing above the 
margin-top of an element is incorrect

Status: unfiled

CL2) http://lists.w3.org/Archives/Public/www-style/2010Sep/0665.html 
(first half)

Definition of hypothetical top border edge position should be the actual 
top border edge position after assuming clear:none

Status: unfiled.  (I am disputing the resolution of Issue 203)

CL3) http://lists.w3.org/Archives/Public/www-style/2010Jul/0023.html

s/Clearance inhibits margin collapsing/Clearance inhibits certain 
margin-collapsing behaviour/

CL4) http://lists.w3.org/Archives/Public/www-style/2010Aug/0477.html 
(last part)

In 9.5.1, the following phrase appears:
"clearance is introduced and margins collapse"
I suggest we append the word "anew", since they collapsed before too but 
under different (temporary) conditions

Status: unfiled

CL5) http://lists.w3.org/Archives/Public/www-style/2010Aug/0526.html 
(second half)
(second half)

Proposal to prevent clearance from having too marked an effect in 
certain cases involving self-collapsing clearing elements

Status: unfiled

CL6) http://lists.w3.org/Archives/Public/www-style/2010Aug/0569.html 
(second half)

Clearance is underspecified

Status: unfiled

Stacking contexts

SC1) http://lists.w3.org/Archives/Public/www-style/2010Oct/0561.html

One typographical and one technical/editorial issue ("non-positioned 
floats") still remain after the bulk of my proposals were adopted.

Status: unfiled.  (See Issue 60)

Chapter 10 widths/heights

DET1) http://lists.w3.org/Archives/Public/www-style/2010Aug/0000.html 
(Issue 3)

10.6.1 and 10.6.3 also apply to anonymous boxes.

Status: unfiled

DET2) http://lists.w3.org/Archives/Public/www-style/2010Aug/0108.html 
(Issue 4)

Editorial issue in 10.6.3 concerning margin collapsing.

Status: unfiled

DET3) http://lists.w3.org/Archives/Public/www-style/2010Aug/0001.html

Editorial issue: titles in 10.3 and 10.6: inline block "in normal flow".

Status: rejected, but Boris Zbarsky disputes that: 

Inline formatting model
Note that Issue 181 (http://wiki.csswg.org/spec/css2.1#issue-181) covers 
some but not all of the Inline Formatting issues summarized here.

IF1) http://lists.w3.org/Archives/Public/www-style/2009Mar/0004.html 
(Issue 3a)

10.6.1 (Inline, non-replaced elements) says:
   # The vertical padding, border and margin of an inline, non-replaced
   # box start at the top and bottom of the content area, [...]

The wording is poor.  David Baron suggests:
   | The vertical padding, border and margin of an inline, non-replaced
   | element start at the top and bottom of the content area of the
   | inline box, [...]

Status: proposal given, but unfiled.

IF2) http://lists.w3.org/Archives/Public/www-style/2009Mar/0004.html 
(Issue 3b)

10.6.1 (Inline, non-replaced elements) says (just as for Issue 3a):
   # The vertical padding, border and margin [..] start at [..] the
   # 'line-height'.
But 'line-height' is a property (and its values are 'quantities') not a 
physical entity; nothing can "start" there.

Status: rejected, but I dispute that. Unfiled.

IF3) http://lists.w3.org/Archives/Public/www-style/2009Mar/0004.html 
(Issues 10b)
(Issue 10d)

Editorial issues concerning baselines and font metrics.  My proposed 
resolution is as follows.


   # Empty inline elements generate empty inline boxes, but these boxes
   # still have margins, padding, borders and a line height, and thus
   # influence these calculations just like elements with content.

   | Empty inline elements generate empty inline boxes, but these boxes
   | still have a line height, a baseline and typically non-zero content
   | area height (in addition to margins, padding and borders) and thus
   | influence these calculations just like elements with content.

and link "a baseline and typically non-zero content area height" to the
new sentence in the Working Draft:

   # The height and depth of the font above and below the baseline are
   # assumed to be metrics that are contained in the font. (For more
   # details, see CSS level 3.)

This suggestion is based on the following rationale.

The fact that empty inline boxes have margins, padding and borders is
irrelevant to the calculations, is obvious, but is harmless to be
reminded of;  the fact that they have a line height is obvious and
relevant;  the fact that they have a baseline is obvious if one believes
that Issue 10b is a non-issue(*), and is relevant;  and the fact that
they have non-zero content area height (or rather, what that height is)
is now obvious, and is relevant due to determining the position of the

(*) In fact, I'd argue that Issue 10b is resolved through the power of
suggestion, if the hyperlink is added!

IF4) http://lists.w3.org/Archives/Public/www-style/2009Sep/0025.html 
(Issue 10e)

Despite resolving Issue #119
(http://wiki.csswg.org/spec/css2.1#issue-119; my Issue 8 in [2]) by
removing the reference to a "block's baseline" in one particular
paragraph, the formulation still exists elsewhere.

In fact, the problem is more serious than I originally described, since
in the description of the values of the 'vertical-align' property, the
'baseline' value contemplates what to do with boxes which don't have a
baseline but the other values either don't contemplate them or assume
that the behaviour should be inferred from that of the 'baseline' value.

This suggests that the spec needs to be explicit in its definition of
baseline for boxes which don't have a natural baseline (ie boxes which
are not non-replaced inline boxes).

We can resolve this as follows.

The last two paragraphs of 10.8.1 are:

   # The baseline of an 'inline-table' is the baseline of the first row
   # of the table.

   # The baseline of an 'inline-block' is the baseline of its last line
   # box in the normal flow, unless it has either no in-flow line boxes
   # or if its 'overflow' property has a computed value other than
   # 'visible', in which case the baseline is the bottom margin edge.

These should be moved up to above the definition of the 'vertical-align'
property, and they should be preceded by the following paragraph:

   | The baseline of inline-level boxes which are not inline non-replaced
   | boxes is defined to be the bottom margin edge, except in the
   | following cases.

Then, alter the second paragraph quoted above as follows:

   | The baseline of an 'inline-block' with at least one in-flow line box
   | and whose 'overflow' property has a computed value of 'visible' is
   | the baseline of its last line box in the normal flow.

Finally, delete the second sentence of the definition of the 'baseline'
value of the 'vertical-align' property:

   # baseline
   #     Align the baseline of the box with the baseline of the parent
   #     box. If the box does not have a baseline, align the bottom
   #     margin edge with the parent's baseline.

IF5) http://lists.w3.org/Archives/Public/www-style/2009Aug/0358.html 
(Issue 12)

There may be a vertical gap between line boxes in the presence of floats

Status: unfiled

IF6) http://lists.w3.org/Archives/Public/www-style/2010Jul/0535.html 
(Issues 13-revisited and 14)

The current spec has tiny snippets of info in 10.6.1, 10.6.2 and 10.6.6
which describe the "height" of inline-level elements for the purpose of
calculating the height of the line box, in addition to the descriptions
of how to calculate the height of their content areas.

Issues 13 and 14, taken together, are saying that instead of 10.8
pointing to 10.6 for those snippets, it would be preferable to move
those snippets to 10.8 (where they are more relevant anyway), which does
away with the need to reference 10.6.

Status: rejected but reason unclear. Forms part of Issue 181?

IF7) http://lists.w3.org/Archives/Public/www-style/2010Aug/0010.html 
(Issue 17)

Ambiguity surrounding which "height" to use for inline-level boxes for 
the purposes of calculating line height

status: acknowledged with proposal. Forms part of Issue 181?

IF8) http://lists.w3.org/Archives/Public/www-style/2010Aug/0010.html 
(Issue 18)

Add a note to 10.8.1 about the possibility of negative leading

Status: acknowledged but unfiled

IF9) http://lists.w3.org/Archives/Public/www-style/2010Aug/0010.html 
(Issue 19)

Add a note in 10.6.1 that the content area height of an inline box 
doesn't depend on its descendant boxes (neither in terms of their 
glyphs, font or line-height) but only on its own glyphs and font.

Status: acknowledged but unfiled


OV1) http://lists.w3.org/Archives/Public/www-style/2009Mar/0001.html

Editorial issue with 11.1 (Overflow):

s/absolutely positioned/positioned/ in description of the kinds of 
behaviour that cause overflow.

[Closely-related: Issue 161 (http://wiki.csswg.org/spec/css2.1#issue-161)]

Status: unfiled

White-space processing model

WS1) http://lists.w3.org/Archives/Public/www-style/2010Aug/0421.html 
(Issues 2–8)

Editorial issues.

Status: unfiled


MISC1) http://lists.w3.org/Archives/Public/www-style/2010Jul/0436.html 
(Issue 2)

Editorial issue with 8.6 (The box model for inline elements in 
bidirectional context)

Status: unfiled

Anton Prowse
Received on Wednesday, 15 December 2010 04:52:35 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:49:52 UTC