100397 - WRMB: Rendering of text within nested font element is not correct

Status: RESOLVED WORKSFORME

(Core :: DOM: HTML Parser, defect, P1)

Description

[rubydoo123]

This comes from a WRMB in bugscape: 8495

If headings contain a nested font element, the line height is not adjusted 
according to the font. Although the second part of the example is bad html, the 
headings are nested in the font element, the character height for a h6 is 
virtually unreadable.

Please see the bugscape bug for more detail. The original website exhibiting 
this problem is: http://www.caisse-epargne.fr/ASP/modele1.asp

Comment 1

[rubydoo123]

Attachment: testcase demonstarting issues with nested font element

Comment 2

[rubydoo123]

forgot to add WRMB

Comment 3

[Marc Attinasi]

Over to Alex for initial investigation

Comment 4

[Alexandru Savulov]

TESTCASE:

<font ... size="...">
<h...> text </h...>
</font>



The second part of the testcase (attachment 49817 [details]) is a quirks mode issue since
NAV/IE ignore the size= attribute (IE choses to size the font like we do for
size="3"). Unlike NAV, IE uses the size= attribute to set the height of the <h.>
elements. 

Since the size= attribute is DEPRECATED 
( see http://www.w3.org/TR/html4/present/graphics.html#edef-FONT )
i think that we should consider the case when a <font> element has a size
attribute always to be a quirk. 

Comment 5

[Alexandru Savulov]

TESTCASE:

<h...><font ... size="..."></font></h...>
The first part of the testcase (attachment 49817 [details]) is a quirks mode issue too.

Like IE we use to size the font in the same way for different size= values, but
up to the default font size for a header <h.> element we do not adapt the height
of the element to the font size (like already observed). Only when the font
height exceeds the default <h.> element height the height will be adapted.

Comment 6

[Alexandru Savulov]

Attachment: sample testcase showing the cases where we act different than IE

Comment 7

[rubydoo123]

adding bugscape ref and topembed keyword

Comment 8

[Alexandru Savulov]

As I was trying to solve the bug that originates this bug report:

              <!-- illegal markup -->
<font size=1>
 <h6>HEADER IN FONT TEST</h6>
</font>
              <!-- illegal markup -->

I found out that in the frames tree, there is  a block frame made of a <font>
element what is not allowed. This is beacuse the content does not get corrected.

Marc Attinasi is investigating the problem too.

Hold on....

Comment 9

[Marc Attinasi]

Interestingly, if the markup was made malformed as well as incorrect, like this:

<font size=1><h6>HEADER IN FONT TEST</h6>

then the Parser will fixup the content model to be sensible, something like:

<font></font><H6><font>HEADER IN FONT TEST</H6></font>

in this case we are fine because the font is inside the heading.

Harish is looking at doing this fixup even when the markup is wellformed
(instead of just when it is malformed).

BTW: the problem is not that we have to make a block frame for the FONT. The
problem is that the FONT block frame surrounding the heading establishes a new
font size, and the contained heading (H6 in this case) has a font size specified
relative to the current font. So, we get a new font-basis of 1 from eh <FONT>
tag, and then the H6 specifies that its font size is 0.67em, and that is
relative to the current font-size-basis of 1, so we get teeny tiny fonts. If the
<FONT> is moved to inside of the heading, then the font will be size 1 - still
small, but at least readable.

Comment 10

[Alexandru Savulov]

changing to assigned

AFAIK harish is already working on a fix.
(see Attinasi's previous comment)

Comment 11

[Kevin McCluskey (gone)]

From what I understand Harish is working on extending our handling of residual
style to handle this case. 

reassigning to Harish.

Comment 12

[harishd]

-> P1

Comment 13

[harishd]

Basically, residual style kicks in for non wellformed cases. So, I tried
diabling the check for wellformedness so that residual style can kick in
whenever a block level element is contained within an inline element. This
causes inline element's ( FONT ) size to be applied to the content within the
block ( H1 )element. However this contradicts bug 77352!!!. That is, when
residual style kicks in, the following markup 
<FONT SIZE="2pt">one<H1>two</H1></FONT> would become 
<FONT SIZE="10pt">one</FONT><H1><FONT SIZE="2pt" moz-rs-heading=>two</FONT><H1>.
The style rule for _moz-rs-heading should make sure that we inherit the size of
H1 and not the size of * FONT *. It looks like we force this rule for quirks
mode only. So,removing the DOCTYPE ( which is strict ) and disabling the
wellformedness check does seem to fix the problem :-). Therefore, the question
is should we consider this style rule for strict mode too?.

IMO, we should consider disabling the check for wellformedness and let it
regress in strict mode because in strict mode inline line should not contain
block and hence would require the content to be corrected.

Comment 14

[harishd]

Attachment: patch v1.0 [ In order for residual style to kick in diable the check for wellformedness in quirks mode ]

Comment 15

[harishd]

typo [ in my previous comment ]

diable/disable

Comment 16

[harishd]

Note: My patch does not try to fix up strict documents. That is, there will be
no change in behavior for testcases provided by beppe ( id=49817 ) and alexandru
( id=51765 )since the DOCTYPE used is strict and therefore would require content
fix up.

Comment 17

[Marc Attinasi]

Comment on attachment 53660 [details] [diff] [review]
patch v1.0 [ In order for residual style to kick in diable the check for wellformedness in quirks mode ]

sr=attinasi

Comment 18

[Alexandru Savulov]

r=alexsavulov

Comment 19

[harishd]

Backed out my fix to this bug since it shot up the reflow numbers & page load
time :-(

Comment 20

[Marek Z. Jeziorek]

removing topembed.
is there a chance for a fix that doesn't cause performance problems?

Comment 21

[harishd]

Marek: The fix that I backed out is the correct fix to the problem but
unfortunately with a heavy price. I can't think of an easy solution to this
problem other than fixing our frame construction code ( which I believe is a
huge task ).

Comment 22

[harishd]

Out of time :-( Moving to 0.9.7

Comment 23

[harishd]

Mark: I'm not sure what to do with this bug. Should we mark this WONTFIX?

Comment 24

[harishd]

I don't this problem will get addressed any time soon. Moving to 0.9.9.

Comment 25

[harishd]

Fixing this would mean rewriting frame construction code. I don't see it
happening in the near future.

This bug has been marked "future" because the original netscape engineer working 
on this is over-burdened. If you feel this is an error, that you or another 
known resource will be working on this bug,or if it blocks your work in some way 
-- please attach your concern to the bug for reconsideration. 

Comment 26

[rubydoo123]

removing myself from the cc list

Comment 27

[Christopher Hoess (gone)]

->Parser

Comment 28

[Henri Sivonen (:hsivonen)]

Marking this WFM because both the old and the new parser handle this sanely and the report is too vague to determine if there's a problem left.