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

Status: VERIFIED WONTFIX

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

Description

[Pierre Saslawsky]

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.

Comment 1

[Marc Attinasi]

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.

Comment 2

[Hixie (not reading bugmail)]

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.

Comment 3

[Marc Attinasi]

Check bug 66578 when this is fixed - Composer has been hacked until this is 
right.

Comment 4

[Marc Attinasi]

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:

http://lists.w3.org/Archives/Member/w3c-css-wg/2000OctDec/0215.html

otherwise trust that they are 'HyperLink, HyperlinkText, HyperlinkBorder' and 
'VisitedHyperLink, VisitedHyperLinkText, VisitedHyperLinkBorder' - of course, 
these may change...

Comment 5

[Hixie (not reading bugmail)]

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...

Comment 6

[Marc Attinasi]

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...

Comment 7

[karnaze (gone)]

Reassigning to glazman.

Comment 8

[Kevin McCluskey (gone)]

Moving from Moz1.0 to future-P1.  All bugs scheduled for Moz1.0 need to
nominated using the nsbeta1 keyword.

Comment 9

[Kathleen :Brade]

carryover EDITORBASE and nsbeta1 from dependent bug 57757

Comment 10

[Hixie (not reading bugmail)]

The CSS3 colour module has the required colour keywords (because of his bug).

Comment 11

[Syd Logan]

Minusing because 57757 was made EDITORBASE-

Comment 12

[Syd Logan]

Daniel, could you tell us how much work is involved with this?

Comment 13

[Daniel Glazman (:glazou) (not active in Mozilla any more)]

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.

Comment 14

[Daniel Glazman (:glazou) (not active in Mozilla any more)]

Trivial fix coming ; stay tuned.

Comment 15

[Daniel Glazman (:glazou) (not active in Mozilla any more)]

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 ?

Comment 16

[Daniel Glazman (:glazou) (not active in Mozilla any more)]

Attachment: patch v1.0 code part

Trivial implementation of HyperlinkText and VisitedHyperlinkText color names
from
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 ?

Comment 17

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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)?

Comment 18

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

/me reads.  Never mind.  (But do you think the color module is stable enough?)

Comment 19

[Hixie (not reading bugmail)]

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

Comment 20

[Akkana Peck]

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
browser.visited_color?

Comment 21

[Daniel Glazman (:glazou) (not active in Mozilla any more)]

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
http://www.w3.org/TR/css3-color/ :

  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
  means....

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
document.

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

Comment 22

[Hixie (not reading bugmail)]

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.

Comment 23

[Akkana Peck]

> 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).

Comment 24

[Madhur Bhatia]

cc'ing myself

Comment 25

[Kevin McCluskey (gone)]

nsbeta1-. Not a "stop ship" bug

Comment 26

[Noah Sager]

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.

Comment 27

[Daniel Glazman (:glazou) (not active in Mozilla any more)]

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 ?

Comment 28

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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.)

Comment 29

[Daniel Glazman (:glazou) (not active in Mozilla any more)]

WONTFIX as per of comment 28.

Comment 30

[rubydoo123]

verify