TABLE should not inherit properties from P, since P cannot contain TABLE. NB:Both IE5 and NN4.6 get this right.

The above URL rendered the same in Mozilla, Nav4.6, and IE5.!!

??? No they do not. Both IE5 and NN4.6 correctly render the first line red and the second line black. Mozilla renders both lines red.

ok, you're right. I see what you saying in apprunner. I was checking with viewer.

The problem is that the layout is functioning in the standards mode while the parser is inclined to the quirks mode. BTW, work needs to be done in setting appropriate modes from document's DOCTYPE. Assigning bug to peterl@netscape.com Adding hyatt, and myself to the CC list.

Should go away when you finish hooking up parser mode to document DTD mode

Setting prority to P1.

DTD modes are hooked up. The above URL should render ok. Marking bug FIXED.

Using 9/16 Apprunner, verified bug fixed. Table does not inherit from P.

Second line should be black even if we are in standard mode. Because P element SHOULD close before the TABLE element in standard mode. reopen.

Clearing FIXED resolution due to Reopen.

Actually, you're right? P shouldn't contain TABLE in noquirks mode. I'll investigate the problem. Thanx Braden.

In quirks mode: P may contain TABLE for compatibility, but TABLE does not inherit properties from P for compatibility. In standard mode: TABLE inherit properties from parent, but P cannot contain TABLE. Second line should be black in either case after all. But the underlying reason is different.

The attachement renders ok, and the test case renders ok. What is the problem??? I'm guessing this got fixed by some of the other DOCTYPE and quirk mode fixes that have happened these past few weeks. Should this now be marked WORKSFORME?

This is still not fixed on latest build using cvs. Second text in the attachment should be black, but it is red.

Tested using 12/10 build on Win 95. Using a 'transitional' doctype, page renders as Nav 4. Using a 'strict' doctype, page renders the table text in red which is incorrect for the reasons reported stated. Bug is reproduced on Win 95. I agree with reporter.

I have attached screenshots for both the standard mode test case and the quirks mode (transitional DTD) test case (also newly attached). They render correctly AFAICT (table text is never red). This is on Win98. Is Win95 really rendering this differently? If so I am *very* surprised and this should be marked [PP], with the Platform/OS fields filled in correctly. Otherwise, this bug is either WORKSFORME or I have an error in my understanding of the issue. Can someone work out which it is?

I've also tested on Win98, but table text was red in standard mode. I Don't know why my result is different from yours.

Are you using AppRunner or Viewer?

I found mode detection was broken now. I'm really confused since "You are in Compatible mode" is displayed, but table text is red on my environment...

Tested using 12/15 build on Win 95 and Win 98. I am testing in Apprunner with the testcase from 12/15 (containing a 'strict' DTD). In strict (standard) mode in Apprunner, I still see the problem. Text in the paragraph and in the table are both red. I have attached a screenshot from Win 95 but Win 98 is the same.

Ian: If your prefs.js has the following line, please remove it. user_pref("nglayout.compatibility.mode", 2); Viewer will write this line when Style/Compatibility Mode Pref menu was selected. Apprunner would never write it, but it also affect apprunner's behaivior. Note: Apprunner and viewer will incorrectly display "You are in Compatible mode" regardless of the "nglayout.compatibility.mode" pref. This is another bug.

Pierre -- this is a css error, not a parser bug. The style is coming from CSS.

We have in fact 2 problems, one in the parser, one in style: - In standard mode, the HTML parser should close the P when reaching the TABLE. - In quirks mode, the style system should not make TABLE inherit the style from the parent if the parent is P. CCing Rick, in case he wants to fix the first issue before I take care of the second one.

Moving table bugs to M15 just to see how many we have.

Migrating from {css1} to css1 keyword. The {css1}, {css2}, {css3} and {css-moz} radars should now be considered deprecated in favour of keywords. I am *really* sorry about the spam...

Block-moved to attinasi the bugs related to style inside tables

This appears to be fixed now. In standard and quirks mode the table renders correctly (ie. P is red, table is black). Tested in Viewer and Mozilla, checked and I have no nglayout prefs set in either case. Marking WORKSFORME - please advise if this is not working for you.

Yup, looks good to me.