The default bug view has changed. See this FAQ.

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

VERIFIED FIXED in mozilla0.9.1

Status

()

Core
Layout
VERIFIED FIXED
16 years ago
16 years ago

People

(Reporter: Michael Dunn, Assigned: harishd)

Tracking

Trunk
mozilla0.9.1
x86
Windows NT
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

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

Attachments

(3 attachments)

(Reporter)

Description

16 years ago
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>
(Assignee)

Updated

16 years ago
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla0.9.1
(Assignee)

Comment 1

16 years ago
CCing Mark Attinasi.

Comment 2

16 years ago
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?

Comment 3

16 years ago
Created attachment 32344 [details] [diff] [review]
Proof of concept testcase: attribute on generated style tags and style rules can fix the residual style problem

Comment 4

16 years ago
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).
(Assignee)

Comment 5

16 years ago
yup, the fix up looks correct.
(Assignee)

Comment 6

16 years ago
Marc: Will the content model include MOZRS attribute?

Comment 7

16 years ago
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>
(Assignee)

Comment 8

16 years ago
Marc: I understand that MOZRS was mentioned only for testing :-). We should
probably use something like _moz-residualstyle.
(Assignee)

Comment 9

16 years ago
Marc: IMO, any other approach to notify the style system about residual style
fixups would be cumbersome :-/.  
(Assignee)

Comment 10

16 years ago
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?

Comment 11

16 years ago
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...
(Assignee)

Comment 12

16 years ago
List of residual style tags:

A,B,BDO,BIG,BLINK,DEL,FONT,I,INS,Q,S,SMALL,STRIKE,SUB,SUP,TT,U.     

 

Comment 13

16 years ago
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...

Comment 14

16 years ago
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.

Updated

16 years ago
Blocks: 75664

Updated

16 years ago
Whiteboard: desired by 05/29/01

Updated

16 years ago
Whiteboard: desired by 05/29/01 → needed by 05/29/01

Comment 15

16 years ago
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
(Assignee)

Comment 16

16 years ago
Marek: Marc & I have a solution in mind. Marc has the layout fix and I will come
up with the parser side fix soon...
(Assignee)

Comment 17

16 years ago
The fix is to identify residual style tags, within heading tags, and apply
special style rules to them.
(Assignee)

Comment 18

16 years ago
Created attachment 34078 [details] [diff] [review]
Patch v1.1 [ Note: This is not the final patch ]
(Assignee)

Comment 19

16 years ago
Created attachment 34136 [details] [diff] [review]
patch v1.2 [ includes changes to quirks.css ]

Comment 20

16 years ago
Is this ready for review?

Comment 21

16 years ago
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
(Assignee)

Comment 22

16 years ago
Fix is in. Marking FIXED.
Status: ASSIGNED → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → FIXED

Comment 23

16 years ago
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.