Relatively positioned inline elements are containers for absolutely positioned child elements

*** Bug 1235 has been marked as a duplicate of this bug. ***

Some support implemented now, and I'm waiting for W3C clarification on how the containing block should be computed

Verifying as a Reminder.

Troy, is this not done now?

Kind of Ian, but not completely. The open issues relate to what to do if the relatively positioned inline (containing block) is split across multiple lines. What does this mean for child absolutely positioned elements with 'auto' for 'top' or 'left' The spec doesn't really address these issues in sufficient depth, but I know there are cases where we don't really do the correct thing The other open issue is in what defines the containing block width and height in that case. The spec says to use the upper-left of the first line and the bottom-right of the last line (of the continued inline), but that means the width could be positive, 0, or negative and changes wildly as the window resizes That doesn't seem sensible to me. Peter is supposed to be resolving this with the w3 folks

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

REMIND is deprecated per bug 35839.

->dbaron

Adding qawanted; needs a testcase.

Attaching a couple of test cases; I hope they're useful. Some of the odd layout behavior only seems to happen when resizing, and goes away if you refresh. Some odd behaviors stay even after a refresh (especially as you get to narrower sizes). Some of the oddities only appear if 'left' is set to 'auto' (see second test case.)

*** Bug 217002 has been marked as a duplicate of this bug. ***

I'm adding a testcase from my dupe bug, which may or may not cover aspects of this problem not reflected in the other testcases. When rendering this file, one would expect the browser to position the text-link td's within their respective tr's. Mozilla doesn't. MSIE 6 does.

I reopened bug 217002. Please ignore comment 14 and comment 15.

With bug 135082 fixed, we are a lot closer to having this work... The remaining issues are: 1) Auto-offset absolutely positioned boxes with inline relatively positioned containing blocks. This is a problem because the absolutely positioned box is reflown before the placeholder has been placed (basically before the layout of the line the placeholder is in is finished). As a result, the hypothetical box is computed incorrectly. 2) We only use the first-in-flow of the relatively positioned inline instead of doing the complicated ugly thing the spec says we should. To fix (1), we would have to reflow the absolutely positioned boxes after the line is done. I wonder whether we can hack line layout to keep track of inlines that need that extra reflow as it goes and reflow them all once the line has been finished. Fixing (2) is something that I don't really think is worth doing or is really feasible. Especially when you have an inline spanning multiple pages.

> To fix (1), we would have to reflow the absolutely positioned boxes after the > line is done. We already do reflow absolute frames after reflowing the lines.

Oops, I see what you mean. Yeah, we need to reflow absolutes for the positioned inline frames after their lines are done. Shouldn't be too hard. One place to do that would be in nsLineLayout::RelativePositionFrames; it's already scanning the inlines, so detecting relative inlines and and reflowing their absolute frames there will be very little overhead, and allow it to compute the final overflow area for the relative inline, which it needs.

Aha! That sounds perfect. I'll look into it.

nsLineLayout::RelativePositionFrames is also perfect because it's guaranteed to happen after vertical alignment and other positioning tweaks on inlines.

Hmm.. so the abs pos reflow would need to update pfd->mCombinedArea there, right? And presumably we want to reflow the abs pos frames before we start positioning views?

You want to add your reflow call inside this 'if' in RelativePositionFrames: if (pfd->GetFlag(PFD_RELATIVEPOS)) { And yeah, you want to update pfd->mCombinedArea. It will be used either in this invocation of RelativePositionFrames (if the frame is a leaf) or in the recursive invocation of RelativePositionFrames (if the frame is a span). Views get sized and positioned after that.

> 2) We only use the first-in-flow of the relatively positioned inline instead > of doing the complicated ugly thing the spec says we should. For the sake of the not-so-knowledgable (such as myself) I'd like to ask someone to explain this sentence. Specifically, "use the first-in-flow" - use for what? And what is the "compilcated ugly thing"? (A link to its description would be nice.)

Complicated ugly thing: http://www.w3.org/TR/CSS21/visudet.html#containing-block-details item 4 sub-item 1. "use for" means "use as the containing block" (what this bug is about and all). The basic issue is that if you have a positioned inline like so: AAAAAA BBBBBBB with a linebreak in the middle of it (due to line-wrapping), what we do is not what the spec says we should do.

(In reply to comment #25) > Complicated ugly thing: > http://www.w3.org/TR/CSS21/visudet.html#containing-block-details item 4 > sub-item 1. > > "use for" means "use as the containing block" (what this bug is about and all). > The basic issue is that if you have a positioned inline like so: > > AAAAAA > BBBBBBB > > with a linebreak in the middle of it (due to line-wrapping), what we do is not > what the spec says we should do. Boris, I sent an attachment to #78880 that indicates some fishy behavior in <p style=text-indent:#> - </p> and <p style=margin-left:#> - </p>. It might help - I certainly hope so. fredB

Fred, the comments in this bug pretty clearly describe what needs to be done. All that's needed is someone with time to do it. Posting more testcases until the issue of when absolutely positioned boxes with inline containing blocks is fixed is not really that useful....

Spec says: A relatively positioned box establishes a new a new containing block for normal flow children and positioned descendants. But FF does not establish

Eugen: How does your testcase supplement the existing ones?

Opera appears to implement this correctly, at least in 9.5b (no idea how long they've supported it). For fixed, non-"auto" values, Gecko seems correct for "top" and "left" (in LTR), but a bit of testing seems to show that "bottom" and "right" are calculated relative to the top line box, not the bottom one. I believe this latter behavior is comment #17's point (2), which Boris says is not worth doing. Strangely, the standard's weird behavior gives me exactly what I'm trying to achieve (as a CSS author) in the case that brought me to this bug. It does seem a bit twisted, but it makes some sense when you think about it in terms of what people would most likely want to do: position things before or after the text of the element, at a precise height within/above/below the line box. No other position makes much sense in general to position things at, because you can't use padding or other means to guarantee that there's any space. The only exception is if you would want to position something outside the line boxes, say to the bottom left, but in that case you may as well position with respect to a block ancestor. Positioning with respect to an inline ancestor is only really necessary when you're looking at the start or end of the text, *after* adjustment by things that you can't get at by reference to block ancestors (such as floats). So actually I think the standard makes sense here. I don't understand what's supposed to happen if you set left = right = 0 but leave width unconstrained, however. 10.3.7 in CSS2.1 seems not to address that, although 10.1 notes that the containing block might have negative width. I guess you're supposed to ignore the "right" (or "left", in RTL) part, as if it's overconstrained, but nothing says that. It seems that's what Opera does.

This bug, as originally described, has been fixed for ages (see comment 4 and comment 5). We should probably spin off remaining issues into separate bug reports with summaries that are accurate representations of what need to be done (though reopening some duplicates might be an appropriate way to create those bug reports).

I dislike closing age-old bugs that don't have a patch attached and no obvious resolution (especially when I can't even tell for sure what was fixed and what fixed it), so I'll leave this for someone else. I'll reopen bug 489100 though, as there is a concise description of what is broken there.

This was fixed way before patches were typically attached to bugs. In fact, it was fixed before things had to be completed before they were checked in. The fix was the majority of the changes in this query: http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=troy%25netscape.com&whotype=match&sortby=Date&hours=2&date=explicit&mindate=1999-04-14&maxdate=1999-04-26&cvsroot=%2Fcvsroot

Alright then, ->FIXED. Adding verifyme keyword to put this on QA queue. I'm also not entirely sure which tm to use (or if there still is a usable one) so leaving it as Future.

Did any of the other duplicates cover other issues?

Yes, there was one duplicate opened today (bug 489100) which I reopened and confirmed. It seems to me that all three testcases on this bug by Dean Peterson are working. The only other bug that was duped (eons ago) was indeed a direct dupe of this bug and the pasted html seems to be working fine, so I'll leave that duped.

That covers (2) in comment 17, but we still need a bug on (1).

The non-dupe-but-related bug 217002 is still unresolved.

(In reply to comment #38) > That covers (2) in comment 17, but we still need a bug on (1). Filed bug 489207.

mass remove verifyme requests greater than 4 months old