CSS Links färben: link:hover will nicht so wie ich

[TobiW]

Hi ihr

 

ihr werd hier gleich wahnsinnig … ich will gerne, dass normale links rot sind, besuchte links grau und links, über die man die Maus bewegt (auch dir bereits besuchten) sollen wieder rot werden … diesen CSS-Code versuche ich dafür zu verwenden, aber erfolglos:

a:link {
    text-decoration:none;
    color:red;
}
a:visited {
    text-decoration:none;
    color:gray;
}
a:hover {
    text-decoration:none;
    color:red;    
}

Ich habe natürlich schon gegoogelt und rausgefunden, das die Reihenfolge irgendeine Rolle spielt, aber ich meine, ich halte mich an dir richtige Reihenfolge :-/

 

Es gibt noch etwas mehr Code, der sich auf Links bezieht, nämlich der für die Navigation, die in <nav> untergebracht ist:

nav a:link, nav a:visited {
    text-decoration:none;
    color:black;
}
nav a:hover, nav a:active, nav a:visited:hover {
    color:red;
    text-decoration:none;
}
nav a.active {
    color:red;
}

Dort soll es etwas anders aussehen, funktioniert aber komischerweise sowie ich es will …

 

Sonnige osnabrücker Grüße

Tobi

[Sebastian Nagel]

Theoretisch sollte das klappen ... in der Praxis wäre rauszufinden, welche Formatierungsanweisungen sich denn auf die Links auswirken (fälschlicherweise, korrekterweise oder wider erwarten nicht), so lässt sich schnell feststellen was schiefläuft.

 

Dafür eignen sich die Browser-Entwicklerwerkzeuge wie der firefox-interne Entwickler-Panel (rechtsklick -> Element untersuchen), Plugins wie Firebug (muss aber nachgerüstet werden), oder äquivalente Werkzeuge in Google Chrome (Inspector), IE (F12-Developer Tools) etc.

 

Wenn du mir einen erreichbaren Link schickst, kann ich auch gerne nachsehen.

[TobiW]

Danke

Mit dem Chrome-Inspektor hab ich’s schon probiert, aber der zeigt mir zu :hover nix an. FF hab ich grad probiert, da funktioniert es witziger weise. Safari zeit das gleiche Verhalten wie Chrome und auch dort ist mit dem Safari-Inspektor nix zu sehen … die Seite ist bisher nicht online, wenn ich darf schicke ich dir einfach alles als ZIP, ist kein sonderlich langes Stylesheet …?

[TobiW]

Also es liegt scheinbar tatsächlich an Chrome, wie hier zu sehen, löst ein zusätzliches font-weight:500 den Bug … Offenbar reagiert Chrome nicht, wenn nur die Farbe geändert werden soll. Grundsätzlich erkennen kann er das schon, denn wenn ich über die Entwickler-Tolls den Link-Status auf :hover festlege, wir dieser rot …

[Sebastian Nagel]

tut mir leid, der Faden ist bei mir untergegangen ...

 

1x kurz durchs Internet scheint sich das so zu bestätigen:

– Farbwechsel allein reicht nicht, wenn es sich um ein Inline-Element (was ein Link normalerweise ist) handelt, und die Farbe die einzige Eigenschaft ist die geändert werden soll. Entweder also wie du sagt eine zweite Eigenschaft "ändern" (Gewicht, Stil, Unterstreichung, ...), oder aus den Links pauschal zuerst ein Block- oder Inline-Block-Element machen ( a {display:block;} bzw. a {display:inline-block;} ). Letzteres ist natürlich nicht immer wünschenswert, wobei inline-block meist wenig Schaden anrichtet.

– Es dürfte ein Webkit-Bug sein, d.h. Safari und bald Opera ist vorläufig ebenso betroffen.

[TobiW]

Danke dir. Seltsamer weise tritt das Problem nur im Haupttext auf. Im Menü und auch in der Fußzeile klappt das hovern … und in Safari geht es an allen Stellen … macht Chrome noch was neben Den Webkit-Sachen?

[Sebastian Nagel]

Chrome hat sich ja vor kurzem von Webkit abgespalten, d.h. sie entwickeln vom Webkit-Stamm weg ohne zurück zu liefern. Aber das ist eigentlich noch so wenig lang her, dass sich das noch nicht in solchen Unterschieden manifestieren dürfte ... könnte aber theoretisch sein.

 

Warum es in Menüs etc. geht:  kann es sein dass die Links dort schon block-Elemente sind? Bei Navigationen etc. ist das nicht unüblich, da sich dort ein Link ja meist wie eine "Box" verhalten soll, nicht wie Fließtext. Das ganze müsste sich bei Links im Menü mit einer Formatierung display:block, display:inline-block oder ggf. auch noch display:table-cell erkennbar machen.

Im Haupttext hingegen sind Links (standardgemäß) inline-Elemente, verhalten sich also wie Fließtext.

 

Und Webkit / Chrome scheint die beiden Anzeigemethoden (bug oder feature?) anders zu handhaben was hover-States etc. anbelangt, wodurch der Unterschied zustande kommen könnte.

[TobiW]

Eingetlich sind die Links alle gleich. Das Menü ist im Prinzip eine Liste: test.joachim-siegel.de du kannst auch gerne in Nachbarthread eine. Kommentar zur Gestaltung loswerden

http://www.typografie.info/3/topic/29306-homepage-f%C3%BCr-meinen-chorleiter-feedback-bitte/

[Alexander Bürgin]

Falls du nicht html5 verwendest hast du einfach den Selektor typ vor nav vergessen wie z.B. <.> klasse oder <#> ID

 

 

wenn das auch nicht der fall ist dann künkt es mich komisch. vieleicht ust der selektor zu schwach versucht mal:

 

 

 

body nav a:link, body nav a:visited

{ text-decoration:none; color:black; }

[TobiW]

Hi, doch ich nutze HTML5 zumindest gibt es auch nen <nav>-Tag …

 

Allerdings sind die Links in der Navigation auch nicht das Problem, da geht alles wie gewünscht, nur bei den einfach Links im Fließtext da reagieren die Links nicht auf hover, wenn sich nur die Farbe ändern soll …

[TobiW]

Ist zwar schon ein Weilchen her … aber ich hatte das Problem beiseite gelegt und stoße nun bei einer anderen Seite wieder darauf. Soweit ich das sehe, habe ich die Reihenfolge der Pseudoklassen eingehalten und die Links sind inline-blocks:

a:link {
    color: $highlight;
    text-decoration: none;
    border-bottom: 1px solid;
    display: inline-block;
}
a:visited {
    color: inherit;
}
a:hover {
    color: $highlight;
}

Allerdings geht es nach wie vor nur, wenn :hover auch eine zweite Eigenschaft ändert. Gibt es inzwischen eine Möglichkeit, das Problem zu beheben.

Wenn ich die Seite übrigens „inspiziere“ und im Inspektor von Safari einen Haken bei hover setze, ändert der Link übrigens korrekt seine Farbe …

 

BTW: Nutze ich besser a oder a:link für die „normalen“ Links?

[Þorsten]

Poste in Zukunft am besten ein minimales, aber lauffähiges, Beispiel, das das Problem reproduziert. Also z.B. sowas wie das hier:

<!DOCTYPE html>
<html lang="en">
  <head>
    <title>Testing CSS link selectors</title>
    <meta charset="utf-8" />
    <style type="text/css">
      body {
        color: green; /*something explicit to inherit*/
      }
      a:link {
        color: orange;
        text-decoration: none;
        border-bottom: 1px solid;
        border-color: fuchsia; /*so we can distinguish it from “text-decoration”*/
        display: inline-block;
      }
      a:visited {
        color: inherit;
      }
      a:hover {
        color: orange;
      }
    </style>
  </head>
  <body>
    Here be links: 
    <a href="http://www.typografie.info/3/index">visited?</a>,
    <a href="http://nonexisting.aa">unvisited?</a>.
  </body>
</html>

Dort scheint erst mal alles zu funktionieren (wenn ich denn recht verstehe, was du erreichen möchtest).

 

Nur solche Fragmente wie in deinem Beispiel zu posten, bringt oft nichts, weil das Problem durch irgendwelche Nebeneffekte verursacht wird, die so verloren gehen.

 

a:link beschreibt nur Links, die noch nicht besucht wurden. a beschreibt alle Links. Es kommt also darauf an, was du erreichen willst.

[TobiW]

Hi,
 
ich hatte gehofft, ich komme um ein MWE drum rum   aber das erstellen desselben hat zumindest insoweit geholfen, dass ich das Problem jetzt konkretisieren kann, wobei ich das eher zufällig rausgefunden habe … der :hover-Stil wird dann ignoriert, wenn die  :hover-Farbe gleich der :link-Farbe aber ungleich der :visited-Farbe ist …
 
Hier das Beispiel:
 

<!DOCTYPE html>
<html lang="de">

<head>
    <style type="text/css">
        a {
            color: red;
        }
        a:visited {
            color: inherit
        }
        a:hover {
            color: red;/* geht nicht */
            color: green;/* geht */
        }
    </style>
</head>

<body>
    <p><a href="http://www.xlihlhlkhsg.com">normaler Link</a></p>
    <p><a href="#">Besuchter Link</a></p>
</body>

</html>

 
Der Fehler (?) zeigt sich unter OS X 10.9 mit Safari, Opera und Chrome, allerdings nicht bei Firefox.
 

a:link beschreibt nur Links, die noch nicht besucht wurden. a beschreibt alle Links. Es kommt also darauf an, was du erreichen willst.

Danke, ich war nur verwundert, weil ich im Netz immer nur noch die :link-Variante lese und dachte das reine a zu nutzen wäre evtl. überholt inzwischen …

[catfonts]

Und wie wäre es, wenn die Farben nicht gleich sein dürfen, statt der benannten Farbe "red" dann den um 1/256 dunklere RGB-Farbe #fe0000; zu verwenden? Dann ist die Farbe anders, ohne dass das wirklich sichtbar ist.

[TobiW]

Ja das ginge grundsätzlich als Hack … hier aber nicht, weil ich im echten Projekt natürlich mit anderen Farben arbeite, die als Variablen gespeichert sind und nicht als HEX-Wert hart codiert werden …

[Þorsten]

#fe0000 o.ä. wäre auch meine Empfehlung gewesen.   Ansonsten kann ich den Bug auch unter Linux bestätigen. Hier konnte ich ihn in Webkit-Browsern (Chrome, Chromium, rekonq) duplizieren, nicht aber in Opera, Konqueror oder eben Firefox, in denen alles funktioniert. Ich nehme an, dass in den betroffenen Browsern beim Kompilieren/Optimieren des CSS a {color: red} bzw. a:link {color: red} und a:hover {color: red} fälschlicherweise als redundant angesehen und daher wegoptimiert wird.

 

Ein paar Live-Testdateien gibts hier. Man kann z.B. sehen, dass das Problem auch auftritt, wenn statt a:visited {color: inherit} bereits besuchte Links mit einer expliziten Farbe versehen werden. a:hover {color: red !important} bringt nichts. Ich würde, bevor ich aufgebe, aber noch andere Optionen versuchen, z.B.

• body a:hover {color: red}
• .someclass a:hover {color: red}
• #someID a:hover {color: red}
• mein CSS teilweise per Javascript zu aktivieren

… halt irgendwas, das die Deklarationen für a {}  und a:hover {} möglichst unterschiedlich aussehen lässt.

 

Viel Spaß!

[Þorsten]

Ich hoffe, dass ich einen Workaround gefunden habe, der auch bei dir funktioniert. Zumindest in all meinen Browsern funktioniert es, wenn ich in a:hover zusätzlich die Hintergrundfarbe setze (und sie muss nicht anders sein, als die, die auch sonst verwendet wurd/würde). Also z.B.

      a:hover {
        color: red;
        background-color: white;
      }

Live-Seite

 

Uff!

[TobiW]

Nabend,

 

ja diesen Workaround hatte ich auch schon gefunden, aber min Hintergrund ist ein Bild … und auf die ganzen anderen Betteleien habe ich eigentlich keine Lust. Aber mir ist eingefallen, wie ich mit Catfonts Vorschlag doch was anfangen kann. Da ich mit SASS arbeite, setzte ich die Farbe einfach als adjust_hue($highlight,1). Damit ist sie minimal anders, aber ich kann trotzdem weiter mit meinen Variablen arbeiten.

 

Das Problem ist so umgangen, aber nicht gelöst. Hat jemand ne Idee, wie man den Bug wem sinnvoll melden kann?!

 

Gute Nacht!

Tobi

[Þorsten]

Da es sich um einen browserübergreifenden, aber webkitspezifischen Bug zu handeln scheint, wäre https://bugs.webkit.org/ wahrscheinlich die technisch sauberste Variante. Ob es sich lohnt, zusätzlich noch Google Bescheid zu sagen, wage ich nicht zu beurteilen.

[TobiW]

Da gibt es sogar schon einen Bericht: https://bugs.webkit.org/show_bug.cgi?id=61697. Der ist allerdings schon von 2011 und da ich vermutlich nicht viel schlaues dazu sagen könnte, lebe ich jetzt einfach mit meinem Workaround

[Þorsten]

Wundert mich nicht. Irgendwie kam mir das Problem auch bekannt vor; ich hatte es auch schon mal vor Jahren, glaube ich.

 

Wenn du die Zeit erübrigen kannst, könntest du – angesichts der stiefmütterlichen Behandlung des Bugs beim Webkit-Projekt – vielleicht doch noch mal bei Chromium recherchieren und ggf. einen neuen Bug posten. Oder halt in Chrome selbst: wrench -> About Google Chrome -> report an issue

[catfonts]

Vielleicht liegt es bei Webkit ja auch daran, das dieser Bug zu den weniger problematischen gezählt wird, wweil jeder, der sich daran stößt dann feststellt: "Aha, der Bug ist schon gemeldet" und unterlässt seinerseits eine neue Meldung.

 

Die Webkit-Leute sehen das dann so: "Gut, da war einer, der das als Fehler ansieht, aber alle anderen scheinen ja damit klar zu kommen, also ist das nicht vorrangig zu beheben"

[TobiW]

So ich habe den Fehler jetzt über Chromes Feedback-Funktion, den Chromium Bug-Report und als Safari-Feedback gemeldet. Vielleicht interessiert sich ja jemand dafür …

[TobiW]

Ganz vergessen … hier noch der Link zur Meldung bei Chromium: https://code.google.com/p/chromium/issues/detail?id=439812

[Þorsten]

Super! Dann kommentiert mal alle ordentlich, um der Sache Dringlichkeit zu verleihen!