Closed Bug 31971 Opened 25 years ago Closed 16 years ago

table inheritance quirks should depend on tag name

Categories

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

defect

Tracking

()

RESOLVED FIXED

People

(Reporter: dbaron, Unassigned)

References

Details

(Keywords: css2)

Attachments

(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). 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.
Attached file testcase described in bug (obsolete) (deleted) —
Keywords: css1, css2
Status: NEW → ASSIGNED
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
Status: ASSIGNED → NEW
Never mind... restoring original state.
Assignee: dbaron → attinasi
Status: NEW → ASSIGNED
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
Status: ASSIGNED → NEW
Status: NEW → ASSIGNED
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
Status: ASSIGNED → NEW
QA Contact: amar → style-system
Attached file testcase described in bug (obsolete) (deleted) —
Previous testcase had a missing ".
Attachment #6567 - Attachment is obsolete: true
Attached file better testcase (deleted) —
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): 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 .
Status: NEW → RESOLVED
Closed: 16 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.

Attachment

General

Created:
Updated:
Size: