31971 - table inheritance quirks should depend on tag name

Status: RESOLVED FIXED

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

Description

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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).

STEPS TO REPRODUCE:
 * load attached test case

ACTUAL RESULTS:
 * 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

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

DOES NOT WORK CORRECTLY ON:
 * Linux, mozilla, 2000-03-15-09-M15

ADDITIONAL INFORMATION:
This is spun off bug 1044.

Comment 1

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Attachment: testcase described in bug

Comment 2

[Marc Attinasi]

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.

Comment 3

[Hixie (not reading bugmail)]

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.]

Comment 4

[Marc Attinasi]

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.

Comment 5

[Hixie (not reading bugmail)]

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.

Comment 6

[Marc Attinasi]

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).

Comment 7

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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...

Comment 8

[Marc Attinasi]

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 ;)

Comment 9

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

No, but IMO quirks should be kept to the cases where they are needed.

Comment 10

[Marc Attinasi]

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.

Comment 11

[Marc Attinasi]

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.

Comment 12

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Assigning to self.

Comment 13

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Never mind... restoring original state.

Comment 14

[Hixie (not reading bugmail)]

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...

Comment 15

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Taking those of attinasi's style system bugs that are really style system bugs
and still look valid.

Comment 16

[Boris Zbarsky [:bzbarsky]]

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...

Comment 17

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Attachment: testcase described in bug

Previous testcase had a missing ".

Comment 18

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Attachment: better testcase

Comment 19

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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):
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=SeaMonkeyAll&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2001-05-31+15%3A15&maxdate=2001-05-31+15%3A20&cvsroot=%2Fcvsroot
which removed StyleContextImpl::RemapStyle and added the rules in quirk.css .