Closed Bug 31971 Opened 23 years ago Closed 13 years ago

table inheritance quirks should depend on tag name


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






(Reporter: dbaron, Unassigned)



(Keywords: css2)


(1 file, 2 obsolete files)

DESCRIPTION:  The table inheritance quirks should not occur on an element unless
it has both:
 * 'display: table'
 * element name of 'table'  (CI)
If only one of these conditions is met, but not the other, then the author
clearly wants a CSS compliant browser, and the table inheritance quirks should
not occur.  (This behavior would not be supported in older browsers.)

Currently the quirk is based only on 'display', but it should require also that
the tagname be TABLE (or TD/TH, if it's done per-cell).

 * load attached test case

 * the five lines of text vary (they should all be in the same font) - actually
one of them doesn't show up and that should be filed as a separate bug

 * all five lines say "Normal text." in 36px Verdana bold italic.

 * Linux, mozilla, 2000-03-15-09-M15

This is spun off bug 1044.
Attached file testcase described in bug (obsolete) —
Keywords: css1, css2
Wouldn't you know it... The decision point for table inheritance quirks is in 
StyleContextImpl::RemapStyle(...) and there is no element tag to be found. The 
element tag would have to be propogated through several interfaces to make it 
into the RemapStyle routine. Ugh - it's never easy.
There is another solution.

Instead of using propagating the tag name all the way down to the style
reolution code, we could just use a different "display" keyword. So ua.css would
say something like:

   table { display: -moz-table; }

...and then only elements that have display set to the moz keyword "-moz-table"
would trigger our quirky inheritance rules -- "display:table" and (once
implemented) "display: inline-table" would use normal inheritance rules.

Would that work?

(Of course, even elements marked -moz-table should use normal inheritance rules
in standard mode.)

[pierre: I'm cc'ing you since this suggestion affects your code.]
OS: Linux → All
Hardware: PC → All
Ian, your idea is a good one, but I worry we are just pushing the problem off on 
another display type. 

If we use display:-moz-table in ua.css and we implement the quirk for that 
display type, then of course any other element given display:-moz-table would 
get the quirk. I don't really know why anyone would use display:-moz-table in a 
style rule, but then I don't know why they would use display:table either.

There is probably code that relies on a table's display being 'table' too, and 
that would break. I am thinking of the model where content is hidden and 
displayed by switching the display from 'none' to 'table'...

Also, I am leary of adding more complexity for this quirk. Adding another 
display type and having to check for that in the code seems like it will be more 
confusing and error prone. I think I would rather just mark this WONTFIX and 
keep things simple than add the extra complexity. Maybe I would have a different 
opinion if I understood why authors change the display type and under what 
circumstances - sounds like a good topic for the style ng.
Hmm. All good points. What about a new property, "-moz-inheritance", which takes
the values "-moz-silly-backwards-compatible-and-broken" or "-moz-correct"?

That would not clash with existing scripts. You could then change the behaviour
to simply use the old inheritance if "-moz-inheritance" is set to "-moz-silly-
backwards-compatible-and-broken" and quirks mode is enabled, and do everything 
correctly for all other cases.

Then in ua.css, only set this property once, on TABLE.

I'm assuming that properties are available in RemapStyle()...

I wouldn't mark this bug WONTFIX, though, as there is no reason for us to
_INTRODUCE_ new quirks in quirks mode, which is effectively what this is about.
Adding a new property will increase the size of the StyleContext and that is 
something we are currently trying to reduce... I guess we could probably steal 
an unused bit from an existing property and avoid bloating the context, but it 
is still a pretty involved change - it is a lot of code to go over. Yet another 
very creative idea, though.

I don't think we have introduced a new quirk. Neither Nav4 nor IE5 appear to 
support changing the display type of an element (at least not the combinations I 
tried). In Mozilla we sometimes support it. My understanding is that when Nav 
doesn't support something at all it is up to us to decide how to do it in 
Standard and Quirk mode. (To really be Nav-compatible I think we should actually 
*ignore* the style rules that attempt to change the display type, since that is 
what Nav does.)

Though I am no expert in 'when to quirk and when not to quirk', it appears that 
we generally use Quirk behavior when it is needed to properly render existing 
pages. I think that this is not the case here, since changing a display type 
never worked in Nav or IE it is very unlikely anybody is relying on it working 
any particular way (except possibly *not* working, in which case we fail the 
compatibility test unless we ignore the display rule).
NavQuirks mode is not about being Nav-compatible.  If it were, we could just
continue releasing from the 4.x codebase.  It's about being quirky only when the
quirks are needed for existing web pages, but still having all the new features
(since most web pages today will trigger quirks mode).

I think Ian's idea for a new property is a good one... and I somehow suspect it
wouldn't be all that much work...
Is this causing issues with existing web pages anywhere? 

That information would really help me to understand how important this is to 
fix. I have never seen any pages where the display type of an element is 
explicitly set to table in document with a transitional doctype. Not that I've 
seen every page on the web, mind you... just most of them ;)
No, but IMO quirks should be kept to the cases where they are needed.
Keywords: css1
It's economics: spending time on that change means we don't spend time on 
another. We must prioritize effectively or risk releasing a product with the 
wrong set of features.

Reducing priority and providing target milestone.
Priority: P3 → P5
Target Milestone: --- → M20
This bug has been marked "future" because we have determined that it is not 
critical for netscape 6.0. If you feel this is an error, or if it blocks your 
work in some way -- please attach your concern to the bug for reconsideration.
Target Milestone: M20 → Future
Assigning to self.
Assignee: attinasi → dbaron
Never mind... restoring original state.
Assignee: dbaron → attinasi
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...
QA Contact: chrisd → ian
QA Contact: ian → amar
Taking those of attinasi's style system bugs that are really style system bugs
and still look valid.
Assignee: attinasi → dbaron
Priority: P5 → P2
At this point the quirk is based only on tagname, not on display (see
quirk.css).  So the testcase is still broken, but now it's the
tables-that-are-blocks that show the wrong behavior...
Assignee: dbaron → nobody
QA Contact: amar → style-system
Attached file testcase described in bug (obsolete) —
Previous testcase had a missing ".
Attachment #6567 - Attachment is obsolete: true
Attached file better testcase
Attachment #370207 - Attachment is obsolete: true
Summary: table inheritance quirks should depend on both tag and display → table inheritance quirks should depend on tag name
So the point of this bug report was that the quirk should depend on the tag name; we now do that, and in so doing interoperate with WebKit and Opera.  (IE matched the old behavior, though.)

I've slightly retitled the bug, and I'm going to mark it as fixed by bug 78695 (the rule tree landing):
which removed StyleContextImpl::RemapStyle and added the rules in quirk.css .
Closed: 13 years ago
Depends on: 78695
Resolution: --- → FIXED
Target Milestone: Future → ---
You need to log in before you can comment on or make changes to this bug.