Closed Bug 572713 Opened 14 years ago Closed 14 years ago

On hover text gets underlined

Categories

(Core :: Layout, defect, P3)

Product:
Core
Component:
Layout
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla2.0b8
Tracking Flags:
Tracking Status
blocking2.0 --- betaN+

People

(Reporter: martijn.martijn, Assigned: dbaron)

References

(
URL
)

Details

(Keywords: regression, testcase)

Attachments

(9 files, 4 obsolete files)

testcase
219 bytes, text/html
Details
additional testcases
457 bytes, application/xhtml+xml
Details
more HTML testcases, standards mode
706 bytes, text/html; charset=UTF-8
Details
more HTML testcases, quirks mode
689 bytes, text/html; charset=UTF-8
Details
less-related testcases, standards mode
995 bytes, text/html; charset=UTF-8
Details
less-related testcases, quirks mode
979 bytes, text/html; charset=UTF-8
Details
more quirks mode table cases
1.14 KB, text/html; charset=UTF-8
Details
quirks mode which-table-element testcases
634 bytes, text/html; charset=UTF-8
Details
patch
16.08 KB, patch
roc
: review+
Details | Diff | Splinter Review
Attached file testcase — 
On the url, when hovering over the text, it gets underlined. This doesn't happen on branch builds, because the parser terminates the <a>-tag directly.
This doesn't happen anymore with the new html5 parser. IE and Google Chrome also don't seem to do this, but they don't underline the text either, so perhaps Mozilla should have some default css rule to prevent text inside tables to get underlined when the table is also inside an anchor?
There are a bunch of competing issues in this testcase:  parsing, block-within-inline handling, and the rules for propagation of text-decoration.  We have some known bugs with the last, but I don't remember exactly what the spec says for text-decoration rules.
The same parses the same way in Minefield and Chrome beta channel.
This bug is quirksmode only.

Request blocking because it affects Ebay forums (bug 601425). I saw it on other sites as well.
blocking2.0: --- → ?
> This bug is quirksmode only.

Yes, see the "text-decoration" part of comment 1.
Assignee: nobody → dbaron
blocking2.0: ? → betaN+
According to the (still member confidential, unfortunately) editor's draft of CSS 2.1, our text-decoration behavior here is correct.
The text in question in the editor's draft is the first bit of:
http://lists.w3.org/Archives/Public/www-style/2010Aug/0334.html
Then again, Chromium has too much underlining on these tests (whereas we have too little):
http://test.csswg.org/suites/css2.1/20101001/xhtml1/text-decoration-086.xht
http://test.csswg.org/suites/css2.1/20101001/xhtml1/text-decoration-088.xht
http://test.csswg.org/suites/css2.1/20101001/html4/text-decoration-086.htm
http://test.csswg.org/suites/css2.1/20101001/html4/text-decoration-088.htm
but still doesn't underline the text in attachment 451971 [details].

However, the actual relevant difference in our text-decoration behavior isn't the handling of inlines, it's the handling of tables.  Chromium doesn't propagate text-decorations into a table from anything (block or inline) outside of it; we do (as I *think* is required by the spec).
(And I'd note the CSS 2.1 test suite has no tests testing propagation into tables.)
Blocks: 610454
based on attachment 491738 [details] and attachment 491739 [details]:

Differences between mozilla-central and Firefox 3.6:
 * propagation of standards-mode text-decoration from blocks to tables (we now underline)
 * parsing of <a> without an </a> (quirky handling removed)

Differences between mozilla-central and Chromium:
 * propagation of standards-mode text-decoration from blocks to tables (we underline)
 * propagation of quirks-mode text-decoration from blocks and inlines to tables (we underline)

Differences between mozilla-central and Opera:
 * propagation of standards-mode text-decoration from inlines to tables (they underline)
 * propagation of quirks-mode text-decoration from blocks and inlines to tables (we underline)

I'd like to test IE7, IE8, and IE9, but given what I know so far, I think Opera's behavior is the most sensible, and we should make our quirks-mode text-decoration handling more quirky and (perhaps not in this bug) our standards-mode text-decoration handling follow the spec.
It looks like IE8 matches Opera (I'd need to double-check the standards-mode case, but I'm pretty sure I'm remembering the quirks-mode case correctly).
However, the original URL for the testcases for this bug and bug 562039 are in standards mode.

That said, the eBay forums (bug 601425) are in quirks mode; they're probably the most important to fix.
That said, I don't see any problems on the two pages that are in standards mode (http://www.netwerknotarissen.nl/page.asp?id=10722&menu=8&kid=2 and http://www.camino.pl/ ).
I have a patch, but want to write additional tests.

I'm planning to make two changes:
 * don't propagate quirks-mode text-decoration across HTML table elements, to fix this bug (and compat with WebKit (mostly, though it also does the same for display:table) and IE)
 * don't propagate quirks-mode text-decoration across inline-block and inline-table, to match spec and WebKit

I'm also setting up the quirks-mode code to be usable for all modes.  This means that I make the first of the above two fixes conditioned on quirks mode but the second apply to all modes, and additionally add a standards-mode check for floating and abs-pos to match the spec's propagation rules.
Attached patch patch — — Splinter Review 
See comment 27 for explanation.
Attachment #491983 - Flags: review?(roc)
http://hg.mozilla.org/mozilla-central/rev/4847e1cf6cf4
Status: NEW → RESOLVED
Closed: 14 years ago
OS: Windows 7 → All
Priority: -- → P3
Hardware: x86 → All
Resolution: --- → FIXED
Target Milestone: --- → mozilla2.0b8
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: