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)

x86
Windows 95
defect

Tracking

()

VERIFIED INVALID

People

(Reporter: irc_addict, Assigned: pierre)

References

()

Details

(Keywords: compat, css-moz)

Attachments

(1 file)

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).
OS: other → Windows 95
Assignee: rickg → kmcclusk
This looks like a job for super-Kevin.
Status: NEW → ASSIGNED
Target Milestone: M10
Assignee: kmcclusk → kipp
Status: ASSIGNED → NEW
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.
Status: NEW → ASSIGNED
Target Milestone: M10 → M11
Summary: Incorrect frame rendering → margin collapsing bug with empty P elements
Target Milestone: M11 → M13
Updated title to reflect the real problem
Target Milestone: M13 → M15
[empty P elements should be completely ignored, as if they had display:none...]
Updating to default Layout Assignee...kipp no longer with us :-(
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.
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
Summary: [BLOCK] margin collapsing bug with empty P elements → [BLOCK] {css1} margin collapsing bug with empty P elements
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)
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...
Keywords: css-moz
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
Attached file testcase
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
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
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
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
Err, not bug 35768, sorry. I meant bug 35772.
Marking Invalid per Ian's comments on 2000-04-13.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → INVALID
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.

Attachment

General

Created:
Updated:
Size: