From Bugzilla Helper: User-Agent: Mozilla/4.0 (compatible; MSIE 5.0; Windows NT) BuildID: 2001010820 Underlined words with letters that go "below the line" (p, q, j, etc.) shouldn't have underline on those letters, to enhance readability. IIRC, Macintosh Netscape 4.x did this. Reproducible: Always Steps to Reproduce: 1. Load first attachment below 2. Guess how it's spelt. 3. Give up and mouse-over the links to find out how it's spelt. Expected Results: See second attachment

confirming

Note that from a CSS point of view this does NOT violate the spec. It was even briefly discussed at the last working group face-to-face -- UAs are quite within their rights to break the underlining so as not to overwrite descenders. Marking dependency on bug 1777; we really should fix that first, but when doing so we should keep this in mind.

Mark, as a work around you might try this: a:link { font-family: verdana, arial; color: black; text-decoration: none; border-bottom : thin solid Black; font-size:12px; } And then you don't have that kind of probems!

Yep, this problem doesn't really appear on font sizes > 10px, as you can then see the below-line part of the letter. Of course, there are a myriad of workarounds, one with a seperate CSS class with the same attributes as the link, but changing the text-decoration to none, and then putting it all together as <a href="bla"><span class="nounderline">g</span>oodb<span class="nounderline">y</span>e</a>, but it'd be really cool if mozilla does this out-of-the-box :-)

Yes that would be fine Mark, but this also works for 10px, please take a look at attachment 22298 [details]. That looks exceptable to me, and to you?

Yeah, they look readable to me, but I think this not underlining the letters with decenders should be seriously considered because the default is that it's unreadable for a 10px font. Also note that H-J's example doesn't work the same as IE 5 as it does in Mozilla so many people will be unwilling to use this workaround. (IE 5 doesn't underline these links). I'll attach a screenshot showing how H-J's example is rendered in both moz (bottom) and IE (top)

In good old 4.x on Windows it just ignores the CSS rules so the last example you can't see the bits below the line either. Any idea why 4.x Mac had this feature and the Windows one didn't? Please put it in, we need it :) You've got my vote slater

H-J: great testcase. Unfortunately, next to the comments from David on how IE and Netscape 4.x handle this, I also think you can count the number of HTML writers who would actually implement this kind of work-around on one hand. As I said before, there's lots of ways to get AROUND this problem, but it'd just be nice if moz would do it WITHOUT the HTML writer having to worry about these problems. That and the fact that it would be a really neat effect :-)

First of all I do agree that this has to be implemented into Mozilla. And to be sure you all know what I mean with that testcase: Yes I do know that IE does this differently. But that's for a lot of thinks to CSS, HTML and DOM. My little testcase only shows that there's a *private* work around, that's all. And if you have difficulties while reading underlined text, as I did with it, then that you can change the CSS file used by Mozilla, so that *you* at least will see the difference. I'm not saying this is the solution for this problem. I'm only saying that this solution is my *private* solution for this specific CSS problem of Mozilla! Until Mozilla is changed I'm using this work around also on several websites. But only because I'm using MG_FastInsertStyleSheet("name.css") And this functions checks current browser version, and then inserts the pre-selected CSS. I have to do this in order to support "text readers" and other improvements for Section 508 and WAI support for specific websites!

I think this is a Mac vs. Windows thing. I believe the Mac underlines "properly", with underlines not cutting through descenders of letters, while Windows and Unix simply draw a line, even if it messes up the descender. http://www.access.ch/power/infoservices/TidBits/TidBits523.html has a note about Tasman, the IE rendering engine, not handling this properly. But it's been a while since I've used a Mac and I may just be remembering wrong.

We cannot use OS level features for underlining text because CSS has some very specific requirements for how to underline, see bug 1777. BTW: We agree there are workarounds, but could discussion regarding such go to a newsgroup like n.p.m.layout instead of adding the off-topic comments to Bugzilla? Thanks!

leave it as future

erik resign. reassign all his bug to ftang for now.

mark all future new as assigned after move from erik to ftang

This enhancemnet would be very, er, challenging,to implement if the patch for 1777 goes in. If it does, the place to do it is nsHTMLContainerFrame::PaintTextDecorationLines() and nsBlockFrame ditto. It would involve walking along the children of the frame, checking whether any characters extends below the baseline. In unicode, I might add -- so a german double s should probably break the line, too. And that's only the beginning. If the text is raised 0.1 em from the underlining, should the underline still be broken? How about 1em? 100em? Another observation: The problem with readability exist only in relative low resolution for relative small fonts. Both have a tendency to increase over time, so I'd think that the problem would go away in time. Indeed, the testcases attached presented no problem for me (1600x1200, Linux/KDE2) I suggest this be marked WONTFIX.

We'll have to implement this when we do the CSS3 Text Module, as CSS3 will most likely have a property to toggle this behaviour.

Examples in Hindi and Thai (with pictures) Bug 56881 : Underline should skip character/part-of-character that is below the base line (text-decoration-mode)

*** This bug has been marked as a duplicate of 156881 ***