quirks mode text-decoration "inherits" differently into tables in IE and Mozilla

RESOLVED FIXED in mozilla2.0b8

Status

()

Core
Layout: Text
P4
normal
RESOLVED FIXED
14 years ago
6 years ago

People

(Reporter: sicking, Assigned: dbaron)

Tracking

({testcase})

Trunk
mozilla2.0b8
testcase
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(3 attachments, 1 obsolete attachment)

In both IE and Mozilla we don't inherit certain CSS-properties into tables, such
as font-weight and font-family. IE similarly blocks text-decoration of parents
from affecting text inside tables, however mozilla does not.

Will attach a testcase
Created attachment 134723 [details]
testcase

In mozilla the top table is underlined, in IE not. Neither browser makes the
bottom table bold.
Created attachment 134726 [details]
testcase 2

This tests all other textdecorations. For the first three textdecorations,
underline, overline and line-through, IE does not apply the style inside the
tables.

IE doesn't support blinking so i guess we can do whatever we want there.
Created attachment 134727 [details]
good testcase 2

Sorry, the text in the last attachment was wrong.
Attachment #134726 - Attachment is obsolete: true
Is this a problem on any real sites to the point that we should be creating a
quirk for this?

Comment 5

14 years ago
This issue came to my team from one of our server products - WebSphere Portal
Server.

The issue was that when using the rich text editing facility of Mozilla, you get
inconsistent results between IE and Mozilla.

So for that group, this was rated as an important issue.
This issue was raised in a forum today, in quirks mode text-decoration is
inherited from body to table cells while it is not in NS4/IE/Opera. It is also
referenced as a specific mozilla bug in several places like
http://www.richinstyle.com/bugs/mozillademo.html
Please don't even bother bringing Richinstyle up in bug reports.  It's notorious
for making incorrect claims and has been unmaintained for years now.

Comment 8

11 years ago
Created attachment 262828 [details] [diff] [review]
proposed patch

Attached patch fixes this bug by stopping text-decoration from inheriting inside tables in quirks mode.  It is right next to the code that sets text color inside a table, in quirks mode, to be the body's text color (nsHTMLStyleSheet::RulesMatching), which is similar in style.

With the test case, attachment 134727 [details], this patch makes the "In Table" text not underlined, not overlined, and not struck out.  This matches IE's quirks-mode behavior.

Before this patch, it was possible for text decorations to be a different color than the text inside a table, since the text decoration drawing code would gotten it's color from the "defining" element, which could be (but shouldn't have been) outside the table.  Red text with an underline surrounding the table would result in black text with a red underline inside the table.  Pretty funky, but not actually desired.

If anyone has suggestions for better approaches to moving this information around (currently an nsCSSValue(eCSSUnit_Initial) is used, in addition to a new NS_STYLE_TEXT_DECORATION_ABORT define), I'd be happy to incorporate a better approach in the patch.
(Assignee)

Comment 9

11 years ago
So eCSSUnit_Initial means something else; it happens to not be implemented yet for text-decoration, but it should be.

I also don't think the fix should need to be this complicated, but I may not have time to come up with a better one immediately.

Comment 10

10 years ago
David, you're probably right that the fix for this doesn't need to be so complicated.

The first solution I had in mind would have been restricted to nsTextFrame::PaintTextDecorations.  If it was possible to determine the responsible element from an nsStyleContext, I would have suggested checking for a table and breaking out of the "while (hasDecorations) { ... }" loop.  But I couldn't determine a way to do that.

If you could point me in the direction that you have in mind for a simpler approach, I'd be happy to pursue it.
(Assignee)

Updated

10 years ago
Depends on: 403524
Assignee: layout.fonts-and-text → nobody
QA Contact: ian → layout.fonts-and-text
(Assignee)

Comment 11

6 years ago
This was fixed by http://hg.mozilla.org/mozilla-central/rev/4847e1cf6cf4 on bug 572713 , which added this quirk.
Assignee: nobody → dbaron
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Depends on: 572713
No longer depends on: 403524
Priority: -- → P4
Resolution: --- → FIXED
Target Milestone: --- → mozilla2.0b8
You need to log in before you can comment on or make changes to this bug.