nicht angemeldet
a { ... } = a.link { ... }?
Hallo,
Ich bin mir etwas unsicher im Umgang mit Pseudoformaten. Wenn ich beispielsweise das a-Element mit diesen formatiere, muss ich a selbst dann immer noch formatieren? Oder macht das keinen Sinn, da ich mit a.link schon alles abdecke und kann ich mir die Angabe a { ... } dann sparen?
Vielen Dank,
Andreas
-
Hallo,
Ich bin mir etwas unsicher im Umgang mit Pseudoformaten. Wenn ich beispielsweise das a-Element mit diesen formatiere, muss ich a selbst dann immer noch formatieren? Oder macht das keinen Sinn, da ich mit a.link schon alles abdecke und kann ich mir die Angabe a { ... } dann sparen?
a { } wirkt auch auf reine Anker: <a name="ziel1">Kapitel 1</a>
Ansonsten sind AFAIK mit a:link { } eigentlich alle Zustaende von Links mitgemeint.Ich wuerde aber eher mit a { } allgemeine Dinge fuer Links, wie Schriftgroesse, Fett, u.s.w. festlegen
und mit den Pseudoklassen nur noch Details fuer Farben, Unterstreichung u.s.w.Gruesse,
Thomas
-
Angenommen ich schreibe:
a { color:#f00; }
a:hover { color:#fff; }Wird dann in allen Browsern für :link, :visited, :focus, :active automatisch der Wert von a übernommen, da ich ja nur bei :hover etwas angegeben?
Andreas
-
Hi,
Wird dann in allen Browsern für :link, :visited, :focus, :active automatisch der Wert von a übernommen, da ich ja nur bei :hover etwas angegeben?
je nach Definition von "allen Browsern": ja.
Cheatah
--
X-Will-Answer-Email: No
X-Please-Search-Archive-First: Absolutely Yes -
Hallo,
a { color:#f00; }
a:hover { color:#fff; }
Wird dann in allen Browsern für :link, :visited, :focus, :active automatisch der Wert von a übernommen, da ich ja nur bei :hover etwas angegeben?Ja.
Du solltest uebrigens _immer_ gleichzeitig mit der Vordergrund- auch die Hintergrundfarbe definieren.
Und :focus solltest Du eher wie :hover definieren.
:focus wird von den meisten Browsern dann verwendet, wenn man mit
der Tabulator-Taste von einem Link zum naechsten huepft.
Zum Ausprobieren:
http://www.tiptom.ch/tests/css/linkpseudo.htmlGruesse,
Thomas
-
Hallo Thomas,
Du solltest uebrigens _immer_ gleichzeitig mit der Vordergrund- auch die Hintergrundfarbe definieren.
Warum sollte man das immer (mit Betonung auf »immer«, nicht »an geeigneter Stelle« o.ä.)?
(Ich verweise vorsichtshalber schon einmal auf </archiv/2003/7/51370/#m283198> und </archiv/2003/3/40669/#m222774>...
M.
-
Hallo Molily,
Du solltest uebrigens _immer_ gleichzeitig mit der Vordergrund- auch die Hintergrundfarbe definieren.
Warum sollte man das immer (mit Betonung auf »immer«, nicht »an geeigneter Stelle« o.ä.)?Weil es sonst eine Warnung beim CSS-Validator gibt ;-)
Im Ernst: Weil es sonst passieren kann, dass der Text, fuer den nur die Vordergrundfarbe
vorgegeben ist, auf einer Hintergrundfarbe steht, auf der man ihn nicht (oder nur schlecht)
lesen kann (oder umgekehrt).
Gruende z.B.:- Browser kann gewisse Selektoren nicht (IMHO ziemlich wahrscheinlich)
- Interferenz mit Benutzerstylesheets (IMHO eher unwahrscheinlich,
gerade, wenn dort Vorder- und Hintergrundfarbe konsequent
immer beide angegeben sind)
Beispiel:
<div><p>Bla Fasel <span>Spantext</span></p></div>body { color:white; background-color:blue; }
div>p { color:black; background-color:white; }
span { color:red; }
/* Saemtliche Farben nur als Beispiel, um das Problem
zu veranschaulichen. ;-) */Man koennte ja argumentieren, dass fuer den Spantext
Vorder- und Hintergrundfarbe sehr wohl definiert sind,
weil er die Hintergrundfarbe ja vom uebergeordneten Element erbt.Wenn ein Browser aber den Selektor div>p nicht kann,
dann steht rote Schrift auf blauem Hintergrund, was
sehr schlecht zu lesen ist, nicht nur fuer Farbenblinde...Wenn man es so definiert:
span { color:red; background-color:white; }
kann das nicht passieren.
Man ist auf der sicheren Seite.Das ist IMHO auch der Grund, warum der Validator Warnungen ausgibt,
wenn man in einer Definition nur die eine Farbe nimmt.transparent und inherit beseitigen zwar die Warnung, aber
sie sind eben truegerisch, weil sie genau zu obigen Fehlern
fuehren koennen.Freundliche Gruesse,
Thomas
-
Hallo Thomas,
Du solltest uebrigens _immer_ gleichzeitig mit der Vordergrund- auch die Hintergrundfarbe definieren.
Warum sollte man das immer (mit Betonung auf »immer«, nicht »an geeigneter Stelle« o.ä.)?Im Ernst: Weil es sonst passieren kann, dass der Text, fuer den nur die Vordergrundfarbe vorgegeben ist, auf einer Hintergrundfarbe steht, auf der man ihn nicht (oder nur schlecht) lesen kann (oder umgekehrt).
Das beantwortet meine Frage nicht, denn um dem zu begegnen, ist in der Regel eine robuste Vererbung nötig, kein sklavisches Angeben von color/background-color in jeder Regel, in der color oder background-color vorkommt.
Gruende z.B.:
- Browser kann gewisse Selektoren nicht (IMHO ziemlich wahrscheinlich)
Das sehe ich ein (auch bzgl. deines Beispiels), darauf muss der Autor in jedem Fall Rücksicht nehmen.
- Interferenz mit Benutzerstylesheets (IMHO eher unwahrscheinlich, gerade, wenn dort Vorder- und Hintergrundfarbe konsequent immer beide angegeben sind)
Vielleicht liegt es an meiner mangelnden Vorstellungskraft, aber mir sind keine Beispiele hinsichtlich Benutzerstylesheets denkbar, in welchen es entscheidend ist, dass jeweils auch die Textfarbe bzw. Hintergrundfarbe angegeben wird. Angenommen, das Benutzerstylesheet ändert problematischerweise nur die Textfarbe, was würde es bringen, dass im Autorenstylesheet *überall*, wo sich die Vordergrundfarbe ein wenig ändert, auch die Hintergrundfarbe (wiederholt) angegeben ist? Oder bei einem Element mit minimal bzw. nur hinsichtlich eines Farbtons abweichender Hintergrundfarbe auch die Vordergrundfarbe? Gesucht ist also ein Fall, in dem es einen kritischen Unterschied macht, wenn die jeweils zweite Angabe fehlt (Selektorunterstützungs- und -spezifizitätsprobleme einmal ausgeklammert). Ich denke eher, diesen im Benutzerstylesheet befindlichen Problemen kann man nicht autorenseitig begegnen; wenn darin Murks steht, kommt es zwangsläufig dem Autorenstylesheet in die Quere, da helfen keine expliziten Farbangaben. Vielleicht kann man sich ein enorm widersinniges Stylesheet konstruieren, mit welchem es tatsächlich einen Unterschied macht, nur wüsste ich nicht, wie, und denke nicht, dass das relevant wäre.
(...) transparent und inherit beseitigen zwar die Warnung, aber sie sind eben truegerisch, weil sie genau zu obigen Fehlern fuehren koennen.
Darin stimme ich dir zu.
Mathias
-
-
-
-
Nein, mit a:link, a:visited deckst du alle Zustände von Hyperlinks ab und schließt gleichzeitig noch Anker (<a name="...">...) aus.
-
-
hi,
Ich bin mir etwas unsicher im Umgang mit Pseudoformaten.
scheint so, denn
da ich mit a.link
a.link bezieht sich auf ein <a> mit der _klasse_ link - das pseudoformat heisst aber :link.
gruss,
wahsaga