Closed Bug 329302 Opened 19 years ago Closed 19 years ago

possible regression in width calculation between FF1.0 and FF1.5

Categories

(Core :: Layout: Positioned, defect)

defect
Not set
normal

Tracking

()

RESOLVED INVALID

People

(Reporter: pascalc, Unassigned)

References

()

Details

(Keywords: regression, testcase)

Attachments

(1 file)

If you have nested lists with list items (<li>) having display:inline, in 1.0 and all other browsers, the width of the nested list is the width of the sum of the list items (which creates an horizontal submenu), in Firefox 1.5 the width of the nested list is the width of it's parent's <li> item. You have a testcase here : http://chevrel.org/bugzilla/ff15widthbug.htm I looked at the css spec and I am still unsure if it is a bug or not, I think that since the nested list container has display:inline set, it should set its width according to the nearest ancestor with display block (like in 1.0 and all other browsers).
The Opera9tp2 rendering of this is different from the pic you say represents Opera 8.5 btw.
The behavior changed between 2004-11-25 and 2004-12-06. Very likely related to bug 201897.
Hardware: PC → All
Blocks: 201897
Assignee: dbaron → nobody
Component: Style System (CSS) → Layout: R & A Pos
QA Contact: ian → layout.r-and-a-pos
So is this specific to ul and li? Or can this be reproduced with "div" and "span" (possibly with list-item display styles, etc)? Are both the inner and outer list needed?
Flags: blocking1.9a2?
Whiteboard: [reflow-refactor]
Attached file testcase (deleted) —
(In reply to comment #3) > So is this specific to ul and li? No, not specific to ul and li.
Martijn, thanks for the testcase! So... The containing block for the abs pos div has width 0 (it's the empty span). Per CSS2.1, section 10.3.7 we have: A) left, width, right are all auto. Set margins (which are also auto) to 0. Then set left to the static position (which is 0). Now we apply the numbered rules: 1) Does not apply. 2) Does not apply. 3) Applies. Width is shrink-to-fit. To compute the shrink to fit width, we need to find the available width, preferred width, and preferred minimum width. These are: preferred width -- total length of text. preferred minimum width -- length of longest word available width -- width of containing block (in this case, 0). Then we do: min(max(preferred minimum width, 0), preferred width) That gives the preferred minimum width. That's what you see in that testcase. Note that before bug 201897 landed we made the div width 0, but screwed up the wrapping of the span inside it. That's been fixed, of course.
Status: NEW → RESOLVED
Closed: 19 years ago
Flags: blocking1.9a2?
Resolution: --- → INVALID
Whiteboard: [reflow-refactor]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: