24036 - Residual style solution not fully backwards compatible {compat} {ll} [TEXT]

Status: RESOLVED WONTFIX

(Core :: CSS Parsing and Computation, defect, P3)

Description

[Hixie (not reading bugmail)]

The solution to bug 991 and relatives has some problems. Examine how this test
page: http://www.bath.ac.uk/%7Epy8ieh/internet/projects/mozilla/font.html
...is rendered.

ACTUAL RESULTS:
   1. when an empty inline element is generated, as in:
         <FONT><P>text</P></FONT>
      ...which becomes (AFAICT):
         <FONT></FONT><P><FONT>text</FONT></P>
      ...we lose the margin of the block level element (P) where the empty
      inline element is found... *except* if the block element has borders
      (or padding) in which case it works ok, *except* if the inline (!) has
      margin/padding/borders, in which case the inline is drawn in.
      (In any case, margin/padding/border styles on inline elements should
      not affect layout.)
   2. Rule matching and inheritance is done based on the resulting tree, not
      the tree as it would be if no residual style changes had taken place.
      For example:
         <FONT><P>hello</P></FONT>
      ...would match the CSS rule:
         P FONT { color: red; }
      ...and not
         FONT P { color: green; }
      This means that if, in the above, the document is styled like this:
         FONT { color: red; }
         P { color: green; }
      ...the text will be _red_, not green, even though in the document the
      font is outermost.

EXPECTED RESULTS:
   The first section of the test case should render as in legacy browsers, that
   is, the three parts should be identical (currently only the first is as
   found in legacy renderings).

[ccing rickg since he owned bug 991]
[ccing david as he showed some interest in 991]

NOTE: This is entirely a compatability mode thing. In Standard mode, this issue
will never even arise, as content won't be malformed like this.

Comment 1

[troy]

The second part anyway looks more like a style system issue than a layout
issue since it involves style resolution

Re-assigning to Style System

Comment 2

[Hixie (not reading bugmail)]

This causes a problem on www.ea.com.

Comment 3

[Marc Attinasi]

Assigning to ekrock: 1/3 of Pierre's NEW bugs to help reduce his doomage factor

Comment 4

[Pierre Saslawsky]

Reassigned back to me these bugs that shouldn't have left my list.

Comment 5

[Marc Attinasi]

Attachment: Simple test case to illuminate the problem

Comment 6

[Marc Attinasi]

Futuring, since this won't get into Beta3 / RTM.

Comment 7

[Hixie (not reading bugmail)]

Marking WONTFIX.

This is a compatability issue, but since we are not fixing it for this release,
web authors will have to write their markup to work around the way we render it
regardless of whether we 'fix' it in the future or not. Thus, fixing it in the
future is a waste of our time.

Note that the markup is invalid anyway; so the workaround is simply to fix the
page in question.

Comment 8

[Hixie (not reading bugmail)]

Not taking QA, despite managerial policy, since I set the resolution and thus
cannot verify this bug.

Comment 9

[Hixie (not reading bugmail)]

Netscape's standard compliance QA team reorganised itself once again, so taking 
remaining non-tables style bugs. Sorry about the spam. I tried to get this done 
directly at the database level, but apparently that is "not easy because of the 
shadow db", "plus it screws up the audit trail", so no can do...