Closed Bug 4814 Opened 26 years ago Closed 25 years ago

{ib} block within inline acts as inline with line break

Categories

(Core :: Layout, defect, P3)

Product:
Core
Component:
Layout
Platform:
All
Windows 95
Type:
defect

Tracking

()

Status:
VERIFIED DUPLICATE of bug 991

People

(Reporter: christinehoff4, Assigned: harishd)

References

Details

(Keywords: testcase)

Using 4/8 build on Win 95, Win NT, Win 98, Mac8.5 and Linux. Here is an isolated test from a bug found at http://www.amazon.com: <html> <head> <title>font_face_isolated_from_Amazon</title> </head> <body bgcolor="#FFFFFF"> <font face="Arial"> One text <br> Two text <p> Three text <br> Four text <br> Five text <br> </font> </body> </html> There are 5 lines of text. Line breaks are by <BR> element tags except after 'Two text' which is broken by a <P> element tag. Gecko: When a FONT FACE element tag is inserted (as above), there is no space displayed after 'Two text'. If you eliminate the FONT FACE element tag, there is a space after 'Two text'. Somehow the FONT FACE element tag is affecting the <P> element tag. Comm4.51 and IE: There is a space after 'Two text' whether or not there is a FONT FACE element tag inserted.
Summary: [4.xP]Font face effects <P> behavior → [4.xP]Font face affects <P> behavior
Assignee: troy → kipp
This may be a duplicate of another bug I wrote up #4825
Severity: normal → critical
Status: NEW → ASSIGNED
Summary: [4.xP]Font face affects <P> behavior → {ib} [4.xP]Font face affects <P> behavior
yet-another block inside of an inline bug
*** Bug 4266 has been marked as a duplicate of this bug. ***
QA Contact: 4144 → 4130
Summary: {ib} [4.xP]Font face affects <P> behavior → {ib} block within inline acts as inline with line break
The following demonstrates the problem as well. I would assert that there should be a gap between lines two and three. <div style="display:inline"> One text <br> Two text <div style="margin-top:1em;"> Three text <br> Four text <br> Five text </div> </div> I would say the easiest way of solving this problem is to say "if an inline contains blocks, then it is a block". i.e., if the specifed value of the 'display' property is inline, but the element contains blocks, then the _actual_ value of the 'display' property would simply become 'block'. This is, AFAICT, the easiest way of solving all the {ib} issues.
URL: see text case in comments → see test case in comments
Severity: critical → normal
Whiteboard: [TESTCASE]
Simplest testcase already documented in comments. Marking as [TESTCASE]...
Severity: normal → critical
Target Milestone: M15 → M11
Target Milestone: M11 → M12
Target Milestone: M12 → M15
QA Contact: claudius → petersen
Target Milestone: M17 → M12
Assignee: kipp → harishd
Status: ASSIGNED → NEW
I have the layout part of this issue fixed (ian's test case) in my tree and will be checking it in asap. The remaining issue is what the parser does with the first testcase, which I'm guessing is yet another dup of the infamous "residual style" bug. Passing this to harish to mark duplicate if it's the case...
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → DUPLICATE
<html> <body> <font size=20pt> One text <p> Two text <br> </font> </body> </html> In the above example P is preventing the FONT from leaking in and, therefore, causes "Two Text" to get displayed with a different size. A classic dup. of bug 991. *** This bug has been marked as a duplicate of 991 ***
Status: RESOLVED → VERIFIED
Marking as a duplicate of 991.
URL: see test case in comments
Keywords: testcase
Whiteboard: [TESTCASE]
You need to log in before you can comment on or make changes to this bug.