tables don't inherit the properties of a surrounding DIV (and it's clear that the problem is *not* that a table is being (incorrectly) considered to be the end of a DIV). See the Example URL, where the text in the DIV shows up properly on both sides of the table, but incorrectly within the table.‰

For backward compatibility, table cells & captions do not inherit any properties from their container except font & color. I'll look into make this behavoir optional based on compatibility mode.

This behavior is now conditional on compatibility mode.

The current NGLayout doesn't even have them inherit font and color (which seems to be what you want for compatibility). IE's current behavior is to have font inherit, but not color. The above URL didn't work in NN4.07, so I couldn't tell what it did.

Actually I notice your last comment was today... I'll check this out again in a later build.

Also note that in compatibility mode, the only properties to penetrate the table are font and color values assigned to the BODY, not random enclosing elenments.

IE5 does have the font face (not size) inherit in the above example, and I think you could do the same, considering that that doesn't seem to be a compatibility issue, and it is probably better to be as close to the specs as possible as long as you are still compatible with old renderings.

Setting all current Open/Normal to M4.

You're making the choice not to inherit based on display:, not based on the HTML elements. That is, in compatibility mode, you're not inheriting into things that have display: table (or display:table-row with an implied table), even if they aren't TABLE elements. I think you should make that choice based on the fact that an element is TABLE (and probably that it has display: table too). I'll have a test for this soon...

Here is a test page that tests inheritence through tables: http://www.bath.ac.uk/%7Epy8ieh/internet/eviltests/table/inherit.html There are large amounts of bugs visible on this page. I believe some are related to bogus rules in ua.css, and am going to file bugs for those separately. [reducing priority and increasing severity]

Deferring to M10

Pushing off non-beta 1 issues

Reassigning peterl's bugs to myself.

Accepting peterl's bugs that have a Target Milestone

Bug 17082 will be marked as dup of this one. It contains some very simple test cases, similar to test 1.2 in the page provided by Ian on 03/17/99 16:14.

*** Bug 17082 has been marked as a duplicate of this bug. ***

It was suggested this was a dup of Bug 3992. Chris Karnaze's response is: I don't think they are duplicates. I haven't tried the test cases in 3992 lately, but I would guess that the style system is working just fine and the table code is not implementing height on rows, etc. Bug 1044 looks like a style system issue that the table code should not try to fix.

*** Bug 20657 has been marked as a duplicate of this bug. ***

Pushing my M15 bugs to M16

*** Bug 19946 has been marked as a duplicate of this bug. ***

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

This kind of bugwards compatibility makes me very sad. I beg you, implement the CSS spec correctly. Why are you even considering deliberately leaving a bug in the product? Either way, though, <CAPTION> should have the same appearance as the table cells unless otherwise indicated. Currently, it doesn't seem to follow the same "rules". *sigh* With further testing, I have now noticed that Mozilla M12 and Netscape Navigator 4.51 seem to have *different* mis-implementations of inheritance in tables. Some tables that are readable in NN4.51 are unreadable in Mozilla, and vice versa. I'm sure it would be easier to implement CSS correctly than to "correctly" mimic Navigator's bugs. More helpful to Web users, too, not to mention the poor developers. Please do the sensible thing, I beg you.

My memory of CSS2 is that table captions should not look anything like cells (i.e., their borders should not be related). Please correct me if I'm wrong, but it doesn't help to say that "<CAPTION> should have the same appearance as table cells unless otherwise indicated" without backing that up from somewhere. Also, captions should be a separate bug. I'd be interested to see your tests that show Mozilla being more buggy that NN 4.x. It would be much easier if you attached them than to leave us guessing at where such behavior occurs :-) (and having to redo the testing work that you've already done).

Okay, a Mozilla-vs-Navigator test case is now attached. For what it's worth, Mozilla's behavior looks saner than Navigator 4.x on this one. IE5 agrees with Mozilla. Concerning <CAPTION>: It seems to me that if we are to depart from the CSS spec at all, then CSS should be broken for <CAPTION> in the same way as it is broken for <TH> and <TD>. But this is not the case in M12. It appears <CAPTION> does not inherit `color', but <TD> does. (Maybe this is intentional.) Mozilla should just do it according to spec and be done with it. The idea that programmer hours are being spent diagnosing the bugs in Navigator for the purpose of replicating them in Mozilla is absurd.

*** Bug 23683 has been marked as a duplicate of this bug. ***

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

The suggestion that anyone could want inheritance to break is frankly absurd. However, on the more real issue of CAPTION, the problem here is that style is not inheriting into it at all - not even from BODY. For example, <table style="color: red"> <caption> A caption </caption> <tr> <td> Content </table> should inherit the color: red, but does not, even though CAPTION is a descendant of TABLE and should therefore by definition inherit style.

Regardig the testcase added by sacolcor@provide.net on 2000-03-14 09:21 The testcase is showing correct behavior. Using the transitional DTD causes Mozilla to apply some Navigator Quirks to try and emulate the behavior of Nav 4.x, hence the text in the table having a different font. It actually matches what I see if I show the page in Nav 4.7. Using the Strict DTD causes Mozilla to implement the specification correctly, making no attempt to emulate Navigator 4.x, and in this case the display is correct also. If you try Viewer instead of Mozilla you can switch between 'Nav Quirks' mode and 'Standard' mode independently of the DTD specified in the page.

I don't know whether this issue is up for debate, but if it is: I really don't like the idea of triggering NavQuirks mode this way. I have a bunch of code that uses too many deprecated elements to use the Strict DTD, so I /have/ to use the Transitional one. But because of this NavQuirks mode, I can't use the Transitional one without also coding around all the Navigator bugs that it introduces. Thus, if I want to take advantage of Mozilla's standards compliance, I'm forced to move all the way to Strict HTML 4. I would anticipate that relatively few web designers will be in a position to do this. My suggestion: If you /must/ include a NavQuirks mode, make it so that it can be disabled entirely from the Preferences dialog somewhere, rather than corrupting the intent of the DTD declaration. On the author side, some kind of META tag could be used to suggest the use of this mode.

sacolcor, I'm curious what you're doing about IE5 and Nav4 (with your deprecated tags, etc). Does it work in those versions?

IE5 handles the attached example correctly. Navigator 4 and Mozilla do not. My goal is to have Mozilla handle it properly, so that I'll be able to stop special-case coding for Navigator's bugs. As it is right now, Mozilla is only perpetuating the problem.

Thanks for the clarification. This may be another one of those issues where we need to decide if it is better to be compatible with Nav4 or IE5. In other areas, e.g. font size rounding, Mozilla distanced itself from Nav4, even in "NavQuirks" mode. Perhaps your test case should also be considered in that light. Cc'ing Rick Gessner and Steve Clark for that purpose.

Is there a comprehensive list of the effects of NavQuirks mode somewhere? It seems like this is an item that merits thorough documentation.

This should be fixed. You've already been bold enough to part with NS4 in many areas, and inheritance with tables is important. I've noticed that the tables do not inherit any BODY css attributes either.

I'm losing track of the bug here. I believe that the original problem has been fixed (at least it is when the DTD is strict), and the other reported issues are standard vs. quirks mode issues. Please correct me if I'm wrong in this summary: 1) When we are using the strict DTD (or setting standard mode in Viewer) inheritance in tables is not a problem. No Bug. 2) When using the transitional DTD (or setting Nav Quirks mode in Viewer) table inheritance is broken, just like in Nav 4. No Bug (you may not like it, but that is what Nav Quirks are all about). 3) Using the DTD alone to determine Standard vs. Nav Quirk mode is problematic. This is a potential bug, and we should probably consider another mechanism to allow web designers to have transitional documents but not have to suffer through the Nav 4 quirks. This is a seperate bug that would need to be written up. 4) Comprehensive list of Nav Quirks needs to be documented. This is clearly another bug. If I have this straight, then I think this bug is ready to be closed and one or two differnet ones should be opened. Please advise if you disagree with this assesment or have any further detail to add.

>2) When using the transitional DTD (or setting Nav Quirks mode in Viewer) table >inheritance is broken, just like in Nav 4. No Bug (you may not like it, but that >is what Nav Quirks are all about). No, that is not what NavQuirks are all about. Where Nav4 clearly or arguably did the wrong thing, we should do the right thing, where "right" means IE's behavior or the standards, as appropriate, on a case by case basis. I'm OK with the idea of creating separate bug reports.

erik: I only *mostly* agree with your last comment. Whether we fix a "bug" in Nav4 in quirks mode is a measure of two things: 1) how blatantly incorrect is the behavior? 2) how many sites depend on the quirk? The answer to (2) is as important as the answer to (1) for quirks mode. The whole point of quirks mode is to lay out the existing web in a useful way without requiring content developers to change their data. So an important question to answer is, how widespread is the *reliance* on this behavior? This is a tough question to answer in many cases.

I'll agree with attinasi that this bug can be closed, in favor of opening three more: 1) Document NavQuirks. In particular, any HTML/CSS standards violations that result from it. 2) (Depends on #1) Document the behavior of IE5 on each issue from #1. If IE5 matches the W3C spec, we should probably do it that way. If IE5 matches Nav4, we should probably leave the quirk in. If there's no match, it'd be a case-by-case thing. 3) (No Dependencies) Review the trigger for NavQuirks and examine better alternatives, including META tags and Preferences options.

Buster, As far as question 2, I've developed the HotBot.com css to workaround this specifically for Mozilla, which is not natural. Both Win and Mac IE tables inherit from the containing DIV. It seems natural that a table would inherit the attributes from a containing DIV. That's why there's a "C" in CSS. ;) There are cases where this quirk could be handy (autonomous tables), but the advantages of inheritance are more compelling. I think most developers have considered it to be undesirable that tables in previous browsers tended to not inherit any font tags either, but this "quirk" has become accepted behavior. I say fix this for CSS. Furthermore, most CSS on the Web today is optimized for IE since Nav4 is so inept at it. This isn't a scientific conclusion, but it seems logical. When W3C is not clear on this, I say go with the installed standards. In other words, when in doubt be consistent with IE. I hope this helps. --Mike

AFAICT, before the recent discussion, this bug was open for 2 reasons: * my comment of 1998-11-05 18:12 (go with the fewer quirks of Nav or IE, since pages don't depend on quirks that aren't in IE), made when I reopened the bug * my comment of 1999-02-13 17:18 (choice of quirks is based on 'display' property and mode, but should depend also on name of element) There's also a third bug involved here: * what container things inherit from (another issue where Nav4 is quirkier than IE, I think) I think bugs (1) and (2) sacolor@provide.net should probably be filed as one bug. I don't know who should look at it. I guess I'm willing in my infinite spare time if nobody else wants to... Re: (3), I think our current method to trigger NavQuirks is bad because it isn't forward compatible. However, I agree that a META/HTTP header would be a good idea. HTTP does allow Entity headers to be extensible (see sec. 7-1). A bug on this should be filed as well. Please comment on this bug for any spin-off bugs filed so those interested can track them, and so they don't get filed twice. One final comment: I think it's a bad idea to say that NavQuirks mode should emulate Nav4, period. If so, then why develop a new browser? I feel quite strongly that NavQuirks should only emulate bugs that real web pages depend on. If it's a bug that isn't in IE, then there's no way web pages depend on it.

Split off the additional issues, creating bugs 31932 and 31933

I filed bug 31955 as a spin-off bug reporting that inheritance from different containers is not always properly emulated (or understood). I'm now marking this bug INVALID since I believe that all remaining issues have been spun off, and there are no valid issues left here...

There's no bug currently covering my comment from 1999-02-13. Also, I think the choice of putting all the issues in this bug into a single new bug doesn't help. It should be split into two or three, one issue per bug, and we need to carefully check that all the issues mentioned here are covered in the new bugs. The new bug isn't any more useful than this one, because it still covers all the issues. Finally, when a bug is split, it's better to resolve as duplicate rather than invalid (or fixed, if most of the issues are fixed).

I spun off bug 31971 for the 'display' vs. TABLE issue.

All issues in this bug are now in other bugs. Verified INVALID.