[PATCH] nested <DL> tags don't display properly

VERIFIED FIXED in mozilla1.0.1

Status

()

Core
Layout
P2
normal
VERIFIED FIXED
18 years ago
16 years ago

People

(Reporter: Luis Villa, Assigned: Marc Attinasi)

Tracking

({regression})

Trunk
mozilla1.0.1
x86
Linux
regression
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [TESTCASE] Attachment shows problem, URL)

Attachments

(2 attachments)

(Reporter)

Description

18 years ago
Clarifications:

*I'm using the M7 build, despite the "other" tag above.
*The given URL does not display the error; however, after going to that URL,
clicking on "read the boards" and then any "read the thread" button will
reproduce the problem. I've attached a code snippet to demonstrate the usage in
the page.

Description:

The page uses nested <DL> tags within a post form to provide indentation for a
threaded BBS (use of older Netscapes, IE4, and Lynx all generate the desired,
tree-like, indentation.) Mozilla only recognizes the first <DL>, which leaves
lower-level posts un-indented, resulting in a flat structure without the desired
indentation.

in other words, a page should appear as so:
<dl>
	<dl>
		<dl>
		</dl>
	</dl>
</dl>

but is in fact rendered as:
<dl>
<dl>
<dl>
</dl>
</dl>
</dl>


AFAICT, HTML 4.0 allows this nested usage of the DL tag, though it is
"discouraged." The standard says that exact presentation depends on the user
agent, so although this presentation is probably technically
standards-compliant, it is probably not as correct as it could be.

I've also checked, and the <dl *compact*> in the HTML below is not the cause of
the problem.

HTML:
<p><form method=post action=http://www.sagarmatha.com/dbrboard/bin/bplist.cgi>
<dl compact>
<dd>
<input type=radio checked name=article
value=/home/james/sagarmatha/dbrboard/boards/3830/message.txt>&nbsp;&nbsp;&nbsp;<font
color=#00ff00>Report from Nike Camp (1989)
 - Bubba
 (06/22/99 18:53)</font></dd>
<dl compact>
<dd>
<input type=radio  name=article
value=/home/james/sagarmatha/dbrboard/boards/3830/1/message.txt>&nbsp;&nbsp;&nbsp;<font
color=#ff8800><b>Great fun, looking forward to next (dated) report **
 - Jason Evans
 (06/23/99 06:53)</b></font></dd>
<dl compact>
</dl>
</dl>
</dl>
<center><table><tr><td align=center><input type=submit name=submit value="Read
the Article">
</td></tr></table></form>

Comment 1

18 years ago
Chris -- can you verify this on linux and mac? It works perfectly (or I'm
missing the problem) on NT.
Assignee: rickg → petersen

Updated

18 years ago
Assignee: petersen → rickg

Comment 2

18 years ago
With the latest build (1999062808), I can reproduce the problem described with
nested DL elements. This problem occurs on all platforms. I have attached a
simply case that reproduces the problem.

Comment 3

18 years ago
Created attachment 570 [details]
This test case contains a nested set of DL's

Updated

18 years ago
Status: NEW → ASSIGNED

Updated

18 years ago
Assignee: rickg → kipp
Status: ASSIGNED → NEW

Comment 4

18 years ago
Kipp - It's a low priority -- but this one is a layout problem. The content
model is formed exactly as you'd expect.
Whiteboard: [TESTCASE] Attachment shows problem

Updated

18 years ago
Status: NEW → ASSIGNED
Priority: P3 → P2
Target Milestone: M9

Updated

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

Comment 5

18 years ago
I updated the ua.css so that nested DL's indent properly

Updated

18 years ago
Status: RESOLVED → VERIFIED

Comment 6

18 years ago
Fixed in the July 16th Build (All Platforms)
(Reporter)

Comment 7

16 years ago
Re-opening. I assume the source of the bug is not the same, but the rendering is
broken again in basically exactly the same way as it was two years ago. The old
testcase still demonstrates the problem just fine. This was fine with the build
from two days ago (I still have that tarball; I can check the exact stamp on
that build in a couple minutes) but is broken in 2001031405. 
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
(Reporter)

Comment 8

16 years ago
For reference, this worked with 2001031121. Additionally, the bug is so old the
parent URL has changed. Updating that with a more useful one.
(Reporter)

Comment 9

16 years ago
Forgot to add the keyword.
Keywords: regression
Reassigning to default component owners.
Assignee: buster → karnaze
Status: REOPENED → NEW

Comment 11

16 years ago
Reassigning to attinasi and moving to m1.0.1
Assignee: karnaze → attinasi
Target Milestone: M9 → mozilla1.0.1
(Reporter)

Comment 12

16 years ago
Some more details: 2001031208 works, 2001031221 does not, and the builds in
between segfault for me. So the brokenness was checked in some time during the
work day on 03/12. Hope that helps track down the bug.
(Assignee)

Comment 13

16 years ago
Looks like this rule has to be added to quirks.css (must have gotten removed?)

dl > dd, dl > dl {
  display: block;
  margin-left: 40px;
}


note: now it is in as:

dl > dd {
  display: block;
  margin-left: 40px;
}
Status: NEW → ASSIGNED
(Reporter)

Comment 14

16 years ago
Solves the problem for me. Thanks!
(Reporter)

Comment 15

16 years ago
Um... so is this fix ever going to get checked in? It's really irritating to
have to re-edit this every day when I get a new build, and every other major
browser except IE 5 for Mac handles this page correctly. It isn't a major
correctness issue, but it /is/ a correctness/NS4.7 issue and should be fixed. 
(Assignee)

Comment 16

16 years ago
I'll check it in if I can get a review and super-review.

liv - do you want to review the change? You have been running with it.

BTW: sorry to have caused you annoyance, but this is a pretty esoteric case so
it has not gotten much attention from me.
Keywords: patch
Summary: nested <DL> tags don't display properly → [PATCH] nested <DL> tags don't display properly
(Reporter)

Comment 17

16 years ago
Sorry to give the impression I was terribly annoyed. Obviously, this is a minor
case and you guys all have lots of things on your plates. I just didn't want it
to slip through the cracks :) 
Anyway, I'm not sure that I have what it takes to review, but I have been
running this fix for a month so I guess I can throw in an 

r=liv@duke.edu

for what it is worth. 
(Assignee)

Comment 18

16 years ago
Patch for approval:

Index: mozilla/layout/html/document/src/quirk.css
===================================================================
RCS file: /cvsroot/mozilla/layout/html/document/src/quirk.css,v
retrieving revision 1.16
diff -u -3 -r1.16 quirk.css
--- quirk.css	2001/03/24 06:25:33	1.16
+++ quirk.css	2001/05/15 23:21:16
@@ -186,7 +186,8 @@
   content: "";
   margin: 0;
 }
-dl > dd {
+/* dl > dl quirk to allow indenting of nested dl  (b=8749) */
+dl > dd, dl > dl {
   display: block;
   margin-left: 40px;
 }
(Reporter)

Comment 19

16 years ago
I don't mean to be a whiny bitch, but _every_single_other_browser_on_the_planet_
(IE, Netscape 4.x, Opera, and the new OS X one whose name escapes me at the
moment) renders this tag sequence correctly. And it is a one line patch! How
hard can it be to get this in to the tree and close this out? 
(Assignee)

Comment 20

16 years ago
Created attachment 40891 [details] [diff] [review]
Patch updated since dbaron;s changes to dl / dd handling
(Assignee)

Comment 21

16 years ago
OK liv, I'll get this in to the trunk. Sorry to drive you to whining...

Comment 22

16 years ago
Why is this quirks-mode only?
(Reporter)

Comment 23

16 years ago
Chris: I think that the original assessment (~M7) was that it was a quirk
because the HTML spec says that this doesn't /have/ to be supported, and that
CSS should be used instead. Of course, this is untenable if you want to support
Lynx, NS 3/4, etc., so even though the spec says "this isn't the right way"
every browser on the planet does it anyway. So... it is permissible under the
spec but not required, hence quirks. 

Comment 24

16 years ago
Ok, dbaron just enlightened me as to dl's not containing dl's. So quirks-only is
cool, sr=waterson.
(Assignee)

Comment 25

16 years ago
Checked into trunk (quirk.css ver 1.25)
(Assignee)

Comment 26

16 years ago
Marking FIXED, but if anybody thinks there is a case for including this in the
0.9.2 branch, please reopen and state your case...
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago16 years ago
Resolution: --- → FIXED
(Reporter)

Comment 27

16 years ago
Dumb question: I'm not following as closely as I used to :/ if it doesn't go in
for 0.9.2, when /will/ it go in? Still for 1.0 or for post 1.0?
(Assignee)

Comment 28

16 years ago
Since it is in the trunk now, it will be in all subsequent Mozilla releases,
certainly 1.0, or earlier milestones if there are any (unless someone backs it
out, of course).
(Assignee)

Comment 29

16 years ago
*** Bug 77723 has been marked as a duplicate of this bug. ***

Comment 30

16 years ago
Marking verified in the Sept 06 build (2001-09-06-05)
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.