Closed Bug 1044 Opened 21 years ago Closed 20 years ago

inheritance problems in tables

Categories

(Core :: CSS Parsing and Computation, defect, P2, major)

x86
Windows 98
defect

Tracking

()

VERIFIED INVALID

People

(Reporter: dbaron, Assigned: attinasi)

References

()

Details

(Keywords: css1)

Attachments

(2 files)

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.‰
Status: NEW → ASSIGNED
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.
Status: ASSIGNED → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
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.
Resolution: FIXED → ---
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...
Severity: normal → major
OS: other → Windows 98
Priority: P1 → P2
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]
Target Milestone: M4 → M6
Target Milestone: M6 → M7
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. ***
Target Milestone: M16 → M15
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. ***
Blocks: html4.01
Summary: inheritance problems in tables → {css1} inheritance problems in tables
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...
Blocks: 22786
Summary: {css1} inheritance problems in tables → inheritance problems in tables
Block-moved to attinasi the bugs related to style inside tables
Assignee: pierre → attinasi
Status: ASSIGNED → NEW
Status: NEW → ASSIGNED
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.
Attached file Text style example
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...
Status: ASSIGNED → RESOLVED
Closed: 21 years ago20 years ago
Resolution: --- → INVALID
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).
No longer blocks: 22786
I spun off bug 31971 for the 'display' vs. TABLE issue.
All issues in this bug are now in other bugs. Verified INVALID.
Status: RESOLVED → VERIFIED
Blocks: 34662
No longer blocks: 34662
You need to log in before you can comment on or make changes to this bug.