This is a section 508 compliance issue. We are not supposed to rely on color alone for conveying information. We have a pref panel that has Unvisited link color: Visited Link color: Underline links? Perhaps we can add Dotted underline for visited links? Opera has a pref like that.

Well, support for this needs to come from the backend. Layout?

Changing QA contact

Support already exists on the back end. It can be done through style sheets. There is a style sheet created from the prefs in nsPresContext.cpp

Plussing, per ADT triage Need UI design for this. Lori?

Assigning to Marlon per discussion with Lori.

I have an alternative way to show visited links with a dashed underline, you can try it by adding the following line to the chrome/userContent.css file in your profile directory. *:visited, *:visited:active {border-bottom: dashed 1px !important; text-decoration: none !important;} I realize that this doesn't line up perfectly with the normal underlines, but that could be fixed by adding a -moz-dashed-underline text decoration type. Anyway, this doesn't look too bad, and it helps people who can't differentiate colors. Here's how I recommend we change the prefs panel: Unvisited Links: [color] Visited links: [color] [x] Underline all links [ ] Make the underline dashed for visited links

Marlon's comments via mail: i would have to see what it looked like using -moz-dashed-underline but i think it would be fine. Do we have control over the length of the dashes? they look too short as well, but that's a minor observation. for the pref wording try something shorter like: Unvisited Links: [color] Visited links: [color] [x] Underline all links [ ] Dashed underline for visited links

Bernie, take a look at this one. It might be a good bug for you. Try the CSS change I described and see if you like the way it looks for visited links.

Aaron, your wording seems fine. "Broken underline" is also used, though it less common.

Bernie, it's all yours. Let me know how I can help.

Changing nsbeta1+ [adt3] bugs to nsbeta1- on behalf of the adt. If you have any questions about this, please email adt@netscape.com. You can search for "changing adt3 bugs" to quickly find and delete these bug mails.

Changing nsbeta1+ [adt3] bugs to nsbeta1- on behalf of the adt. If you have any questions about this, please email adt@netscape.com. You can search for "changing adt3 bugs" to quickly find and delete these bug mails.

Here is an initial patch to see if this approach is what is desired. In summary the patch: 1. Adds a new text-decoration style -moz-dashed-underline, 2. Adds a user preference to use dashed underlines on visited links, 3. Adds drawing code (for Windows only in this patch) to draw the dashed line. (The dashed underline is drawn in the same position as an underline. ) I need some feedback on the following: 1. How does this dashed underline look, 2. My drawing code is a real hack. I need someone who knows about nsTransform2D :: TransformCoord. I need to understand the purpose of these transformations. 3. What is the code in embedding\browser\photon for? A module there PtMozilla.cpp seems to need some modifications but it's not built by the makefile.win in embedding\. Can anyone help here? 4. Does anyone know what and how gfx\src\RegressionTestFontMetrics.cpp is used for? Sounds like some testing function. How is it run? Check this patch out on Windows and I'll look at changes on other platforms.

Bernie this is a great first patch! I don't really know any of the answers to your questions, and I'm the wrong person to r= this, but you might try dbaron. Here are some comments: Your pref browser.dashed_underline_visitedlinks seems to be missing an underscore between the last 2 words. It seems like you did that on purpose but mayble it looks a little inconsistent. String nit in nsPresShell.cpp. The latest string wisdom says there is a more efficient way to append strings then Assign() and Append(): stringNew = stringA + stringB In nsPresContext.*, this is declared but does not seem to be used: + nsString mDashedUnderline; Your dashed line drawing code in nsTextFrame.cpp does seem a little hacky; I can't understand what the hard coded values are for, like 10. I would avoid using hard coded integer values. At least they should be defined in the .h or .idl files.

Thanks Aaron, Here is a revised patch with Aarons suggestions. I revised the drawing code to use a patterned brush to draw the dashed line. Please comment on how this looks and, of course, comment on the implementation if you like. Thanks

Patch looks good to me. I think this needs an r= from dbaron or someone in layout. Perhaps someone needs to r= the prefs changes as well.

After testing the patch on my system, I've decided the paintbrush method doesn't work well enough. Sure it's cleaner code, but the dashed underlines don't always look right. The paintbrush method creates an inconsistent look for the start of the underline. It would be better if there was always a full dash that always starts exactly below the first character.

After a quick look at the patch: * I don't see why you want a separate underline offset method for dashed underlines. I would think you would always want the underline at the same offset, so you could use the existing nsIFontMetrics method and avoid changing nsIFontMetrics on multiple platforms. * We have a bunch of existing dash-drawing and dot-drawing code in nsCSSRendering.cpp. You're probably much better off using that than adding new methods to nsIRenderingContext that would have to be implemented on multiple platforms. * At some point this could be converted to the CSS3 proposed 'text-underline-style' property, but probably not now (since that draft isn't stable yet).

David, Thanks for looking at the patch. I've tried using the code in nsCSSRendering.cpp for drawing dashed/dotted rects and lines but really can't get it working. I cant find (using lxr) any place these methods are used outside of nsCSSRendering. It would be helpful to see how some of this is used. Do you know of any documentation on these functions?

Bug 59109 covers implementing CSS3's text-underline properties.

I'm wondering if there's a good reason this shouldn't be the default configuration. I would think that if link underlining is enabled, visited links should just have dashed underlines. I don't see a good reason to add the pref. The improved accessibility should help everyone, even those able to distinguish colors. One possible concern with using the dashed underline for visited links is that windows help used to use that to mean a popup window tip. I checked and notice that windows help (on windows 2000) is now less accessible than it used to be: All links now use a solid underline--they just use blue for normal links and green for the popup tips. I guess it's not a big deal.

I'd like to add that this is now a bit more important than it previously was, now that users/authors cannot change anything except color in CSS, due to the way that Bug 147777 was fixed. Also consider Bug 693164, which might be a better overall solution, because the width of text underline remains too thin at all zoom levels for some users, who therefore need much more aggressive styling.

Hopefully we can fix this in a way that's invisible to scripts, so we're not reintroducing the privacy problem (bug 147777) for users who set this pref.

Re: Jesse Ruderman Comment #23 > Hopefully we can fix this in a way that's invisible to scripts, so we're not reintroducing the privacy problem (bug 147777) for users who set this pref. One way would be, for example to set a border on both normal links and visited links, with the normal link border styled to be invisible (but to still have a width). Then, allow styling the color of the border for visited links; this would have the effect of giving the links a different appearance, but their dimensions would remain the same. But this would significantly increase the logic required to determine what styles are valid, and it introduces the theoretical possibility that the rendering time would increase, making it still detectable. Another technique might be setting a content character in a native content sub-element of all links, which has no rendering in the case of links (a spacing character), but which has a rendering (say, a block or symbol) for :visited links, and is the same size in either case. It would require using a browser-overridden font (to stop authors specifying a font in which the two symbols are different sizes). Because of the way that the text subsystems cache and render glyphs, there should be no rendering speed differences detectable (at least, after the very first time a given glyph is used). As I mention in Bug 693164, and the reason that I consider that a better option (either alone, or in combination with this option), is that users who need to distinguish links other than by color probably benefit from "herd immunity" - the privacy-invading technique is so near-useless against the majority who don't change their defaults, that it won't even be deployed to catch those who do change their styles, because the gains will be too small.

Moving to p3 because no activity for at least 1 year(s). See https://github.com/mozilla/bug-handling/blob/master/policy/triage-bugzilla.md#how-do-you-triage for more information

Moving to p3 because no activity for at least 1 year(s). See https://github.com/mozilla/bug-handling/blob/master/policy/triage-bugzilla.md#how-do-you-triage for more information