Closed Bug 32999 Opened 26 years ago Closed 25 years ago

NavQuirks: 'inherit' should override table inheritance quirks

Categories

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

Product:
Core
Component:
CSS Parsing and Computation
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
Future

People

(Reporter: braden, Assigned: attinasi)

References

Details

(Keywords: css2)

Attachments

(4 files)

Test case
410 bytes, text/html
Details
new testcase
199 bytes, text/html
Details
more thorough test case
535 bytes, text/html
Details
additional testcase (same as previous, but DIV instead of BODY)
569 bytes, text/html
Details
The "font-family" property is not being inherited into tables. Test case to follow.
Attached file Test case —
Style & tables: reassigned to attinasi
Assignee: pierre → attinasi
This looks like correct NavQuirks behavior. In Quirk mode we do not inherit fonts into tables because NAv4 did not. If you change the DOCTYPE to: <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3c.org/TR/html4/strict.dtd"> then you will put the browser in Standard mode and the font inherits correctly. Marking INVALID; please let me know if I am missing something else here. Thanks.
Status: NEW → RESOLVED
Closed: 26 years ago
Resolution: --- → INVALID
The DOCTYPE declaration on the test case should be functionally identical to the one you mention; I thought quirks mode was invoked for the transitional DTD? In any event, I thought the quirk you refer to only covered default behavior (arising from an implicit or explicit UA default style). Here I am quite explicitly invoking inheritance. An author who does something like I've done in this example *surely* expects inheritance. I don't think quirks mode should cover this case.
I'm not positive, but I am pretty sure that the parser requires either STRICT or XML or XHTML in the doctype to go into standard mode; since many older pages did not even use doctypes we assume NavQuirks mode for all but explicitly strict DTDs. The authoritative source is here: http://lxr.mozilla.org/seamonkey/source/htmlparser/src/nsParser.cpp#581 As for the real problem, the application of the Quirk, I think you are probably correct in suggesting that an author specifying explicit rules with inherit values probably wants non-quirk behavior. Currently we cannot distinguish between when the inheritance comes from an author-defined rule or a UA-defined rule, so it makes it extremely difficult to determine when to apply the quirk. In an ideal world we could distinguish between the two cases and honor the inheritance when the author explicitly sets it in rule, however in the real world we cannot (in all honesty we *could* but there are obvious diminishing returns on implementing Quirks, and it would be a complicated change). The result is that we implement the quirk at all times if we are in Quirk mode :(
Perhaps this bug should be re-described to deal with explicit inherit values in quirks mode, rather than being closed? On a related note, bug 31933 requests better ways of specifying/suppressing quirks mode.
Maybe I'm a little late on hopping onto this comment but I want to comment on this. I do web authoring as a hobby but I've come to learn a bit on how CSS work. And as far as this kind of "bug" goes, shouldn't the property be inherited regardless even with a TRANSITIONAL DTD set? I looked through the source code (even though I lack some of the better understanding of how it works) and I find that including the "transitional" and "frameset" as part of the quirk modes is unfair. Even when an external stylesheet is loaded that defines a default font for the entire document, CSS inheritance rule states that child elements that do not have either an attribute or property that defines otherwise default back to its parent element and eventually its UA default. So in this case, a default font is defined in the BODY element as the parent. Shouldn't the browser set the entire document's default font to that unless specified or designed otherwise?
Reopening. I think the point here was that an *explicit* 'inherit' should override the default behavior of not inheriting as a quirk.
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
Changed the summary, accepting re-opened but, but please see my comment from 2000-03-27 15:31 to understand why this may not get much traction for a while.
Status: REOPENED → ASSIGNED
Summary: font-family not inheriting into tables → font-family not inheriting into tables in Quirks mode even when explicitly set to 'inherit'
Target Milestone: --- → M20
I've read the comments on this already prior to commenting. While it's fortunate that the bug did get reopened for issues about the style inheritance, there are also other numerous factors, such as transitional DTDs using mostly what is standard and a bit of deprecated elements from HTML 4. I believe that transitional DTDs are intended to try to be as close to comformance to the strict DTD as possible, while maintaining viewability for other browsers that can at least understand the style sheet properties defined. There will be some discrepancies between other browsers that do understand HTML 4 in the long run. However, I do understand that older HTML DTDs (like 3.2) and documents w/o a DTD will default to using NavQuirks. Perhaps it should be assumed that, if there _is_ a DTD for HTML 4, that we try to use "standard" mode? Or is that just too much to ask for since a "strict" DTD is enough to set the browser into standard mode?
Please do not discuss the DTD selection code on this bug. Instead see http://bugzilla.mozilla.org/showdependencytree.cgi?id=34662 . To summarize, pages with Transitional DTD exist on the web, and some standrds are quite harsh to existing pages (see bug 5821). See also bug 34476.
Depends on: 31955
Added 31955 as depend - not really dependent, but very closely related. 'Fixing' 31955 will 'fix' this one too.
Font-Family now inherits into tables in QuirkMode. See bug 31955
Status: ASSIGNED → RESOLVED
Closed: 26 years ago → 26 years ago
Resolution: --- → FIXED
Reopening bug. This bug should apply to all the quirky table properties, not just font-family. New testcase uses 'color' property (and also uses quirks mode). (What other properties are quirky? Is font-size?)
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Summary: font-family not inheriting into tables in Quirks mode even when explicitly set to 'inherit' → NavQuirks: 'inherit' should override table inheritance quirks
With the new summary, I'm in complete agreement that this bug is still opened. Note for later: To fix this we need to track how a style value is set. Some possible flags include: - default value - implicitly inherited value - explicitly set via style rule - explicitly set to 'inherit' in rule - mapped from an HTML attribute
Status: REOPENED → ASSIGNED
That sounds awfully complicated. Somehow, I'd think it would just involve implementing the quirk differently. Also, note that it might be possible to implement the quirk differently using the quirks-mode ua.css.
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
Hmmm... this would be good to fix for NS6. I've seen lots of complaints about the table inheritance quirks (and not that much support for them), and it would be good if we could say, "here's a CSS rule that will turn them off, so you don't have to use strict mode". But then again, encouraging people to use strict mode is a good thing.
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
FIXED by Hyatt's checkin on 2001-05-31 (see changes to nsStyleContext::RemapStyle) Tested on Mozilla nightly (id: 2001060308) on Windows 2000 and on a Linux build from source pulled early this week
Status: ASSIGNED → RESOLVED
Closed: 26 years ago → 25 years ago
OS: Linux → All
Hardware: PC → All
Resolution: --- → FIXED
v
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: