Closed Bug 77352 Opened 24 years ago Closed 23 years ago

Current font styles override the default header tag (<h1>,<h2>, etc.) styles

Categories

(Core :: Layout, defect)

x86
Windows NT
defect
Not set
normal

Tracking

()

VERIFIED FIXED
mozilla0.9.1

People

(Reporter: dunn5557, Assigned: harishd)

References

Details

(Whiteboard: needed only in 0.9.1 by 05/22/01)

Attachments

(3 files)

Current font styles override the default header tag (<h1>,<h2>, etc.) styles <html><body> <H1>This is Paragraph header 1</H1> <H2>This is Paragraph header 2</H2> <H3>This is Paragraph header 3</H3> <H4>This is Paragraph header 4</H4> <HR> <p> The four lines below should appear exactly as the four lines above <p> Which they do in Netscape 4.x and IE <HR> <FONT size=2 PTSIZE="10"> <H1>This is Paragraph header 1</H1> <H2>This is Paragraph header 2</H2> <H3>This is Paragraph header 3</H3> <H4>This is Paragraph header 4</H4> <HR> <p> --Example 2-- <FONT size=2 PTSIZE="10"> <H1>This is Paragraph header 1</H1> <H2>This is Paragraph header 2</H2> </FONT> <H3>This is Paragraph header 3</H3> <H4>This is Paragraph header 4</H4> <p> <HR> The result is that EACH of headers is displayed in a different size. This is the expected result. But what it confirms for us is that, under ideal circumstances, the headers ARE ignoring the font tag (were they not, the first two headers would both be the same size (ptsize="10")). I suspect the problem has to do with how the parser is terminating tags that are not properly terminated. If you view the "inner html" of the first example above (the results of having parsed the source html into the DOM), you will actually find the following: <HR> <p> --Example 3-- <font size="2" ptsize="10"></font> <h1><font size="2" ptsize="10">This is Paragraph header 1</font></h1> <h2><font size="2" ptsize="10">This is Paragraph header 2</font></h2> <h3><font size="2" ptsize="10">This is Paragraph header 3</font></h3> <h4><font size="2" ptsize="10">This is Paragraph header 4</font></h4> </body> </html> <HR> Testcase with color: <HR> <html><body> <FONT color=red size=2 PTSIZE="10"> <H1>This is Paragraph header 1</H1> <H2>This is Paragraph header 2</H2> <H3>This is Paragraph header 3</H3> <H4>This is Paragraph header 4</H4> </body> </html> <HR> Nav4.x and IE seem to favor the color attribute but not the size attribute! In other words, they don't seem to be predictable. <HR>
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla0.9.1
CCing Mark Attinasi.
I think we can do this with an attribute on the parser-generated style tag and some style rules. As an example I created a testcase that mimics the way residual style changes the content. Given this markup <font> <h1>...</h1> Residual style processing creates the following content model <font></font> <h1><font>...</font></h1> If the generated <font> is given a special attribute, say 'MOZRESIDUALSTYLE', then a style rule can be used to bypass the normal stylistic influence of that style tag. I'll attach a testcase that show how this works (it is limited to the FONT tag, but would need to have rules for all of the style tags that residual style can operate on). Harish, does my take on how residual style fixes up the markup seem correct? Does the testcase prove to you that we can fix this with an attribute on the generated tag and some style rules? Finally, what are all of the style tags that residual style works on?
Oh yea, I forgot to mention that if you remove the style rule from the attached testcase you get the old behavior (i.e. the size for the H1 is overridden by the FONT).
yup, the fix up looks correct.
Marc: Will the content model include MOZRS attribute?
Harish, I don't recommend that attribute name (MOZRS) - it was just a test. I don't know if we can create an attribute that is not visible to the DOM but is visible to CSS - I think not. So, yes, the attribute would have to be part of the content model. Is that OK? I know that exposing the attribute is not ideal, but if we give it an appropriatly proprietary-sounding name, lke 'mozResidualStyleTag', maybe it is OK? I hope so anyway, it is an easy and low-risk way to solve this problem. <history> Rick G., Pierre, and I had discussed another approach a 16 months ago that involved the parser notifying the style system when a residual style fixup happened. The style system would then generate special style rules to 'undo' the fixup's style impacts. Pierre thought that this was unnecessary and didn't want to do it, and I was just too green to know how important it was. </history>
Marc: I understand that MOZRS was mentioned only for testing :-). We should probably use something like _moz-residualstyle.
Marc: IMO, any other approach to notify the style system about residual style fixups would be cumbersome :-/.
Marc: I think the parser changes should happen after the layout changes since it would be a lot easier to test the parser with the layout changes. Should I assign this bug to you for now?
Sure Harish. My end wil be quick and easy, but I need the list of TAGS that you apply residual style fixups to so I can create the style rules...
List of residual style tags: A,B,BDO,BIG,BLINK,DEL,FONT,I,INS,Q,S,SMALL,STRIKE,SUB,SUP,TT,U.
That is a lot of tags - maybe it is better to just apply the rule to all tags that have the new attribute. I'd hate to degrade performance by adding 17 new rules with attributes...
New rules for QUIRK.CSS to cause residual-style generated content nodes to take their style attributes from their parent instead of applying their own. These rules will just be appended to the quirk.css file /* rules to handle residual style fixups made by parser: see bug 77352 */ *[_moz-residualstyle] { font-style: inherit; font-variant: inherit; font-weight: inherit; font-size: inherit; font-family: inherit; text-decoration: inherit; vertical-align: inherit; } I think these cover the style properties introduced by the style tags listed.
Blocks: 75664
Whiteboard: desired by 05/29/01
Whiteboard: desired by 05/29/01 → needed by 05/29/01
I'm not sure where this bug is right now. It appears that we have something in progress, but I don't see clear resolution. The bug states needed by 5/29 but effectively we need this (if it makes sense and can be done) by code freeze of 0.9.1 -- 22/May/01.
Whiteboard: needed by 05/29/01 → needed only in 0.9.1 by 05/22/01
Marek: Marc & I have a solution in mind. Marc has the layout fix and I will come up with the parser side fix soon...
The fix is to identify residual style tags, within heading tags, and apply special style rules to them.
Is this ready for review?
We need a comment for the quirks.css change too - please follow the comment style that already exists in the file, and with that sr=attinasi
Fix is in. Marking FIXED.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Marking verified in the May 30th build.
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: