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)
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)
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
patch
|
Details | Diff | Splinter Review |
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 2•24 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•24 years ago
|
||
Comment 4•24 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).
Comment 7•24 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>
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 :-/.
Assignee | ||
Comment 10•24 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•24 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•24 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•24 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•24 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•24 years ago
|
Whiteboard: desired by 05/29/01
Updated•24 years ago
|
Whiteboard: desired by 05/29/01 → needed by 05/29/01
Comment 15•23 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•23 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•23 years ago
|
||
The fix is to identify residual style tags, within heading tags, and apply
special style rules to them.
Assignee | ||
Comment 18•23 years ago
|
||
Assignee | ||
Comment 19•23 years ago
|
||
Comment 20•23 years ago
|
||
Is this ready for review?
Comment 21•23 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•23 years ago
|
||
Fix is in. Marking FIXED.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•