Closed Bug 28526 Opened 25 years ago Closed 24 years ago

extra vertical space in tables [P-Margin]

Categories

(Core :: Layout, defect, P2)

defect

Tracking

()

VERIFIED DUPLICATE of bug 35772

People

(Reporter: njriley, Assigned: buster)

References

()

Details

(Keywords: compat)

From Bug Helper: User-Agent: Mozilla/5.0 (X11; N; Linux 2.2.12-20smp i686; en-US) BuildID: 2000021808 Mozilla no longer displays my bookmarks page correctly. I worked pretty hard to get it standards compliant, and looking decent under a multitude of browsers. IE5 Win/Solaris, IE4.5 Mac, and earlier Mozilla versions (e.g. M13) do not exhibit this problem. The issue is extra space above the various headers (in green). (Hey, I'm even slightly getting used to using Alt V to type space characters!) Reproducible: Always Steps to Reproduce: 1. Go to the above URL. 2. Observe. 3. Actual Results: Extra space appeared above the headings. Expected Results: A small amount of space appeared above the headings.
Could this be the same thing as in bug 28213 (combo-bug with both font and layout issues) where it's also more analyzed? If that's the case it might be a parser issue. I am, by the way, refused to connect to shore.net.
I have created a simple test case that exhibits this bug, and put it on a Web server which is hopefully more accessible than shore.net. I am not sure whether it is the same as bug 28213, or whether it's a layout or parser problem, so I hesitate to mark this as a duplicate of that bug. Bug 28213 seems to center around parsing of <P> tags, however I don't have any <P> tags inside the table, just a <H3> tag. Check it out at http://www.canis.uiuc.edu/~njriley/moz-bug/
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
I think it is the same bug as bug 28213. It relates to every block level element that has set margin-top: 1em in html.css.
*** Bug 28213 has been marked as a duplicate of this bug. ***
Added rule to html.css so the first child of a TD has a zero top margin
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
I see that this seems to be marked as "resolved", but the bug still exists. I redid Linux.com to work around 1/2 of the bug (the space inside the tables when a <p> is added), by removing the paragraph tags. The second half (related) of this bug is something I could not work around w/o breaking all other browsers... you can see that there should be space under the [more] on the featured article on Linux.com's front page, but it is not there. The content of the page may change, but the layout will remain constant for _at least_ another week or two, meaning that this half of the bug will still be visible. I'll work on a mockup that exposes both bugs in the mean time.
Okay, I have made a static page with nice-n-easy html (with comments on the middle block) to follow that displays both related tag spacing bugs mentioned in previous comments. http://linuxart.com/mozilla/bug/28526/ Be sure to check out the page in Communicator 4.x (and other browsers) to see the difference. I have a screenshot of Netscape 4.72 next to the latest Mozilla nightly build (for your reference) at http://linuxart.com/mozilla/bug/28526/comparison.png
I'm reopening this per the previous comment. Sorry, I haven't checked it at all, since I can't get a Mozilla build at the moment (long story).
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Buster, reassigning to you because this is a block layout issue. The real problem is that Kipp added rules to html.css to specify a top-margin for certain elements. Then to squash them for the BODY he added a rule to suppress it for the first-child. I duplicated that rule for TD as well, and last I looked that fixed the problem Evidently not to people's satisfaction, though. There is a larger issue here, though, because those rules in html.css that specify top margin end up applying to floated and positioned elements and they should not. Unfortunately there's no way in css selectror syntax to say that a rule only applies to in-flow elements. I have petitioned the style system folks to add such a thing The real solution here is for you to examine what Kipp did and come up with a better solution that addresses the full set of problems
Assignee: troy → buster
Status: REOPENED → NEW
Status: NEW → ASSIGNED
Target Milestone: --- → M19
If I'm really going to be the one to look at this, it certainly won't make beta2 and might not make FCS. I'm open to suggestions about what priority it should have.
redistributing bugs across future milestones, sorry for the spam
Target Milestone: M19 → M21
OS: Linux → All
Priority: P3 → P2
Summary: extra vertical space in tables → extra vertical space in tables [P-Margin]
Marking compat. Nom. nsbeta3, recc. nsbeta3[somedate]. Tables widely used for layout on web, so we want to be b.c.
Keywords: compat, nsbeta3
This is a specific example of a more general bug. DUP to 35772 *** This bug has been marked as a duplicate of 35772 ***
Status: ASSIGNED → RESOLVED
Closed: 25 years ago24 years ago
Keywords: nsbeta3
Resolution: --- → DUPLICATE
Verified duplicate.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.