Last Comment Bug 77352 - Current font styles override the default header tag (<h1>,<h2>, etc.) styles
: Current font styles override the default header tag (<h1>,<h2>, etc.) styles
Status: VERIFIED FIXED
needed only in 0.9.1 by 05/22/01
:
Product: Core
Classification: Components
Component: Layout (show other bugs)
: Trunk
: x86 Windows NT
: -- normal (vote)
: mozilla0.9.1
Assigned To: harishd
: Chris Petersen
: Jet Villegas (:jet)
Mentors:
Depends on:
Blocks: 75664
  Show dependency treegraph
 
Reported: 2001-04-24 09:29 PDT by Michael Dunn
Modified: 2001-05-31 13:47 PDT (History)
3 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Proof of concept testcase: attribute on generated style tags and style rules can fix the residual style problem (386 bytes, patch)
2001-04-26 15:34 PDT, Marc Attinasi
no flags Details | Diff | Splinter Review
Patch v1.1 [ Note: This is not the final patch ] (4.16 KB, patch)
2001-05-11 10:08 PDT, harishd
no flags Details | Diff | Splinter Review
patch v1.2 [ includes changes to quirks.css ] (4.05 KB, patch)
2001-05-11 15:44 PDT, harishd
no flags Details | Diff | Splinter Review

Description Michael Dunn 2001-04-24 09:29:12 PDT
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>
Comment 1 harishd 2001-04-25 10:28:48 PDT
CCing Mark Attinasi.
Comment 2 Marc Attinasi 2001-04-26 15:32:54 PDT
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 Marc Attinasi 2001-04-26 15:34:33 PDT
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 Marc Attinasi 2001-04-26 15:35:34 PDT
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).
Comment 5 harishd 2001-04-26 15:45:43 PDT
yup, the fix up looks correct.
Comment 6 harishd 2001-04-26 15:48:34 PDT
Marc: Will the content model include MOZRS attribute?
Comment 7 Marc Attinasi 2001-04-26 15:56:59 PDT
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>
Comment 8 harishd 2001-04-26 16:07:15 PDT
Marc: I understand that MOZRS was mentioned only for testing :-). We should
probably use something like _moz-residualstyle.
Comment 9 harishd 2001-04-26 16:14:17 PDT
Marc: IMO, any other approach to notify the style system about residual style
fixups would be cumbersome :-/.  
Comment 10 harishd 2001-05-01 16:20:47 PDT
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 Marc Attinasi 2001-05-02 10:11:53 PDT
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...
Comment 12 harishd 2001-05-02 10:31:41 PDT
List of residual style tags:

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

 
Comment 13 Marc Attinasi 2001-05-02 10:49:00 PDT
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 Marc Attinasi 2001-05-02 14:54:58 PDT
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.
Comment 15 Marek Z. Jeziorek 2001-05-09 11:52:06 PDT
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.
Comment 16 harishd 2001-05-09 12:07:46 PDT
Marek: Marc & I have a solution in mind. Marc has the layout fix and I will come
up with the parser side fix soon...
Comment 17 harishd 2001-05-09 12:10:33 PDT
The fix is to identify residual style tags, within heading tags, and apply
special style rules to them.
Comment 18 harishd 2001-05-11 10:08:17 PDT
Created attachment 34078 [details] [diff] [review]
Patch v1.1 [ Note: This is not the final patch ]
Comment 19 harishd 2001-05-11 15:44:45 PDT
Created attachment 34136 [details] [diff] [review]
patch v1.2 [ includes changes to quirks.css ]
Comment 20 Marek Z. Jeziorek 2001-05-14 21:44:28 PDT
Is this ready for review?
Comment 21 Marc Attinasi 2001-05-15 11:56:04 PDT
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
Comment 22 harishd 2001-05-16 11:14:11 PDT
Fix is in. Marking FIXED.
Comment 23 Chris Petersen 2001-05-31 13:47:47 PDT
Marking verified in the May 30th build.

Note You need to log in before you can comment on or make changes to this bug.