Warum liefert dieses Stylesheet Warnungen?

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!

zwutz

hmmz schrieb:

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

Glashaus, Steine; du kennst den Rest

Du warst es, der vom Thema abwich, als du mit deinem konstruierten Beispiel kamst.
Im Fall des Codes des OP sind classes nicht angemessen, wie dir shade und árn[y]ék auch mehrfach versucht haben, klar zu machen

Gibt es wenigstens Einen, der mal von Anfang bis Ende liest, oder greift ihr euch nur die Teile raus auf denen ihr rumreiten könnt? Mir wird das nun echt zu albern! Lernt lesen ...

zwutz schrieb:

Glashaus, Steine; du kennst den Rest

... ich kenn den Rest, weiß aber nicht wie du auf den Blödsinn kommst

zwutz schrieb:

Du warst es, der vom Thema abwich, als du mit deinem konstruierten Beispiel kamst.

OP:

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

Meins:

a:link 
{ 
    text-decoration:  none; 
    background-color: inherit; 
    color:            blue; 
} 

a:visited 
{ 
    text-decoration:  none; 
    background-color: inherit; 
    color:            purple; 
}

Konstruiertes Beispiel
Was willst du von mir, und wie kommst du darauf mein Beispiel wäre _konstruiert?

Dasd

Du hast zweimal "text-decoration: none;" in deinem Stylesheet. Der OP nur einmal. Und genau darauf kam es an: Redundanz zu vermeiden.

zwutz

hmmz schrieb:

wie wärs mit aggressionstherapie? Ist ja kein Grund, hier alles gleich persönlich zu nehmen

hmmz schrieb:

Was willwie kommst du darauf mein Beispiel wäre _konstruiert?

ich rede davon:

hmmz schrieb:

<b class='my'>hallo</b>&nbsp;<i class='my'>du</i>

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

das hat mit dem Beitrag des OPs nix zu tun.

Dasd schrieb:

Du hast zweimal "text-decoration: none;" in deinem Stylesheet. Der OP nur einmal. Und genau darauf kam es an: Redundanz zu vermeiden.

ich sehe das zwispältig.
Klar, Redundanzen sollte man vermeiden. Gerade im Web-Bereich ist jedes Byte relevant.
Aber manchmal hat man durchaus absichtlich redundanzen drin, gerade, wenn man Elemente hat, die zwar aktuell ähnlich aussehen, aber getrennt voneinander formatiert werden können müssen
z.B. alle überschriften unterstrichen und rot. Später soll h1 aber blau sein, trotzdem aber noch unterstrichen, dafür h2 mit gestricheltem Unterstrich und gelb.

Dasd

zwutz schrieb:

Dasd schrieb:

Du hast zweimal "text-decoration: none;" in deinem Stylesheet. Der OP nur einmal. Und genau darauf kam es an: Redundanz zu vermeiden.

ich sehe das zwispältig.
Klar, Redundanzen sollte man vermeiden. Gerade im Web-Bereich ist jedes Byte relevant. [...]

Ich meinte eher die "informationelle" Redundanz, weniger die Dateigröße. Je weniger Stellen ich später ändern muss, desto besser (und einfacher wartbar). Ich würde sogar sagen, die Version des OP hat mehr Bytes als die von hmmz.

Aber natürlich hast du recht: dafür geht ein gewisser Grad an Flexibilität verloren. Ist wohl also eher eine philosophische Frage, die je nach Projekt/Kontext anders zu beantworten ist.