Closed Bug 58534 Opened 20 years ago Closed 18 years ago

Put back :link and :visited rules into html.css


(Core :: CSS Parsing and Computation, defect, P1)






(Reporter: pierre, Assigned: glazou)


(Keywords: css1, css3, Whiteboard: Fix in hand, WG[CSS1-2.1] EDITORBASE+ [adt2])


(1 obsolete file)

This bug is related to bug 43040 and bug 57621.

We should put back into html.css the rules that were removed when fixing bug 
43040.  We need to keep default colors and text decorations for the link.  It 
would have prevented bug 57621.
I think we need to support a new property like -moz-pref-linkcolor and
-moz-pref-visitedcolor to do this. If we just put in the old standard 'blue' and
'purple' colors, then we will have to raise the specificity of the rule in the
pref stylesheet to override it, which is why I originally removed it.

Thanks for filing this, Pierre - accepting.
This would also fix the problem whereby links in HTML sidebar panels that have
no colouring CSS of their own do not get coloured links.

Marc: Your solution sounds good. In fact, it sounds like those colours could be
useful additions to CSS3 -- we could bring it up on the WG.
Keywords: css1, mozilla1.0
Whiteboard: WG
Keywords: css3
Blocks: 57757
Check bug 66578 when this is fixed - Composer has been hacked until this is 
According to the CSS WG, there is already a property value planned for link 
colors. If you have W3C memeber access, see 
the discussion on the list at:

otherwise trust that they are 'HyperLink, HyperlinkText, HyperlinkBorder' and 
'VisitedHyperLink, VisitedHyperLinkText, VisitedHyperLinkBorder' - of course, 
these may change...
Netscape's standard compliance QA team reorganised itself once again, so taking 
remaining non-tables style bugs. Sorry about the spam. I tried to get this done 
directly at the database level, but apparently that is "not easy because of the 
shadow db", "plus it screws up the audit trail", so no can do...
QA Contact: chrisd → ian
CC'ing Daniel. Daniel, what do you think about implementing this new set of 
property values for the link colors? I can fill you in on any of the details if 
you are interested...
Target Milestone: --- → mozilla1.0
Reassigning to glazman.
Assignee: attinasi → glazman
Moving from Moz1.0 to future-P1.  All bugs scheduled for Moz1.0 need to
nominated using the nsbeta1 keyword.
Priority: P3 → P1
Target Milestone: mozilla1.0 → Future
Whiteboard: WG → WG[CSS1-2.1]
carryover EDITORBASE and nsbeta1 from dependent bug 57757
Keywords: nsbeta1
Whiteboard: WG[CSS1-2.1] → WG[CSS1-2.1] EDITORBASE
The CSS3 colour module has the required colour keywords (because of his bug).
Minusing because 57757 was made EDITORBASE-
Keywords: nsbeta1nsbeta1-
Daniel, could you tell us how much work is involved with this?
Keywords: nsbeta1-nsbeta1+
Whiteboard: WG[CSS1-2.1] EDITORBASE → WG[CSS1-2.1] EDITORBASE+
Target Milestone: Future → mozilla1.0
Whiteboard: WG[CSS1-2.1] EDITORBASE+ → WG[CSS1-2.1] EDITORBASE+ [adt2]
Syd : strange.. I never received the bugmail going with your comment #12 :-/

Anyway... It implies implementing the HyperlinkText and VisitedHyperlinkText new
system colors from document [1].
That document is a Last Call working draft and is fairly stable. I think we
can do it w/o risk.
Working on it now.
Trivial fix coming ; stay tuned.
Akkana : fixing this bug needs very light modifications in nsXPLookAndFeel.cpp :

    both colorPrefChanged() and InitColorFromPref() call only NS_ColorNameToRGB()
    to translate a color name stored in a pref into a RGB color. But they never
    try to call NS_LooseHexToRGB(). That blocks this current bug because colors
    stored in prefs 'browser.visited_color' and 'browser.anchor_color' are 
    "#RRGGBB" strings...

    Isn't it a bug that they try to deal only with color names ? Is there any
    danger trying to also deal with "#RRGGBB" string form for colors ?
Attached patch patch v1.0 code part (obsolete) — Splinter Review
Trivial implementation of HyperlinkText and VisitedHyperlinkText color names
the CSS 3 Color Module.
This part of the fix does not include the work that has to be done on the
stylesheets themselves.

Akkana, can you please review ?
Summary: Put back :link and :visited rules into html.css → [PATCH] Put back :link and :visited rules into html.css
Whiteboard: WG[CSS1-2.1] EDITORBASE+ [adt2] → Fix in hand, WG[CSS1-2.1] EDITORBASE+ [adt2]
Could you either point to a spec that lists those keywords or add -moz- to the
beginning of them (and list them along with the other -moz- keywords, using the
same type of prefix on the variable name as well)?
/me reads.  Never mind.  (But do you think the color module is stable enough?)
color is not yet in CR -- it's not even yet in Last Call -- so please prefix the
value names with -moz-. Thanks.
The code changes look fine -- yes, adding the checks for #rrggbb color specifiers
seems like the right thing to do -- but is "look and feel" really the right
place for these browser-specific prefs?  Won't these conflict with the existing
prefs that are already used for that purpose, browser.anchor_color and
Hixie said :

> color is not yet in CR -- it's not even yet in Last Call -- so please prefix
> the value names with -moz-. Thanks.

Ian, you should read better the CSS mailing-lists... Excerpt from :

  This document is a working draft of the CSS working group which is part of the
  style activity (see summary). This is a W3C Last Call Working Draft. Last call

I don't think it makes any sense to prefix it with -moz- . Yes David, I think
this part of the document is stable enough to implement it as it is in the

Akkana : there is nothing in the OS for these color names ; these color names
are really what we call browser.visited_color and browser.anchor_color
I stand corrected. However, we really should not be implementing anything
without -moz- prefixes until the relevant spec is in CR, however stable we think
it might be. That's the whole point of the whole -vendor-prefix thing.
> Akkana : there is nothing in the OS for these color names ; these color names
> are really what we call browser.visited_color and browser.anchor_color

That's why I questioned putting them in nsLookAndFeel since we already have
browser preferences for these.  I'm not clear what the difference is between the
new look-and-feel prefs and the existing prefs, or why anyone would ever want to
make these prefs platform specific (which is basically what nsILookAndFeel is
used for).
cc'ing myself
nsbeta1-. Not a "stop ship" bug
Keywords: nsbeta1+nsbeta1-
I'm just adding some more specific info, in case. The initial viewing of pages
with the a:whatever psudo-class works as expected. But after a page has been
visited, the color and text-decoration are ignored on the link.
Attachment #83722 - Attachment is obsolete: true
I have a real problem with this bug (besides the fact it blocks 577757 which is
nsbeta1+ editorbase+) : the two pref colors for anchors and visited anchors are
used by PresShell::SetPrefLinkRules() to generate the two rules

    *:link { color: xxxxx }
    *:visited { color : yyyyy }

in the PreferenceStyleSheet.

I have a working easy patch for that, introducing the new -moz-hyperlinktext and
-moz-visitedhyperlinktext values for the color property.

**BUT** the declarations in the two rules above are made !important (or not)
depending on the pref browser.display.use_document_colors ....
And we have no real way of specifying a "dynamic" importance for a rule,
depending on a pref.

My patch this bug is still worth (and in fact important) for bug 57757. But
it does not really solve the current bug.

Opinions ?
Summary: [PATCH] Put back :link and :visited rules into html.css → Put back :link and :visited rules into html.css
I don't see any reason why this bug, as stated in comment 0, should be fixed. 
(I'd rather see those prefs moved into an additional C++ implementation of
nsIStyleSheet rather than in a pasted-together CSS stylesheet -- I think the
code would end up being a good bit simpler and more flexible.  However, that's
another issue.)
No longer blocks: 57757
WONTFIX as per of comment 28.
Closed: 18 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.