Closed
Bug 8938
Opened 25 years ago
Closed 24 years ago
[BLOCK] :first-node does not ignore empty P elements
Categories
(Core :: CSS Parsing and Computation, defect, P3)
Tracking
()
VERIFIED
INVALID
M17
People
(Reporter: irc_addict, Assigned: pierre)
References
()
Details
(Keywords: compat, css-moz)
Attachments
(1 file)
245 bytes,
text/html
|
Details |
On this page, when you load it up, the top frame is supposed to show a java- scroll-box, 2 links, and the word BoCH twice. Unfortunately, it seems to be rendering too much blank space at the top, making the html stuff unviewable (except for the tip-top of the words).
Reporter | ||
Updated•25 years ago
|
OS: other → Windows 95
Updated•25 years ago
|
Status: NEW → ASSIGNED
Target Milestone: M10
Updated•25 years ago
|
Assignee: kmcclusk → kipp
Status: ASSIGNED → NEW
Comment 2•25 years ago
|
||
I extracted a test case from the URL http://www.thebride.com/ The problem is the page lays the first line out differently between "Gecko" and Nav 4.x. On Nav 4.x the first line is rendered at the top of the page. In "Gecko" it is rendered one line down. The problem seems to be the <P> tag following the <BODY> tag. It causes the text to be moved one line down, Test case: <HTML> <BODY> <P><P> BoCH BoCH</P> </HTML> </BODY> Dumping the frames indicates that "Gecko" creates a line for the empty <P> at the beginning. The block frame containing the text has a y offset of 240 twips. If the empty <P> is removed the block frame containing the text has a y offset of 0 twips. The question is, should empty <P> tags cause a blank line to inserted during layout?. Kipp, reassigning to you.
Summary: Incorrect frame rendering → margin collapsing bug with empty P elements
Target Milestone: M11 → M13
Comment 4•25 years ago
|
||
[empty P elements should be completely ignored, as if they had display:none...]
Why are you re-reassing layout bugs? Do NOT touch layout bugs. The bugs are assigned to Kipp so they can stay neatly organized until we have a new owner for the block/inline code.
Updated•25 years ago
|
Whiteboard: (py8ieh:might investigate -- could be interaction with :first-node)
Summary: margin collapsing bug with empty P elements → [BLOCK] margin collapsing bug with empty P elements
Updated•25 years ago
|
Summary: [BLOCK] margin collapsing bug with empty P elements → [BLOCK] {css1} margin collapsing bug with empty P elements
Updated•25 years ago
|
Assignee: kipp → pierre
Component: Layout → Style System
Summary: [BLOCK] {css1} margin collapsing bug with empty P elements → [BLOCK] {css-moz} :first-node does not ignore empty P elements
Whiteboard: (py8ieh:might investigate -- could be interaction with :first-node)
Comment 7•25 years ago
|
||
Yup, as I guessed, this is because of :first-node, and in fact what we are doing is correct as designed. Currently, we lose the margin-top of the first element, due to a rule in html.css, which says: body > *:first-node { margin-top: 0; } This is to act as legacy browsers do, and drops the top margin of the first P element, which (if it had any content) would otherwise have added 1em of margin at the top of the viewport. However, that P is empty (as far as we are concerned) and so we ignore it... but then the next P, which _does_ have a margin, is layed out, and since it is not the :first-node, we do not remove its margin. The fix would be to ignore empty P element for the purposes of :first-node. So, this stylesheet: *:first-node { border: solid; } ...would match the elements with class="matched" in the following: <!-- ... --> <body> <div class="matched"> <p></p> <p></p> <p class="matched"></p> <p></p> </div> Note: that is probably more trouble that it's worth. Unless this bug appears on another page, I would recommend that we mark this WONTFIX. This is not a serious bug, and we can always "define" :first-node to *not* ignore empty P elements, regardless of HTML4, since :first-node is one of our CSS extensions. Since the bug is in the Style System, and not layout, I am reassigning this to that component. Pierre: if you see another way of fixing this, then feel free to reassign it to layout and Kipp pile...
Assignee | ||
Comment 8•25 years ago
|
||
Sorry Ian, that's not the problem here. Empty P tags are ignored wherever they are located, first node or not. In Nav4x and IE, the following code results in just 2 paragraphs: <body> <div> <p></p> <p></p> <p></p> <p></p> <p>first paragraph</p> <p></p> <p></p> <p></p> <p></p> <p></p> <p></p> <p>second paragraph</p> <p></p> </div> Changing the Summary back to "margin collapsing bug with empty P elements" from ":first-node does not ignore empty P elements". It's a block layout bug: reassigning to Kipp's list.
Assignee: pierre → kipp
Keywords: css-moz
Summary: [BLOCK] {css-moz} :first-node does not ignore empty P elements → [BLOCK] margin collapsing bug with empty P elements
Assignee | ||
Comment 9•25 years ago
|
||
Comment 10•25 years ago
|
||
Pierre, you misundertood what I said. I agree that we should ignore P elements whereever they occur -- and we already do this in most cases. However, in this particular case, we are ignoring the first P element for the purposes of the layout engine, but we are _not_ ignoring it when doing the :first-node style resolution. In other words: We already *do* ignore <p> tags wherever they appear -- EXCEPT if they are the first-node, at the moment. In this particular bug, _that_ is the problem. If you look at your attachement, you will see that the second set of <p></p> tags _are_ ignored, as are the first, except that the rule in html.css which is supposed to knock out the first margin for backwards-compatability reasons is not working because it is only knocking it out for the first *empty* <p> element, and not the first _non-empty_ <p> element. Or have I misunderstood something myself?
Keywords: css-moz
Comment 11•25 years ago
|
||
Pierre, per my last comments, I'm reassigning this to you again. The problem is, as far as I can tell, that _we_ *don't* ignore empty <p> elements in the :first-node code, but we *should*. I don't see how the block code can solve this problem. We already correctly handle empty <p> elements in all other cases (well, almost all other cases).
Assignee: kipp → pierre
Severity: normal → minor
Summary: [BLOCK] margin collapsing bug with empty P elements → [BLOCK] :first-node does not ignore empty P elements
Whiteboard: margin collapsing bug with empty P elements
Assignee | ||
Comment 12•25 years ago
|
||
We had 2 problems here: - The bug with "margin collapsing bug with empty P elements" was probably fixed a few days before my "2000-01-27" comment and testcase. It works with recent builds. - The bug with :first-node is still valid. We already skip whitespace text and comments; we should also skip empty P elements (look for "firstNodePseudo" in nsCSSStyleSheet.cpp).
Status: NEW → ASSIGNED
Whiteboard: margin collapsing bug with empty P elements
Comment 13•24 years ago
|
||
This just became a compatability issue, because according to bug 35768, empty paragraphs should no longer be ignored. David, could you make a judgement call here? Is this WONTFIX or INVALID? I think that if empty <p> elements should not actually be ignored, then our :first-node pseudo should not ignore empty Ps either, which then means that this bug has no obvious solution.
Keywords: compat
Comment 14•24 years ago
|
||
Err, not bug 35768, sorry. I meant bug 35772.
Assignee | ||
Comment 15•24 years ago
|
||
Marking Invalid per Ian's comments on 2000-04-13.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → INVALID
Comment 16•24 years ago
|
||
As per meeting with ChrisD yesterday, taking QA. VERIFIED INVALID.
Status: RESOLVED → VERIFIED
QA Contact: petersen → py8ieh=bugzilla
You need to log in
before you can comment on or make changes to this bug.
Description
•