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)
Core
CSS Parsing and Computation
Tracking
()
RESOLVED
FIXED
People
(Reporter: dbaron, Unassigned)
References
Details
(Keywords: css2)
Attachments
(1 file, 2 obsolete files)
(deleted),
text/html
|
Details |
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.
Reporter | ||
Comment 1•25 years ago
|
||
Reporter | ||
Updated•25 years ago
|
Updated•25 years ago
|
Status: NEW → ASSIGNED
Comment 2•25 years ago
|
||
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•25 years ago
|
||
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
Comment 4•25 years ago
|
||
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•25 years ago
|
||
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•25 years ago
|
||
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).
Reporter | ||
Comment 7•25 years ago
|
||
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•25 years ago
|
||
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 ;)
Reporter | ||
Comment 9•25 years ago
|
||
No, but IMO quirks should be kept to the cases where they are needed.
Keywords: css1
Comment 10•25 years ago
|
||
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
Comment 11•24 years ago
|
||
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
Reporter | ||
Comment 12•24 years ago
|
||
Assigning to self.
Assignee: attinasi → dbaron
Status: ASSIGNED → NEW
Reporter | ||
Comment 13•24 years ago
|
||
Never mind... restoring original state.
Assignee: dbaron → attinasi
Reporter | ||
Updated•24 years ago
|
Status: NEW → ASSIGNED
Comment 14•24 years ago
|
||
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
Updated•24 years ago
|
QA Contact: ian → amar
Reporter | ||
Comment 15•22 years ago
|
||
Taking those of attinasi's style system bugs that are really style system bugs
and still look valid.
Assignee: attinasi → dbaron
Status: ASSIGNED → NEW
Reporter | ||
Updated•22 years ago
|
Status: NEW → ASSIGNED
Priority: P5 → P2
Comment 16•22 years ago
|
||
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...
Reporter | ||
Updated•17 years ago
|
Assignee: dbaron → nobody
Status: ASSIGNED → NEW
QA Contact: amar → style-system
Reporter | ||
Comment 17•16 years ago
|
||
Previous testcase had a missing ".
Attachment #6567 -
Attachment is obsolete: true
Reporter | ||
Comment 18•16 years ago
|
||
Attachment #370207 -
Attachment is obsolete: true
Reporter | ||
Updated•16 years ago
|
Summary: table inheritance quirks should depend on both tag and display → table inheritance quirks should depend on tag name
Reporter | ||
Comment 19•16 years ago
|
||
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.
Description
•