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)
Core
Layout: Positioned
Tracking
()
RESOLVED
INVALID
People
(Reporter: pascalc, Unassigned)
References
()
Details
(Keywords: regression, testcase)
Attachments
(1 file)
(deleted),
text/html
|
Details |
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).
Comment 1•19 years ago
|
||
The Opera9tp2 rendering of this is different from the pic you say represents Opera 8.5 btw.
Comment 2•19 years ago
|
||
The behavior changed between 2004-11-25 and 2004-12-06. Very likely related to bug 201897.
Hardware: PC → All
Updated•19 years ago
|
Assignee: dbaron → nobody
Component: Style System (CSS) → Layout: R & A Pos
QA Contact: ian → layout.r-and-a-pos
Comment 3•19 years ago
|
||
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]
Comment 4•19 years ago
|
||
(In reply to comment #3)
> So is this specific to ul and li?
No, not specific to ul and li.
Comment 5•19 years ago
|
||
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.
Description
•