Error in boxacidtest - floating <H1> "kicked out" of containing div

VERIFIED FIXED in M13

Status

()

Core
HTML: Parser
P3
normal
VERIFIED FIXED
18 years ago
18 years ago

People

(Reporter: chrisn, Assigned: rickg)

Tracking

Trunk
x86
Windows 98
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(6 attachments)

(Reporter)

Description

18 years ago
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.
(Reporter)

Comment 1

18 years ago
Created attachment 4212 [details]
Here's the attachment I mentioned.
(Reporter)

Comment 2

18 years ago
Created attachment 4213 [details]
Oops - the first attachment shows what happens if the h1 is changed to div. This attachment shows the error.
(Reporter)

Comment 3

18 years ago
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.
(Reporter)

Comment 4

18 years ago
Created attachment 4214 [details]
This attachment shows the error when the header tag <h1> is given a float: left style
(Reporter)

Comment 5

18 years ago
Created attachment 4215 [details]
If there is no float declaration, the <h1> tag behaves normally
(Reporter)

Comment 6

18 years ago
Created attachment 4216 [details]
If the header tag with the float style is not the last contained element, it still exhibits odd properties but is properly contained.
Assignee: nobody → rickg
Blocks: 8914
Component: Browser-General → Parser
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.
Created attachment 4260 [details]
simple testcase
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)

Updated

18 years ago
Status: NEW → ASSIGNED
Target Milestone: M13
(Assignee)

Comment 10

18 years ago
I clearly misread the spec, and explicitly kicked h1..h6 out. Fixed in my tree
now, awaiting a chance to land
(Assignee)

Updated

18 years ago
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → FIXED
(Assignee)

Comment 11

18 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

18 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

18 years ago
QA Contact: blakeross → janc

Comment 13

18 years ago
verified
2000-09-15-08-M18
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.