Warum liefert dieses Stylesheet Warnungen?

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.

zwutz schrieb:

hmmz schrieb:

hmmz schrieb:

hmmz schrieb:

hmmz schrieb:

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

Ich hab einfach die Nase voll von Klugscheißern die ihr Wissen aus Lehrbüchern haben und fernab jeglicher Praxis aufwachsen. Was irgendwo geschrieben steht und wie es aber tatsächlich realisiert wird, sind zwei grundverschiedene Dinge!

Ist wohl also eher eine philosophische Frage, die je nach Projekt/Kontext anders zu beantworten ist.

Mit der Aussage kann ich mich anfreunden, denn genau das ist es was man tagtäglich antrifft (in der großen echten Welt). Das perfekte Lehrbuchbeispiel ist von den realitätsechten Situationen das, welches am wenigsten auftaucht, aber genau das vermittelt ihr hier den Leuten... Und dieser Fakt ist für mich nicht begreiflich...

Mit meinem Beispiel hatte ich mich an die Situation des OP gewandt, dass das nicht unbedingt sinnvoll ist, ist mir klar, deswegen ist es aber noch lange nicht schlecht / redundant, oder gar falsch (das Beispiel). Trotzdem erzählt ihr mir einen vom Pferd und macht genau das was ihr - und da wette ich mit euch - in euren Projekten absolut identisch umsetzt, hier im Forum total runter?!

VlG

Shade Of Mine

zwutz schrieb:

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.

Ja, es kommt darauf an ob die Elemente gleich sein sollen oder nur zufaellig gleich sind.

Es macht zB durchaus Sinn wenn du alle Links unterstrichen haben willst, unabhaengig davon wo sie stehen. Wenn du aber Ueberschriften hast die Zufaellig gerade alle fett und 72pt sind, dann ists eher unwahrscheinlich dass das ewig bleibt: also hier lieber trennen. Die Fontfamily dagegen wird sich vermutlich nicht unterscheiden -> also hier wieder zusammen legen.

Prinzipiell legt man deshalb alles zusammen was wirklich eine gemeinsame Basis ist. Wie eben beim OP die links. Wichtig aber ist, dass auseinander nehmen einfacher ist als zusammen legen. Das sollte man auch beachten

zwutz

hmmz schrieb:

Ich hab einfach die Nase voll von Klugscheißern die ihr Wissen aus Lehrbüchern haben und fernab jeglicher Praxis aufwachsen. Was irgendwo geschrieben steht und wie es aber tatsächlich realisiert wird, sind zwei grundverschiedene Dinge!

ich denke, hier haben einige genug Praxis.
Genug Praxis um zu wissen, dass das, was in Büchern steht, nicht umsonst dort steht.
Google geht mittlerweile soweit, die Seitengeschwindigkeit in ihre Rankings mit einzubauen, und so kosten zu lange Ladezeiten mitunter bares Geld. Und da html-Dateien seltener bzw. kürzer gecacht werden, als css-Dateien, sollte man in html-Dateien wirklich nur das allernötigste notieren.
Wenn man styles also auch so ohne classes zuverlässig zuweisen kann, sollte man das auch so machen

zwutz schrieb:

Google geht mittlerweile soweit, die Seitengeschwindigkeit in ihre Rankings mit einzubauen

Quelle?

zwutz schrieb:

in html-Dateien wirklich nur das allernötigste notieren.
Wenn man styles also auch so ohne classes zuverlässig zuweisen kann, sollte man das auch so machen

Ich habe nie was anderes behauptet....

zwutz

hmmz schrieb:

zwutz schrieb:

Google geht mittlerweile soweit, die Seitengeschwindigkeit in ihre Rankings mit einzubauen

Quelle?

http://googlewebmastercentral.blogspot.com/2010/04/using-site-speed-in-web-search-ranking.html

Danke