Warum liefert dieses Stylesheet Warnungen?

SideWinder

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.

schmidt-webdesign.net

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.

Nico D.

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

schmidt-webdesign.net

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

Shade Of Mine

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>&nbsp;<i class='my'>du</i>

<style>
.my { font-family:Tahoma; }
</style>

???

VlG

Nico D.

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>&nbsp;<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.

Shade Of Mine

hmmz schrieb:

Aber was wäre falsch an:

<b class='my'>hallo</b>&nbsp;<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.

Hallo,

ich glaube wir reden aneinander vorbei! Ich rede davon zwei verschiedene Elemente mit gleichen Eigenschaften zu belegen! Nicht davon, immer das gleiche Element mit gleichen Eigenschaften zu besetzen.

Missverständlich für mich war und ist auch immer noch, wieso man Ersteres nicht tun sollte?! Somit ist es auch keine Themenverfehlung!

@Shade
Du machst aus meinem Beispiel eine ganz andere Geschichte -> folglich: absolut falsch was du erzählst! Weil, du machst das genaue Gegenteil von dem was ich geschrieben hab! Das deine Beispiel so keinen Sinn machen ist mit vollkommen klar, was aber wenn ich aus:

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

das hier mache:

<b class="a">hallo</b> <i class="a">du</i> <i class="b">da</i>
<style>
a i { color:red; }
.a { font-family:Tahoma; }
.b { font-family:Verdana; }
</style>

... dann wären wir wieder bei meinem Beispiel! Und ich erkenne immer noch nicht was daran nicht in Ordnung sein soll

VlG

Shade Of Mine

hmmz schrieb:

Du machst aus meinem Beispiel eine ganz andere Geschicht

Dein Beispiel ist auch komplett irrelevant. Habe ich ja bereits geschrieben. Schau dir den Code des OP an...

Der OP hatte folgenden Code:

<style>
a:link, a:visited 
{ 
    text-decoration:  none; 
} 

a:link 
{ 
    background-color: inherit; 
    color:            blue; 
} 

a:visited 
{ 
    background-color: inherit; 
    color:            purple; 
}
</style>

a:link und a:visited werden zusammengefasst weil sie sich gleiche Styles teilen. Danach werden fuer beide eigene erweiterte Styles definiert.

Darum geht es. Hier sind Klassen dumm.

Wenn du natuerlich etwas komplett anderes machen willst, wie in deinem letzten Beispiel, wo es darum geht dass es unterschiedliche Arten (=Klassen) von bestimmten Tags gibt -> ja, dann sind Klassen natuerlich das richtige.

Deshalb auch mein Hinweis darauf, dass du etwas komplett anderes meinst als es Thema hier ist...

Oh, Meister - ich hab zwar nicht gelesen, weiß aber trotzdem alles - hat sich wieder zu Wort gemeldet...

Wieso ist der Code jetzt plötzlich irrelevant? Lies den gesamten Thread, versteh ihn, und mach den Mund erst wieder auf wenn du tatsächlich weißt um was es geht! Ich hab kein Bock auf Diskussionen die mit dem Thema nichts zu tun haben, sondern nur entstehen, weil dir gerade nicht passt was ich schreibe.

Ich habe mich auf den Post von árn[y]ék bezogen, nicht auf den des OP!
Wer lesen kann....

Shade Of Mine

hmmz schrieb:

Ich habe mich auf den Post von árn[y]ék bezogen, nicht auf den des OP!

Dein Post kam vor dem ersten Post von árn[y]ék
Aber ich bin sicher dass du trotzdem recht hast.

Hallo,

ich weiß nicht wo du mit deinen Gedanken bist?! Ich bin mit meinen bei jenem Satz: "für so etwas wurde das Attribut class eingeführt ...". Dieser Satz kam von mir auf Basis eines Posts welcher wiederum von "árn[y]ék" kam. Darum dreht sich doch diese Diskussion, oder nicht? Wenn nicht, weiß ich ehrlich gesagt nicht was du eigentlich von mir willst??

Naja, es ist wie so oft: "Hauptsache man hat irgendwas dazu gesagt... Ob es mit dem Thema zu tun hat oder nicht, interessiert ja sowieso nicht..."

VlG

P.S. arrogantes Rumgezwinker macht die Sache auch nicht besser!