Closed
Bug 23837
Opened 25 years ago
Closed 25 years ago
Error in boxacidtest - floating <H1> "kicked out" of containing div
Categories
(Core :: DOM: HTML Parser, defect, P3)
Tracking
()
VERIFIED
FIXED
M13
People
(Reporter: chrisn, Assigned: rickg)
References
()
Details
Attachments
(6 files)
If you visit the URL, you will see that the final block element on the page, the <h1>, is being kicked out of its containing tag, the <dl>. If the h1 in the style declaration and in the HTML becomes a <div>, the problem goes away. I have created a simplfied test case, which I will attach next. The test case isn't as simplified as it should be, because if the last block of text (within the <p> tags) is removed, the body box collapses vertically, despite what it contains, and I didn't want that confusing the issue. I will file a separate bug against that.
Actually, the other bug I mentioned -- "if the last block of text is removed, the body box collapses vertically, despite what it contains" -- is actually part of this bug, and it helped clarify the problem for me. The problem seems to stem from header tags with a "float" style declaration. This declaration can appear within the style tags, or within the header tag itself. When a header tag has a float declaration, and is contained inside another block-level element, the container, in this case <body>, seems to not realize that the header tag <h1> is its child (similar to the initial problem with this bug), and the header block exhibits the curious property of becoming only as wide as its longest word. So, if we go back to the first attachment that I show that exhibits this bug, 01/13/00 04:24, you will notice that the <h1> block (which has the float: left declaration) has been ejected from its parent container the <dl> block.
Chrisn - I don't understand most of your comments, but the basic problem here is another parser regression... an H1 element is forcing the end of a DD. Attaching simple testcase in a second, and changing component and reassigning and adding dependency to boxacidtest tracking bug.
The three testcases about floating H1s (4214-4216) do not show any bugs, for the following reasons: * Floats, in general, should not cause their parents to expand. * If a float has no width specified, it should tend towards a width of 0. * If a float is followed by an element with 'clear' that must clear the float, the element being cleared can cause the parent to expand. So I think the only bug here is the parser problem.
|
Assignee | |
Comment 10•25 years ago
|
||
I clearly misread the spec, and explicitly kicked h1..h6 out. Fixed in my tree now, awaiting a chance to land
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
|
|
Assignee | |
Comment 11•25 years ago
|
||
Somewhere along the way, my brain got disconnected. As a result, I misread the spec (does any really *read* that tome?) and implemented it wrong. Now it's fixed.
|
||
Comment 12•24 years ago
|
||
*spam* changing qa contact from nobody@mozilla.org to me (BlakeR1234@aol.com) on 121 open or resolved (but not verified) bugs. sorry for the spam everybody, but most of these bugs would just remain dormant and not checked by QA otherwise. I'm not sure how so many bugs have nobody as their QA contact, but I suspect this is the fault of some sort of bugzilla corruption that happened at some point (most of these bugs are in the 20000-26000 range, and I don't see where in the activity log that QA contact explicitly changed to nobody@mozilla.org) Anyways, sorry again for spam. If you really get annoyed, I'm usually available in #mozilla on IRC for torture.
QA Contact: nobody → BlakeR1234
|
|
||
Updated•24 years ago
|
QA Contact: blakeross → janc
You need to log in
before you can comment on or make changes to this bug.
Description
•