Closed
Bug 38157
Opened 24 years ago
Closed 24 years ago
Floater without a specified width should take up remaining available width
Categories
(Core :: Layout, defect, P1)
Core
Layout
Tracking
()
VERIFIED
FIXED
M17
People
(Reporter: simon, Assigned: buster)
References
()
Details
(Keywords: regression, Whiteboard: [nsbeta2+] [FIX IN HAND])
Attachments
(2 files)
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.14-15mdksmp i686; en-US; m15) BuildID: 2000041811 This is a w3c page, and needless to say it validates properly. It displays fine in Netscape 4.6; however in Mozilla M15 the content is squashed into tall, narrow strip to the left of the page, with the bulk of the page left blank. Reproducible: Always Steps to Reproduce: 1. Point your browser at http://www.w3.org/Jigsaw 2. Errr... that's it. 3. I validated the page against the validator at http://validator.w3.org/, and got: URI: http://www.w3.org/Jigsaw/ Last modified: Thu Apr 27 09:06:46 2000 Server: Apache/1.3.6 (Unix) PHP/3.0.15 Content length: 16781 Character encoding: iso-8859-1 Document type: HTML 4.0 Transitional Below are the results of attempting to parse this document with an SGML parser. No errors found!
Comment 1•24 years ago
|
||
I see this on the page you gave as well as http://www.betanews.com (something similar) with 2000050308 win98
Comment 2•24 years ago
|
||
Reassigning to karnaze. Triaging Troy's bug list. Looks like a table layout problem.
Assignee: troy → karnaze
Comment 3•24 years ago
|
||
The behaviour has changed while with a 2000032909 build I get a to small main section. It is now with a build from 20000512 to wide and goes after the left column. The page does not contain a single <table> tag so I doubt that this is karnaze's field.
Comment 4•24 years ago
|
||
the positioned <DIV>'s do not have any width assigned to them. so, they are getting their intrinsic width. In the case of the second <DIV>, that's very large because of the long text run. Since the second <DIV> does not fit in the space next to the first, it is pushed down to the next line as per CSS2 spec. I think what we should be doing here, and what Nav and IE seem to do, is give the floater the remaining space in the absence of any other width information. I'll have to look into it further to see what the spec says about floated blocks that have no assigned width. cc'd David in case he already knows the answer.
Status: NEW → ASSIGNED
The CSS2 (and perhaps CSS1) specs say that floats with no specified with should have (or tend towards, because of minimum width of inline content) width 0. However, I think some folks want to change this, as shown by Mozilla's current implementation. I guess it's really up to you (perhaps it's worth discussing this with the WG?) how you want to deal with this. CSS1/2 would have a wide float move to the next line, but that doesn't seem to make too much sense here, since the float's width is only being limited by available space...
this is a part of the spec that has not been well defined. Troy implemented it as best he could with the interpretation at that time, but it looks like we'll need to enhance the behavior here.
OS: Linux → All
Priority: P3 → P1
Hardware: PC → All
Target Milestone: --- → M18
Comment 9•24 years ago
|
||
By the way this bug duplicates bug 36587, which was closed as worksforme ???? and assigned to troy.
Assignee | ||
Comment 10•24 years ago
|
||
*** Bug 36587 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 11•24 years ago
|
||
moving nsbeta2 nomination from dup'd bug. This seems to happen on a fair number of pages, we'll get lots of bug reports for beta2 unless we fix this. Est. time to fix: 2 days. Risk: low to moderate.
Assignee | ||
Comment 12•24 years ago
|
||
I know the general form of the solution now, working out some remaining bugs.
Assignee | ||
Comment 13•24 years ago
|
||
I think the remaining problem with my fix is really a GFX Scrollbar bug. If I turn off GFX scrollbars, resizing works perfectly. With GFX Scrollbars turned on, resizing doesn't work because the body is being told it has more available width than it should really have. Could still be my fault, I'm checking... also need to test multiple stacked floaters, all of which are without a specified width.
Summary: Layout goes horribly wrong → Floater without a specified width should take up remaining available width
The GFX scrollbar bug is probably bug 35681.
Assignee | ||
Comment 16•24 years ago
|
||
fix checked in
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Summary: Floater without a specified width should take up remaining available width → Floater without a specified width should take up remaining available widthquirk relating to empty P elements should be removed [P-margin]
Whiteboard: [nsbeta2+] [FIX IN HAND] → (py8ieh: fix testcases) [nsbeta2+][6/22]
Restoring original information from weird bug changes (probably caused by Mozilla bugs). This isn't the best time to use Mozilla on Bugzilla...
Summary: Floater without a specified width should take up remaining available widthquirk relating to empty P elements should be removed [P-margin] → Floater without a specified width should take up remaining available width
Whiteboard: (py8ieh: fix testcases) [nsbeta2+][6/22] → [nsbeta2+] [FIX IN HAND]
Assignee | ||
Comment 18•24 years ago
|
||
Comment 19•24 years ago
|
||
Steve, by "remaining problem" do you mean bug 42685? If so, one of us should make a notation in bug 42685 that a test case relevant to us is present in this bug. If not, could you please REOPEN this or open a separate report if it's a new issue? Thanks!
Comment 20•24 years ago
|
||
Is this bug truely fixed ? I don't see the original probelm as reported.
Comment 21•24 years ago
|
||
With the June 30th build, the problem appears to be fixed.
Status: RESOLVED → VERIFIED
You need to log in
before you can comment on or make changes to this bug.
Description
•