Open Bug 712875 Opened 13 years ago Updated 2 years ago

[quirks mode] link containing only superscript, alone on line, has text decoration well below the line

Categories

(Core :: Layout: Block and Inline, defect)

defect

Tracking

()

People

(Reporter: t.crewson, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: regression, testcase)

Attachments

(4 files)

User Agent: Mozilla/5.0 (Windows NT 5.1) AppleWebKit/535.7 (KHTML, like Gecko) Chrome/16.0.912.63 Safari/535.7

Steps to reproduce:

Viewed pages like http://www.gedhtree.com/welkmayn/gtp0.htm.


Actual results:

Firefox as-of V. 8 and 9 drops the underline of the superscript links down by a half line.  Firefox 8 renders superscripted links wrong:  Links containing text that is superscripted  (<A HREF=...><SUP>...</SUP></A>) now have the underline dropped down a half line, making the pages unreadable. This differs from previous versions and all other browsers, destroys webpages. 


Expected results:

Firefox should keep the underline where it was in V. 7 and previous, and all other browsers - IE, Chrome and K-Meleon.
> and all other browsers - IE, Chrome and K-Meleon

Opera behaves like Firefox. 

Please note that this site is in quiksmode.
If you add <!DOCTYPE html> on top you trigger standards mode and browser behaviour aligns.

This is most likly caused by bug 403524 (implement CSS2.1 text-decoration rules for both quirks and standards modes) ans therfor invalid.
Blocks: 403524
Component: General → Layout: Block and Inline
OS: Windows XP → All
Product: Firefox → Core
QA Contact: general → layout.block-and-inline
Hardware: x86 → All
Yeah, this is the weird interaction of having an underline outside of a superscript in the quirks mode inline box model combined with placing the text-decorations correctly.

We could perhaps reduce the inline box model quirk by disabling it for elements that have text decorations.
Keywords: regression
Summary: FF8 & FF9 drop-down the underline of superscripted links. → [quirks mode] link containing only superscript, alone on line, has text decoration well below the line
I'm unfamiliar with Firefox bugfix procedures.  Will this be fixed in next or future FF version?
Status: UNCONFIRMED means it isn't even clear whether that's a bug at all or an acceptable side effect of fixing bug 403524. It's on David Baron to evaluate this.
Presto browsers (Opera) have the same behaviour in quirks mode.

The reported HTML file is in "quirks mode". Web authors should no use quirks mode o avoid different rendering in different browsers.

See  https://developer.mozilla.org/en/Mozilla_Quirks_Mode_Behavior

See comment 1 how to trigger HTML "standards mode". This reduces browser differences to a very minimum.
Keywords: testcase
Version: 8 Branch → Trunk
I can't tell what change is required.  The bug has now been present in versions 8 through 13.  The <!DOCTYPE html> just destroys the webpage further.  Firefox must be fixed to render the page equal to IE and Chrome, or must go the route of Opera - proud, standard and useless.
Status: UNCONFIRMED → NEW
Ever confirmed: true
It's also possible the right fix is to disable the quirk for the parent of a superscript/subscript.
Also, as far as workarounds for the page:  don't use <sup> at all.  Because you're in quirks mode and there's no other text it's basically not making a superscript, it's only making the text a little smaller (which you could do without using <sup>).

But in general, discussing workarounds for the page here makes it harder for us to discuss how to fix Firefox, and this is where we do that.
(In reply to David Baron [:dbaron] from comment #8)
> It's also possible the right fix is to disable the quirk for the parent of a
> superscript/subscript.

Based on testing other browsers, I think this is the correct fix.
(In reply to David Baron [:dbaron] from comment #12)
> (In reply to David Baron [:dbaron] from comment #8)
> > It's also possible the right fix is to disable the quirk for the parent of a
> > superscript/subscript.
> 
> Based on testing other browsers, I think this is the correct fix.

Actually, I think what Chrome does is not this, but instead more like bug 15428... except that it doesn't have bug 15428.
I guess the desired behavior is that the quirky behavior is to use min(font size, the largest font size of any descendant) rather than ignoring the metrics when we trigger the quirk.
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: