[CSS21] Which 'direction' property for replacing 'auto' with static position?

Uri Bernstein pointed out in
https://bugzilla.mozilla.org/show_bug.cgi?id=403328#c2 what seems to
me to be a mistake in the editing or the resolution of issues-2 (the
issues list for http://www.w3.org/TR/2004/CR-CSS21-20040225/ ),
issue #87.  The full text of that issue was:

# Issue 87.
# Description:
# should over-constrained margins use 'direction' of parent, or self?
# http://dbaron.org/css/test/2004/10-mountain-view/cr87-direction
# Resolution:
# Change "If the 'direction' property is 'ltr'" to "If the 'direction'
# property of the containing block is 'ltr'" in 9.4.3. (Done.)
# Change "the 'direction' property" to "the 'direction' property of
# the containing block" in 10.3.3.
# Change "if 'direction'" to "if the 'direction' property of the
# containing block" in 10.3.7 (twice).
# Change "case 'direction' is" to "case the 'direction' property of
# the containing block is" in 10.3.7.
# Change "while 'direction'" to "while the 'direction' property of the
# containing block" in 10.3.8 (twice).
# Change "case 'direction' is" to "case the 'direction' property of
# the containing block is" in 10.3.8.
# Add "The 'direction' property of the initial containing block is the
# same as for the root element." to the first item in the list in
# 10.1.
# Issue close.

(This was a case where Mozilla was (I think) the only browser
implementing what CSS 2.0 said, and we agreed to change to match
other browsers, and change the spec along with it to match everyone
else.)

It's not entirely clear which occurrences the above resolution was
saying should be edited, but as shown in
http://www.w3.org/Style/css21-updates/WD-CSS21-20050613-20040225-diff/visudet.html#abs-non-replaced-width
a number of places in 10.3.7 and 10.3.8 dealing with static position
(rather than overconstrained margins) were edited.  These edits
weren't strictly related to the issue raised or the resolution.

These edits also don't seem sensible to me, since they're making
which side is ignored be determined by the 'direction' property of a
box that's not relevant for any other calculations.  The boxes that
are relevant in the case when the static position is used are the
box and the containing block that it would have if it were static
positioned.  Given that, and given that we're generally using the
containing block's direction for these decisions, I think we should
use the containing block that the box would have had if it were not
absolutely positioned (which is the one used to determine the static
position).

Note that implementing what the spec said did break at least one
real page, as reported in
https://bugzilla.mozilla.org/show_bug.cgi?id=403328 .

Unfortunately my original test case for the issue didn't test
absolutely positioned elements at all, and didn't test margins
separately from static-position, and didn't test whether absolutely
positioned elements used their containing block or the hypothetical
containing block had they been statically positioned.

Uri Bernstein wrote a testcase:
https://bugzilla.mozilla.org/attachment.cgi?id=302176
testing which of 'left' or 'right' is ignored for all 4 cases (out
of the 8 possible choices of direction of element, direction of
containing block, and direction of the containing block it would
have if it were statically positioned) where the values of the
latter two directions differ.  He tested these four cases for all
four statements in section 10.3.7 where the value on one side is
ignored.  (Note that it would probably be useful to also test the
three parts of section 10.3.8 that say the value on one side should
be ignored.)  My results of testing in different browsers, a slightly
extended version of his from
https://bugzilla.mozilla.org/show_bug.cgi?id=403328#c17 , are the
following, where:
  S = Static-position containing block
  A = normal (absolute) containing block
  L = always left side
  C = always center
  E = element's direction property

Case:    A B C D   
================
CSS 2.0  E E E E
CSS 2.1  A A A A (without proposed change)
CSS 2.1  S A A S (with proposed change)
IE 7     S S S S
Safari 3 A A A A (standards mode)
Safari 3 S S S S (quirks mode)
Mozilla  E E L S (Firefox 2 / Gecko 1.8)
Mozilla  A A A S (current trunk)
Mozilla  S A A S (what we're changing trunk to before Firefox 3)
Opera    L C L L (9.25)


Thus I'd propose that in the following places:

 1. Section 10.3.7, paragraph beginning "If all three of 'left',
    'width', and 'right' are 'auto'"
 2. Section 10.3.7, bullet (2), which begins "'left' and 'right' are
    'auto' and 'width' is not 'auto'"
 3. Section 10.3.8, bullet (2), which begins If both 'left' and
    'right' have the value 'auto'"

we replace the text:

# 'direction' [property] of the containing block
(the word "property" is used in 10.3.7 but not in 10.3.8)

with the text:

# the 'direction' property of the element establishing the
# static-position containing block

and then define (in the bulleted list at the beginning of 10.3.7):

# The <dfn>static-position containing block</dfn> is the containing
# block of a hypothetical box that would have been the first box of
# the element if its 'position' property had been 'static' and its
# 'float' had been 'none'.

(There I'm trying to match the wording of the definition of "static
position".)



 [ the following should probably be a separate issue ]

I'd also note that the current wording agreed in the edit I referred
to in the beginning is technically incorrect since the "containing
block" is not an element and thus does not have a 'direction'
property; the wording of the other cases probably needs to be
adjusted to refer to the element establishing the containing block.

-David

-- 
L. David Baron                                 http://dbaron.org/
Mozilla Corporation                       http://www.mozilla.com/

Received on Wednesday, 20 February 2008 23:33:13 UTC