Warum liefert dieses Stylesheet Warnungen?
-
Dann gib ihm halt eine Vordergrundfarbe.
Ohne einen Link zu der Seite oder den kompletten Quelltext ist das eh 'ne Stocherei im Nebel.
-
Scheppertreiber schrieb:
Dann gib ihm halt eine Vordergrundfarbe.
Hat er doch: Zeile 13: "color: purple". Das ist es ja gerade, was mich stört: Ich habe eine Vordergrundfarbe angegeben (nur nicht im selben Block, aber das sollte egal sein. Es geht mir ja eben darum, dass ich damit verdeutliche, dass body und a:link in jedem Fall immer dieselbe Hintergrundfarbe haben sollen, ohne die Farbe zweimal im Code definieren zu müssen).
Scheppertreiber schrieb:
Ohne einen Link zu der Seite oder den kompletten Quelltext ist das eh 'ne Stocherei im Nebel.
Das Code in meinem ersten Post ist der komplette Quelltext: Kopier ihn dir raus, lade die Datei beim Validator selbst hoch und staune darüber, dass er mal null, mal eine und mal zwei Warnungen hat.
-
Ich werde mir das nicht rauskopieren.
Entweder gibts Du Dir da mal etwas Mühe oder lernst es.
-
OK, jetzt kapier ich gar nichts mehr: Ich poste einen kompletten Code für ein Stylesheet. Ich poste die Warnungen als Screenshot, die mir der Validator mit genau diesem Stylesheet ausgibt. Und dann frage ich ganz normal, wo der Fehler liegt.
Worin hab ich mir nun keine Mühe gegeben? Du sagtest, ohne kompletten Quelltext ist das ein Stochern im Nebel und ich sagte dir, dass ich den kompletten Quelltext zur Fehlerrekonstruktion gepostet habe, es also nicht nur irgendein Ausschnitt eines Quellcodes ist, sondern dass genau dieser Quellcode ausreicht, um den Fehler zu rekonstruieren.
Was hab ich jetzt deiner Meinung nach gemacht, dass du mir vorwirfst, mir nicht genug Mühe zu geben oder etwas "nicht zu lernen"? Das würde mich wirklich interessieren.
-
background: white;
ist völlig korrekte Syntax.color
definiert die Textfarbe. Was das mit einer "Vordergrundfarbe" zu tun hat, ist mir recht schleierhaft ...
Seltsamer Fehler, ist mir so noch nie begegnet. Möglicherweise ein Ketteneffekt?
-
Dr. Webber schrieb:
OK, jetzt kapier ich gar nichts mehr: Ich poste einen kompletten Code für ein Stylesheet. Ich poste die Warnungen als Screenshot, die mir der Validator mit genau diesem Stylesheet ausgibt. Und dann frage ich ganz normal, wo der Fehler liegt.
Worin hab ich mir nun keine Mühe gegeben? Du sagtest, ohne kompletten Quelltext ist das ein Stochern im Nebel und ich sagte dir, dass ich den kompletten Quelltext zur Fehlerrekonstruktion gepostet habe, es also nicht nur irgendein Ausschnitt eines Quellcodes ist, sondern dass genau dieser Quellcode ausreicht, um den Fehler zu rekonstruieren.
Was hab ich jetzt deiner Meinung nach gemacht, dass du mir vorwirfst, mir nicht genug Mühe zu geben oder etwas "nicht zu lernen"? Das würde mich wirklich interessieren.Es handelt sich hier um einen Fail des Gesprächspartners. Ich lege dir Ignorieren dieses Partners ans Herz. Edit: Zu deinem Problem kann ich aber leider auch nichts sagen. Evtl. auch ein Bug im Validator?
MfG SideWinder
-
árn[y]ék schrieb:
Was das mit einer "Vordergrundfarbe" zu tun hat, ist mir recht schleierhaft ...
Ja, gut, schlechte Wortwahl. Ich meinte die Textfarbe.
árn[y]ék schrieb:
Seltsamer Fehler, ist mir so noch nie begegnet. Möglicherweise ein Ketteneffekt?
Was meinst du damit?
SideWinder schrieb:
Evtl. auch ein Bug im Validator?
Daran hab ich auch schon gedacht. Zumal ich mein Stylesheet seit Jahren benutze und erst neulich, als ich etwas (hiermit nichts zu tun habendes) hinzugefügt habe und dann erstmalig diese Warnung kam, die auch noch blieb, als ich das Stylesheet auf den obigen Quellcode verringert habe.
-
Füge folgende Ergänzungen ein:
body { color : black; [b]background-color : inherit;[/b] } a:link { color : purple; [b]background-color : inherit;[/b] }
Dann sollten die Warnungen unterbleiben.
-
Der Fehler wird aber vermutlich schlicht daran gelegen haben, dass hinter
purple
das Semikolon fehlte.
-
Das hilft immer noch nichts. Zum Beispiel dieser Code:
body { background-color: black; color: white; } a:link, a:visited { text-decoration: none; } a:link { background-color: inherit; color: blue; } a:visited { background-color: inherit; color: purple; }
liefert immer noch die Warnung:
20 a:visited Sie haben keine Vordergrundfarbe zu der Hintergrundfarbe angegeben
-
Hallo,
wieso machst du sowas seltsames? Das ist ja wie als würdest du eine Variable doppelt deklarieren
Was passt dir nicht an:
a:link { text-decoration: none; background-color: inherit; color: blue; } a:visited { text-decoration: none; background-color: inherit; color: purple; }
VlG
-
Der CSS-Validators findet in diesem
body { background-color: black; color: white; } a:link, a:visited { text-decoration: none; background-color: inherit; } a:link { color: blue; } a:visited { color: purple; }
weder Fehler noch Warnungen (gerade getestet).
-
hmmz schrieb:
wieso machst du sowas seltsames? Das ist ja wie als würdest du eine Variable doppelt deklarieren
Das ist überhaupt nicht seltsam, sondern ziemlich elegant, wenn du Redundanz vermeiden willst. Hier in dem Beispiel wirkt es sicherlich etwas deplatziert. Aber gesetz den Fall, du hast ein umfangreicheres Skript, dann ist solch ein Code überhaupt nichts Besonderes.
Du vermeidest so, Eigenschaften, die für mehrere Stile gleichermaßen gelten, bei einer Änderung an 20 Stellen nacheinander anpassen zu müssen. Das reduziert die Fehlerquote und den Aufwand drastisch.
-
Hallo,
árn[y]ék schrieb:
Das ist überhaupt nicht seltsam, sondern ziemlich elegant, wenn du Redundanz vermeiden willst. Hier in dem Beispiel wirkt es sicherlich etwas deplatziert. Aber gesetz den Fall, du hast ein umfangreicheres Skript, dann ist solch ein Code überhaupt nichts Besonderes.
Du vermeidest so, Eigenschaften, die für mehrere Stile gleichermaßen gelten, bei einer Änderung an 20 Stellen nacheinander anpassen zu müssen. Das reduziert die Fehlerquote und den Aufwand drastisch.
für so etwas wurde das Attribut class eingeführt ...
<a href='#' class='a1'>test</a> <a href='#' class='a2'>test</a> <style> a { text-decoration:none; } .a1:link { color:black; } .a1:visited .a2:visited { color:purple; } .a2:link { color:green; } </style>
VlG
-
hmmz schrieb:
für so etwas wurde das Attribut class eingeführt ...
Nope.
class ist etwas ganz anderes.Es macht keinen Sinn ueberall class zu verwenden. class ist dafuer da, wenn etwas anders aussehen soll, nicht wenn etwas gleich aussehen soll.
Du hast ein menu - das sieht anders aus als der Rest der Seite: class
Du willst b und i Tags aehnlich aussehen lassen, aber nicht identisch: kein class.
-
Hallo,
das ist ~mal wieder~ eine Aussage, aber keine Begründung. Wieso sollte man class nicht auch für gleich/ähnlich aussehende Elemente verwenden?
Natürlich wäre es Unsinn hier ein gleiches Aussehen zu provozieren, wo b und i doch schon Stylegebende Elemente sind...
Aber was wäre falsch an:
<b class='my'>hallo</b> <i class='my'>du</i> <style> .my { font-family:Tahoma; } </style>
???
VlG
-
Mal 'ne Frage am Rande: Ist
inherit
ueberhaupt als Farbangabe zulaessig? Les' ich grade zum ersten Mal, dass man in CSS ueberhaupt etwas vererben lassen kann.
-
hmmz schrieb:
für so etwas wurde das Attribut class eingeführt ...
Achne, Schlaumeier
Und jetzt lies dir nochmal genau durch, was ich geschrieben hatte.Es geht nicht um die Auszeichnung bestimmter Elemente, sondern darum, verschiedene Elemente, die dennoch zusammengehörig gewisse Stilangaben teilen, ökonomisch und leicht zu warten im Stylesheet zu beschreiben. Und exakt dafür sind die von dir völlig zu Unrecht gescholtenen Doppeldeklarationen gut.
heini schrieb:
Mal 'ne Frage am Rande: Ist
inherit
ueberhaupt als Farbangabe zulaessig? Les' ich grade zum ersten Mal, dass man in CSS ueberhaupt etwas vererben lassen kann.Geht durchaus, wird z.B. gerne verwendet, um dem Text eine andere Farbe zu geben als seiner Unterstreichung. Grundsätzlich kannst du für nahezu alle Werte
inherit
angeben, das heißt einfach nur "übernehme die Angabe vom übergeordneten Element". Und das hat halt schlimmstenfalls einfach keine besondere Auszeichnung.
-
hmmz schrieb:
Aber was wäre falsch an:
<b class='my'>hallo</b> <i class='my'>du</i> <style> .my { font-family:Tahoma; } </style>
Es ist nicht falsch, aber redundant. Wie Shade schon geschrieben hat: b und i haben eine gewisse grundsätzliche Formatierung.
class
würdest du jetzt verwenden, wenn darunter einige bestimmte b- oder i-Elemente wider die Norm eine andere Formatierung bekommen sollen.
-
hmmz schrieb:
Aber was wäre falsch an:
<b class='my'>hallo</b> <i class='my'>du</i> <style> .my { font-family:Tahoma; } </style>
Das ist themenverfehlung.
Deshalb kleines Beispiel:
<b>hallo</b> <i>du</i> <style> b,i { font-family:Tahoma; } b { text-decoration:underline; } i { color:red; } </style>
Das ganze jetzt mit Klassen:
<b class="a">hallo</b> <i class="a">du</i> <style> .a { font-family:Tahoma; } b.a { text-decoration:underline; } i.a { color:red; } </style>
Oh, ploetzlich ist das hier das selbe wie ohne Klassen. Ne, das kann man auch ohne dem zusammenlegen der definitionen tun:
<b class="a b">hallo</b> <i class="a c">du</i> <style> .a { font-family:Tahoma; } .b { text-decoration:underline; } .c { color:red; } </style>
macht die Sache auch nicht wirklich besser.
Einfach nur Klassen auf ein Problem werfen ist idR die falsche Loesung.
Wir wollen im markup code so unspezifisch wie moeglich bleiben. Deshalb ist uU auch folgendes hier eine bessere Loesung als massig Klassen zu verwenden:
<span class="a"> <b>hallo</b> <i>du</i> </span> <style> span.a b, span.a i { font-family:Tahoma; } span.a b { text-decoration:underline; } span.a i { color:red; } </style>
Bedenke: jede Klasse mehr erhoeht die komplexitaet und somit die Wartbarkeit. Wenn jedes b Element in Tahoma geschrieben sein soll, dann ist es besser hierfuer keine Klasse zu verwenden anstatt ueberall class="xyz" dazuzuschreiben. Denn dann kann man viel leichter Aenderungen durchfuehren. zB wie in meinem letzten Beispiel - mit Klassen waere das echt schwer.