- From: Anton Prowse <prowse@moonhenge.net>
- Date: Wed, 15 Dec 2010 05:51:58 +0100
- 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
http://lists.w3.org/Archives/Public/www-style/2010Sep/0766.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
(http://lists.w3.org/Archives/Public/www-style/2010Oct/0850.html)
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
(http://lists.w3.org/Archives/Public/www-style/2010Sep/0684.html)
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
9.2.1.1 (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 9.2.1.1 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
http://lists.w3.org/Archives/Public/www-style/2009Mar/0279.html
Editorial issue concerning the narrowing of BFCs next to floats.
Status: unfiled, but I assume the WG prefer to leave this undefined for
CSS21
Positioning
===================================================================
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
Floats
===================================================================
FL1) http://lists.w3.org/Archives/Public/www-style/2010Sep/0053.html
http://lists.w3.org/Archives/Public/www-style/2010Aug/0181.html
see also:
http://lists.w3.org/Archives/Public/www-style/2009Oct/0055.html
http://lists.w3.org/Archives/Public/www-style/2009Oct/0057.html
Original post:
http://lists.w3.org/Archives/Public/www-style/2009Oct/0027.html
(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)
http://lists.w3.org/Archives/Public/www-style/2010Sep/0148.html
(first half)
http://lists.w3.org/Archives/Public/www-style/2010Sep/0150.html
(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)
http://lists.w3.org/Archives/Public/www-style/2010Sep/0150.html
(second third)
A left float can be to the right of a right float in certain situations
Status: unfiled
Clearance
===================================================================
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)
http://lists.w3.org/Archives/Public/www-style/2010Aug/0374.html
http://lists.w3.org/Archives/Public/www-style/2010Aug/0309.html
http://lists.w3.org/Archives/Public/www-style/2010Aug/0477.html
http://lists.w3.org/Archives/Public/www-style/2010Aug/0526.html
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)
http://lists.w3.org/Archives/Public/www-style/2010Sep/0665.html
(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:
http://lists.w3.org/Archives/Public/www-style/2010Aug/0009.html
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)
http://lists.w3.org/Archives/Public/www-style/2009May/0191.html
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)
http://lists.w3.org/Archives/Public/www-style/2009May/0191.html
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)
http://lists.w3.org/Archives/Public/www-style/2009Sep/0025.html
(Issue 10d)
Editorial issues concerning baselines and font metrics. My proposed
resolution is as follows.
Replace:
# 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.
with:
| 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
baseline.
(*) 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)
http://lists.w3.org/Archives/Public/www-style/2010Aug/0010.html
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
Overflow
===================================================================
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
Miscellaneous
===================================================================
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
Cheers,
Anton Prowse
http://dev.moonhenge.net
Received on Wednesday, 15 December 2010 04:52:35 UTC