12302 - "right: auto" wrong when "direction: rtl"

Status: VERIFIED FIXED

(Core :: Layout, defect, P3)

Description

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

This is the first of two bugs for my finally half-completed test for CSS2 10.3.7
(widths and margins of absolutely positioned non-replaced elements).

DESCRIPTION:  When direction is rtl, right: auto should set the computed value
of right to the offset of the right edge of where the block would be if it
weren't absolutely positioned.  Right now, it seems to be using what the offset
for left would be instead.

STEPS TO REPRODUCE:  Look at the above URL.

ACTUAL RESULTS:  All the edges that should be at the "right red edge" are
actually about 40px (??) further to the right.

EXPECTED RESULTS:  The edges that should be at the "right red edge" should come
up against, but not cross, the "right red edge".

DOES NOT WORK CORRECTLY ON:
 * Linux, apprunner, 1999-08-20-13-M10

Comment 1

[troy]

Yes, sadly it's true that 'right:auto' is being lazy and not actually
calculating where the right edge of the box would be if it were in the flow.

Comment 2

[troy]

This brings up an interesting question, though, how should this work in all
cases.

Some things to consider:
1. the element is an inline element that is positioned. It's a block, of course,
once positioned, but when calculating where it would have been do we calculate
'right' as if it were inline? That's not easy especially if it would have word
wrapped many lines

2. as far as the left edge goes, does this calculation depend on whether the
element would have been a block or an inline? For example, if it would have been
an inline, then it's left edge is its position in the flow. That's the
placeholder frame for us.

If it would have been a block, then is its left edge calculated differently?
Presumably as a block its left edge is at the left margin of its parent

Calculation of 'top' for an element that would have been a block is tricky,
because of collapsing of vertical white space. Do we need to take that into
account as well, and pretend that it would have started a new block context?

I'm attaching an example that demonstrates these issues.

Comment 3

[troy]

Attachment: small test case

Comment 4

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

The last example in section 9.8.4 of CSS2 seems to show that the answer to your
first question is yes.  That is, you calculate as if 'display' had been
'inline'.  In most cases, this wouldn't be too hard because the direction of the
text would be rtl so the right would be the beginning of the text, not the end.

But that brings up another question.  I'm not very comfortable with the
interaction of the CSS/HTML 'direction'/dir="" and the Unicode directionality
algorithm.  This could get very messy when the two disagree.

Actually, I can't tell the difference between (1) and (2) - I think I
answered(?) both.

And of course, the spec gives you the right to 'estimate' where it would have
been rather than calculate it...

Comment 5

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Perhaps what you should do is the following:

If the 'direction' property on the element is the opposite of the *actual
direction* of text flow in the parent (not the 'direction' property), then use
the content edge of the parent (left edge when direction is 'ltr'; right edge
when direction is 'rtl'), since this is where the content of the element would
start if:
 * it is long
 * it really is what the direction property says.

However, for the default value of unicode-bidi, 'direction' doesn't do anything
to inline elements, so I'm not sure if this is the best idea...

There were some comments on mozilla-i18n that they might actually get rtl
support working, so you may want to talk to them about this stuff...

Comment 6

[troy]

The difference between 1 and 2 is important. 1 is the case of a SPAN, for
example, that was inline and is being positioned. 2 is the case of a DIV, for
example, that is block-level and is being positioned. My test case demonstrates
2.

If you look at the example in IE5 what you'll see is that the positioned element
has its left edge just after "Text" and so it sits over top of "more text". It's
top edge is aligned with the line box

That's not where it would be if it were in the flow. It would be on a new line
and over at the left margin of the document.

Comment 7

[troy]

To make it even less clear, the CSS2 spec in 10.3.7 list item one says: "replace
'auto' with the distance from the left edge of the containing block to the left
margin edge of a hypothetical box"

The wording "left margin edge" implies that they want the margin included in the
calculation. That seems odd.

They also use the words "hypothetical box". I would feel better about this bug
if we had a clear understanding of the position and dimensions of the
"hypothetical box" in all cases (element is inline, element is block, 'ltr',
'rtl')

Cc'ing Peter to get this thoughts

Comment 8

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

ALSO DOES NOT WORK CORRECTLY ON:
 * Windows, apprunner, 1999-08-24-09-M10

Marking All/All

Comment 9

[troy]

At the W3C face to face it was agreed that when the spec says things
like "direction: rtl" it is referring to the specified 'direction' property on
the _containing block_ and not the 'direction' property specified on the
absolutely positioned element

Comment 10

[Hixie (not reading bugmail)]

Migrating from {css2} to css2 keyword. The {css1}, {css2}, {css3} and {css-moz}
radars should now be considered deprecated in favour of keywords.
I am *really* sorry about the spam...

Comment 11

[Christine Hoffman]

Adding 'beta1' keyword. Although to date, it is not clear whether the 'right' 
CSS2 property is supported in beta1 (clarification has been requested), the 
property falls within the general CSS2 'absolute positioning' area, which should 
be supported by beta1. 

Comment 12

[troy]

Removed beta 1...

Comment 13

[troy]

I think we compute 'right' correctly in the new code. I put a very large amount 
of effort into computing the hypothetical box. I take into account whether the 
element would have been inline-level or block-level.

Comment 14

[bsharma]

Verified.
Windows: 2000-07-13-09-M17
Linux:   2000-07-13-08-M17

Comment 15

[(no longer active)]

Mass-assigning the new rtl keyword to RTL-related (see bug 349193).