Closed Bug 11229 Opened 25 years ago Closed 24 years ago

Mozilla incorrectly allows TABLE to inherit properties from P

Categories

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

Other
Other
defect

Tracking

()

VERIFIED WORKSFORME

People

(Reporter: braden, Assigned: attinasi)

References

()

Details

(Keywords: css1, Whiteboard: WORKSFORME?)

Attachments

(6 files)

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.
Assignee: harishd → peterl
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.
Assignee: peterl → harishd
Should go away when you finish hooking up parser mode to document DTD mode
Status: NEW → ASSIGNED
Target Milestone: M11
Priority: P3 → P1
Setting prority to P1.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
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.
Status: RESOLVED → VERIFIED
Status: VERIFIED → REOPENED
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.
Resolution: FIXED → ---
Clearing FIXED resolution due to Reopen.
Status: REOPENED → ASSIGNED
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.
Target Milestone: M11 → M12
Blocks: 17907
Blocks: 18471
Target Milestone: M12 → M13
Priority: P1 → P4
Whiteboard: WORKSFORME?
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.
Assignee: harishd → pierre
Status: ASSIGNED → NEW
Pierre -- this is a css error, not a parser bug. The style is coming from CSS.
Target Milestone: M13 → M14
Status: NEW → ASSIGNED
Target Milestone: M14 → M16
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.
Target Milestone: M16 → M15
Moving table bugs to M15 just to see how many we have.
Blocks: html4.01
Summary: Mozilla incorrectly allows TABLE to inherit properties from P → {css1} Mozilla incorrectly allows TABLE to inherit properties from P
Keywords: css1
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...
Summary: {css1} Mozilla incorrectly allows TABLE to inherit properties from P → Mozilla incorrectly allows TABLE to inherit properties from P
Block-moved to attinasi the bugs related to style inside tables
Assignee: pierre → attinasi
Status: ASSIGNED → NEW
Status: NEW → ASSIGNED
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.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago24 years ago
Resolution: --- → WORKSFORME
Yup, looks good to me.
Status: RESOLVED → VERIFIED
No longer blocks: 17907
No longer blocks: 18471
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: