Closed Bug 12302 Opened 25 years ago Closed 25 years ago

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

Categories

(Core :: Layout, defect, P3)

defect

Tracking

()

VERIFIED FIXED

People

(Reporter: dbaron, Assigned: troy)

References

()

Details

(Keywords: css2, rtl)

Attachments

(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". DOES NOT WORK CORRECTLY ON: * Linux, apprunner, 1999-08-20-13-M10
Status: NEW → ASSIGNED
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 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.
Attached file small test case (deleted) —
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 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.
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
OS: Linux → All
Hardware: PC → All
ALSO DOES NOT WORK CORRECTLY ON: * 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.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Verified. Windows: 2000-07-13-09-M17 Linux: 2000-07-13-08-M17
Status: RESOLVED → VERIFIED
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.

Attachment

General

Creator:
Created:
Updated:
Size: