Closed Bug 12302 Opened 21 years ago Closed 20 years ago

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


(Core :: Layout, defect, P3)






(Reporter: dbaron, Assigned: troy)




(Keywords: css2, rtl)


(1 file)

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".

 * Linux, apprunner, 1999-08-20-13-M10
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.
This brings up an interesting question, though, how should this work in all

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.
Attached file small test case
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...
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...
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

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.
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',

Cc'ing Peter to get this thoughts
OS: Linux → All
Hardware: PC → All
 * Windows, apprunner, 1999-08-24-09-M10

Marking All/All
Target Milestone: M12
Summary: "right: auto" wrong when "direction: rtl" → {css2} "right: auto" wrong when "direction: rtl"
Target Milestone: M12 → M13
QA Contact: petersen → chrisd
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
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...
Keywords: css2
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. 
Keywords: beta1
Removed beta 1...
Keywords: beta1
Summary: {css2} "right: auto" wrong when "direction: rtl" → "right: auto" wrong when "direction: rtl"
Target Milestone: M15 → M17
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.
Closed: 20 years ago
Resolution: --- → FIXED
Windows: 2000-07-13-09-M17
Linux:   2000-07-13-08-M17
Mass-assigning the new rtl keyword to RTL-related (see bug 349193).
Keywords: rtl
You need to log in before you can comment on or make changes to this bug.