1.59 KB, text/html
1.83 KB, text/html
patch v1.0 [ In order for residual style to kick in diable the check for wellformedness in quirks mode ]
707 bytes, patch
Alexandru Savulov: review+
Marc Attinasi: superreview+
|Details | Diff | Splinter Review|
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
forgot to add WRMB
Severity: normal → major
Summary: Rendering of text within nested font element is not correct → WRMB: Rendering of text within nested font element is not correct
Over to Alex for initial investigation
Assignee: attinasi → alexsavulov
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.
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.
adding bugscape ref and topembed keyword
Whiteboard: [bugscape: 8495]
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....
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.
changing to assigned AFAIK harish is already working on a fix. (see Attinasi's previous comment)
Status: NEW → ASSIGNED
From what I understand Harish is working on extending our handling of residual style to handle this case. reassigning to Harish.
Assignee: alexsavulov → harishd
Status: ASSIGNED → NEW
Status: NEW → ASSIGNED
Priority: -- → P1
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.
Created attachment 53660 [details] [diff] [review] patch v1.0 [ In order for residual style to kick in diable the check for wellformedness in quirks mode ]
typo [ in my previous comment ] diable/disable
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.
Whiteboard: [bugscape: 8495] → [bugscape: 8495][fix in hand]
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
Attachment #53660 - Flags: superreview+
Backed out my fix to this bug since it shot up the reflow numbers & page load time :-(
removing topembed. is there a chance for a fix that doesn't cause performance problems?
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 ).
Out of time :-( Moving to 0.9.7
Target Milestone: mozilla0.9.6 → mozilla0.9.7
Mark: I'm not sure what to do with this bug. Should we mark this WONTFIX?
I don't this problem will get addressed any time soon. Moving to 0.9.9.
Target Milestone: mozilla0.9.7 → mozilla0.9.9
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.
Target Milestone: mozilla0.9.9 → Future
removing myself from the cc list
Status: ASSIGNED → NEW
Component: Layout → Parser
QA Contact: petersen → moied
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.
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.