CSS oder nicht?

[sigrun]

Hallo,
ich benötige an einigen Stellen die Angabe "padding-left:8em".
Ist es da wirklich sinnvoll, dies in externe CSS-Datei auszulagern?
CSS:
.paddingLeft8em {padding-left:8em}
html:
<p class="paddingLeft8em">

ist doch aufwendiger und unübersichtlicher als

<p style="padding-left:8em;">.

[Kai345]

[latex]Mae  govannen![/latex]

ich benötige an einigen Stellen die Angabe "padding-left:8em".
Ist es da wirklich sinnvoll, dies in externe CSS-Datei auszulagern?
CSS:
.paddingLeft8em {padding-left:8em}
html:
<p class="paddingLeft8em">

ist doch aufwendiger und unübersichtlicher als

<p style="padding-left:8em;">.

Nachdenk-Frage: An wie vielen Stellen mußt du jeweils den Wert ändern, wenn du irgendwann mal überall 7em haben willst? Immer noch aufwendiger?

(Spätestens hier fällt übrigens die Unsinnigkeit einer Klassenbenennung "paddingLeft8em" auf)

Stur lächeln und winken, Männer!
Kai

[sigrun]

Nachdenk-Frage: An wie vielen Stellen mußt du jeweils den Wert ändern, wenn du irgendwann mal überall 7em haben willst? Immer noch aufwendiger?

change 8em 7em all!

(Spätestens hier fällt übrigens die Unsinnigkeit einer Klassenbenennung "paddingLeft8em" auf)

Welche Bezeichnung böte sich dann an?
Insbesondere, wenn ich an anderen Stellen 6em und 4em haben möchte?

[Multi]

Welche Bezeichnung böte sich dann an?
Insbesondere, wenn ich an anderen Stellen 6em und 4em haben möchte?

h1, h2, h3
und die Benutzung der entsprechenden Elemente.

[Kai345]

[latex]Mae  govannen![/latex]

Nachdenk-Frage: An wie vielen Stellen mußt du jeweils den Wert ändern, wenn du irgendwann mal überall 7em haben willst? Immer noch aufwendiger?

change 8em 7em all!

Funktioniert vor allem prima, wenn irgendwo beispielsweise style="margin-right: 8em;" steht ;)

Stur lächeln und winken, Männer!
Kai

[sigrun]

change 8em 7em all!

Funktioniert vor allem prima, wenn irgendwo beispielsweise style="margin-right: 8em;" steht ;)

Darum solltest Du Dir keine Sorgen machen - bisher haben alle meine Massenänderungen tadellos funktioniert

@multi:

h1, h2, h3
und die Benutzung der entsprechenden Elemente.

h1,h2,h3 eignen sich ja schon gar nicht!
Die entsprechenden Elemente gibt es ja nicht standarmäßig.

Also wie nennt man sinnvollerweise die Klassen, die jeweils nur
padding-left:4em;
padding-left:6em;
padding-left:8em;
...
enthalten?
Die Theorie ist recht und schön, aber sie hat halt doch Grenzen, wenn es an die Praxis geht.

[Multi]

Die entsprechenden Elemente gibt es ja nicht standarmäßig.

Von welchem Standard redest du? In jedem HTML und XHTML-Standard gibt es h1-h6, wenn du was anderes nimmst, hast du es in deinem ersten Posting versäumt zu erwähnen.

Also erklär mal, womit du arbeitest, wo es h1-h6 nicht gibt.

BTW: Wie du eine Klasse nennst ist völlig schnurz.

[sigrun]

Die entsprechenden Elemente gibt es ja nicht standarmäßig.

Also erklär mal, womit du arbeitest, wo es h1-h6 nicht gibt.

Ich habe nicht geschrieben, dass es h1.... nicht standardmäßig gibt, sondern es ging um Elemente, die (nur) die Eigenschaft padding-left:8em; bzw.
padding-left:7em; ... enthalten. Dies ist doch wohl für h1,h2,.... nicht der Fall!

BTW: Wie du eine Klasse nennst ist völlig schnurz.

Da ist Kai345 aber anderer Meinung:

(Spätestens hier fällt übrigens die Unsinnigkeit einer Klassenbenennung "paddingLeft8em" auf)

[Multi]

Ich habe nicht geschrieben, dass es h1.... nicht standardmäßig gibt, sondern es ging um Elemente, die (nur) die Eigenschaft padding-left:8em; bzw.
padding-left:7em; ... enthalten. Dies ist doch wohl für h1,h2,.... nicht der Fall!

Es gibt absolut gar kein Element, das Standardmässig padding-left:8em; hat.
Diese Werte werden Elementen grundsätzlich erst zugeweisen.

Somit darfst du, nach deiner Aussage, gar kein Element benutzen.

Und so nebenbei:

h1 {padding-left:8em;}

ist absolut normal, zulässig, sinnvoll und praktisch.

Da ist Kai345 aber anderer Meinung:

(Spätestens hier fällt übrigens die Unsinnigkeit einer Klassenbenennung "paddingLeft8em" auf)

Kennst du den Unterschied zwischen "unsinnig" und einer Namensvorschrift?
Er wollte lediglich ausdrücken, dass es unsinnnig ist, die Grösse in den Klassennamen zu schreiben, wenn sich die Grösse ändern kann. Dann verwirrt dieser Klassenname nur.

Kann es sein, dass dir die absoluten Grundlagen fehlen? Denn all das ist im ersten Kapitel zu  CSS in Selfhtml nachzulesen!

[sigrun]

Kann es sein, dass dir die absoluten Grundlagen fehlen?

Kann es sein, dass Du nicht verstehst, was ich meine?
Was nützt eine h1-Angabe mit zusätzlicher padding-Angabe, wenn ich die Eigenschaften des h1-Elemnts gar nicht will?

Denn all das ist im ersten Kapitel zu  CSS in Selfhtml nachzulesen!

Dann zeig mir, wo eine Antwort zu meiner ursprünglichen Frage steht!

[Der Martin]

Hallo,

Kann es sein, dass dir die absoluten Grundlagen fehlen?
Kann es sein, dass Du nicht verstehst, was ich meine?
Was nützt eine h1-Angabe mit zusätzlicher padding-Angabe, wenn ich die Eigenschaften des h1-Elemnts gar nicht will?

es geht bei der Auswahl des "richtigen" Elements nicht darum, welche visuellen Eigeschaften es bei der Anzeige haben soll, sondern was es in der Dokumentstruktur darstellt.
Wenn das betreffende Element also den Charakter einer Überschrift hat, wäre h1..h6 genau die richtige Wahl; wenn es ein gewöhnlicher Textabsatz ist, wäre z.B. p geeignet.

Denn all das ist im ersten Kapitel zu  CSS in Selfhtml nachzulesen!
Dann zeig mir, wo eine Antwort zu meiner ursprünglichen Frage steht!

Für die Antwort auf deine ursprüngliche Frage sollte man zuerst mal klären: Was für eine inhaltlich-strukturelle Bedeutung haben die Elemente? Welches Merkmal führt dazu, dass du einen vom Standard abweichenden linken Rand willst?
Nach genau diesem Merkmal sollte sich dann auch die Wahl des richtigen Elements und ggf. des dazu passenden Klassennamens richten. Vielleicht genügt ja auch ein kombinierter Selektor wie h2+p oder h3+p, um die Elemente sinngemäß richtig zu erfassen, und eine Klasse ist gar nicht nötig?

So long,
 Martin

[Gunnar Bittersmann]

@@Multi:

nuqneH

BTW: Wie du eine Klasse nennst ist völlig schnurz.

Aus Sicht des Parsers vielleicht. Aus Sicht des Entwicklers keinesfalls.

Qapla'

[Multi]

Aus Sicht des Parsers vielleicht. Aus Sicht des Entwicklers keinesfalls.

Richtig. Und deshalb macht es keinen Sinn, wenn man der OP sagt, wie sie ihre Klassen nennen soll. Oder fragst du hier nach, wie du deine Klassen nennen sollst?

[Gunnar Bittersmann]

@@Multi:

nuqneH

Aus Sicht des Parsers vielleicht. Aus Sicht des Entwicklers keinesfalls.

Richtig. Und deshalb macht es keinen Sinn, wenn man der OP sagt,

… es wäre „völlig schnurz“.

Qapla'

[Multi]

Richtig. Und deshalb macht es keinen Sinn, wenn man der OP sagt,

… es wäre „völlig schnurz“.

Ok, dann erwarte ich jetzt von dir eine genaue Erklärung, wie Klassennamen auszusehen haben. Denn wenn es nicht völlig schnurz ist, gibt es dafür Vorschriften. Und die scheinst du ja zu kennen.

[Gunnar Bittersmann]

@@Multi:

nuqneH

Ok, dann erwarte ich jetzt von dir eine genaue Erklärung, wie Klassennamen auszusehen haben. Denn wenn es nicht völlig schnurz ist, gibt es dafür Vorschriften. Und die scheinst du ja zu kennen.

[ ] Und du kennst den Unterschied zwischen „Vorschrift“ und „best practice“?

Qapla'

PS: Falls nicht, dann (er)warte mal …

[Multi]

[ ] Und du kennst den Unterschied zwischen „Vorschrift“ und „best practice“?

Bist du dieses Jahr als Klugscheisser unterwegs?
Du behauptest zwar, es ist nicht egal, wie ein Klassenname lautet, bist aber nicht in der Lage, das zu begründen.

Und was für dich "best practice" ist, ist für mich "schnurz egal". Wenn du es noch nicht gemerkt hast, "best practice" ist für jeden was anderes und du glaubst nur, dass deine Meinung die einzig richtige ist.

[Gunnar Bittersmann]

@@Multi:

nuqneH

Bist du dieses Jahr als Klugscheisser unterwegs?

Same procedure as _every_ year, James.

Qapla'

[splinter]

Wenn du es noch nicht gemerkt hast, "best practice" ist für jeden was anderes und du glaubst nur, dass deine Meinung die einzig richtige ist.

Wenn wird schon beim klugscheissen sind: Eine Methode wird zur "Best Practice" wenn sie allgemein als die sinnvollste angesehen wird. Dieses "allgemein" bezieht sich insbesondere auf die "Allgemeinheit" und ganz besonders auf die Experten im entsprechenden Fachgebiet. Der Sinn davon ist eben gerade nicht dass es für jeden was anderes ist.

Ob du es glaubst oder nicht, manche seriöse Entwickler suchen ganz explizit nach solchen De-facto-Standards damit andere Entwickler ihre Codes in angemessener Zeit auch verstehen können. Ist dir wohl noch nie passiert, dass du in einem etwas grösseren Team was entwickeln durftest, sonst würdest du kaum solchen Dunst von dir geben.

Und was für dich "best practice" ist, ist für mich "schnurz egal".

K.A. wo du arbeitest aber in den Betrieben die ich kenne stehst du mit dieser Einstellung schleunigst auf der Strasse.

[Der Martin]

Hallo,

Wenn du es noch nicht gemerkt hast, "best practice" ist für jeden was anderes

ja, das sehe ich auch so: Was "best practice" ist, also das günstigste Verfahren zum Erreichen eines bestimmten Zieles, ist eine sehr subjektive Einschätzung. Natürlich kristallisieren sich auch hier Wege und Methoden heraus, für die sich mehr Befürworter finden als für andere. Das ist überall so. Das heißt aber noch lange nicht, dass diese Mehrheitseinschätzung für jeden gut ist.

Der Sinn davon ist eben gerade nicht dass es für jeden was anderes ist.

Ja, theoretisch. Praktisch scheitert sowas aber daran, dass eben nicht alle gleich denken und empfinden. Was für dich "best practice" ist, könnte für mich völlig unbrauchbar sein. Es ist nichts weiter als eine von einer Mehrheit angewendete Methode, die man mal ausprobieren sollte - es könnte ja sein, dass man selbst damit auch gut fährt. Wenn nicht, wäre es aber kontraproduktiv, trotzdem daran festzuhalten.

K.A. wo du arbeitest aber in den Betrieben die ich kenne stehst du mit dieser Einstellung schleunigst auf der Strasse.

Es sei denn, man ist der Chef. ;-)

Ciao,
 Martin

[splinter]

Hi

Wenn du es noch nicht gemerkt hast, "best practice" ist für jeden was anderes

ja, das sehe ich auch so: Was "best practice" ist, also das günstigste Verfahren zum Erreichen eines bestimmten Zieles, ist eine sehr subjektive Einschätzung. Natürlich kristallisieren sich auch hier Wege und Methoden heraus, für die sich mehr Befürworter finden als für andere. Das ist überall so. Das heißt aber noch lange nicht, dass diese Mehrheitseinschätzung für jeden gut ist.

Der Sinn davon ist eben gerade nicht dass es für jeden was anderes ist.

Ja, theoretisch. Praktisch scheitert sowas aber daran, dass eben nicht alle gleich denken und empfinden. Was für dich "best practice" ist, könnte für mich völlig unbrauchbar sein. Es ist nichts weiter als eine von einer Mehrheit angewendete Methode, die man mal ausprobieren sollte - es könnte ja sein, dass man selbst damit auch gut fährt. Wenn nicht, wäre es aber kontraproduktiv, trotzdem daran festzuhalten.

Und genau deshalb sind "Best Practices" auch keine Vorschriften sondern nur Empfehlungen. Hier kommt die zweite Bedeutung des Wortes "allgemein" ins Spiel: Im konkreten Fall gibt es natürlich meist _gute_ Gründe davon abzuweichen und damit meine ich nicht Begründungen wie "Best Practices sind mir schnurz egal".

[Multi]

"Best Practices sind mir schnurz egal".

Du solltest nochmal lesen, was ich geschrieben hab, dann merjst du evtl. dass deine Aussage und meine Aussage völlig unterschiedlich sind.

[Daniel.S]

Grüße dich, sigrun,

Welche Bezeichnung böte sich dann an?
Insbesondere, wenn ich an anderen Stellen 6em und 4em haben möchte?

Das hängt davon ab, warum bestimmte Elemente verschieden breite seitliche Innenabstände haben sollen.

Du wirst diese Gestaltung ja aus einem gewissen Zweck vornehmen. Oder etwa nicht?

Gruß, Daniel

[Gunnar Bittersmann]

@@sigrun:

nuqneH

Welche Bezeichnung böte sich dann an?

Eine, die den Inhalt des Textes beschreibt. Bspw. "lead", "hinweis", "warnung", "fehler", …

Insbesondere, wenn ich an anderen Stellen 6em und 4em haben möchte?

Daran solltest du beim Schreiben des HTML (insb. bei der Benamsung der Klassen) überhaupt nicht denken.

Qapla'

[Gunnar Bittersmann]

@@sigrun:

nuqneH

CSS:
.paddingLeft8em {padding-left:8em}
html:
<p class="paddingLeft8em">

ist doch aufwendiger und unübersichtlicher als

<p style="padding-left:8em;">.

Beides ist so ziemlich gleich schlecht, denn beides ist präsentationsbezogenes Markup.

Aber unter den schlechten Varianten ist die zweite die wohl etwas bessere. Und ehrlichere.

Qapla'

[sigrun]

Hi,

Beides ist so ziemlich gleich schlecht, denn beides ist präsentationsbezogenes Markup.

Wie mache ich es dann als "präsentationsunbezogen"?

[suit]

Beides ist so ziemlich gleich schlecht, denn beides ist präsentationsbezogenes Markup.

Wie mache ich es dann als "präsentationsunbezogen"?

Du meinst, wie du es _nicht_ präsentationsbezogen machst?

Überlege dir _warum_ du an dieser Stelle einen Abstand benötigst.

[suit]

Beides ist so ziemlich gleich schlecht, denn beides ist präsentationsbezogenes Markup.

Wie mache ich es dann als "präsentationsunbezogen"?

Du meinst, wie du es _nicht_ präsentationsbezogen machst?

Überlege dir _warum_ du an dieser Stelle einen Abstand benötigst.

Es wäre übrigens auch nicht schlecht, uns das Ergebnis zu verraten - sonst kann man schlecht helfen.

Warum sollten diese Elemente also einen Abstand erhalten? Sind sie Hinweise? Warnungen? Zitate? Anmerkungen?

[Gunnar Bittersmann]

@@suit:

nuqneH

Warum sollten diese Elemente also einen Abstand erhalten? Sind sie Hinweise? Warnungen? Zitate? Anmerkungen?

Zitate? Statt <p class="Zitat">I have a dream</p> wäre eher <blockquote><p>I have a dream</p></blockquote> (oder auch ohne 'p') sinnvoll.

Bei Hinweisen/Anmerkungen wäre je nach deren Art auch <p><small>Beachten Sie das Kleingedruckte</small></p> angebracht.

Qapla'

[Gunnar Bittersmann]

@@suit:

nuqneH

Du meinst, wie du es _nicht_ präsentationsbezogen machst?

Überlege dir _warum_ du an dieser Stelle einen Abstand benötigst.

Das wäre präsentationsbezogen. Wie sollte sich „Abstand“ nicht auf die Präsentation beziehen?

Qapla'

[suit]

Du meinst, wie du es _nicht_ präsentationsbezogen machst?

Überlege dir _warum_ du an dieser Stelle einen Abstand benötigst.

Das wäre präsentationsbezogen. Wie sollte sich „Abstand“ nicht auf die Präsentation beziehen?

No na bezieht sich der Abstand auf die Präsentation - aber das Markup darf diese Information nicht explizit enthalten.

[T-Rex]

Hallo,
ich benötige an einigen Stellen die Angabe "padding-left:8em".
Ist es da wirklich sinnvoll, dies in externe CSS-Datei auszulagern?
CSS:
.paddingLeft8em {padding-left:8em}
html:
<p class="paddingLeft8em">

ist doch aufwendiger und unübersichtlicher als

<p style="padding-left:8em;">.

Das kommt drauf an. Generell ist CSS natürlich immer besser, ich verwende an einigen Stellen jedoch trotzdem style. Das sind aber wie gesagt Ausnahme-Situationen bzw. Sonderfälle. Ein Beispiel wäre eine Überschrift. Die hat eine hübsche Klasse. Diese gibt dieser Überschrift ein Margin-Bottom: 10px. Jetzt gibt es eine einzige Stelle wo es eine Subunterschrift gibt. Dort nehme ich die Margin-Bottom per style wieder weg. Aber nur falls ich über Kaskadierung nicht den erwünschten Effekt schaffe.

Ansonsten gilt das was Kai345 gesagt hat. Mittels css zentralisierst du das Layout an einer Stelle. Du kannst durch Media Styles dein Styling diversen Medien anpassen und Browser können CSS Angaben schneller Rendern als bei jedem Element das Style aus zu lesen.

Gruß
zurück Winkender, sturer
T-Rex

[Gunnar Bittersmann]

@@T-Rex:

nuqneH

[…] Ausnahme-Situationen bzw. Sonderfälle. Ein Beispiel wäre eine Überschrift. Die hat eine hübsche Klasse. Diese gibt dieser Überschrift ein Margin-Bottom: 10px.

Den Abstand relativ zur Schriftgröße anzugeben (em oder rem) scheint mir weitaus sinnvoller zu sein als in px.

Jetzt gibt es eine einzige Stelle wo es eine Subunterschrift gibt.

Nicht etwa eine Sub_über_schrift? ;-)

So etwa?

<h2>Überschrift</h2>  
<h3>Subüberschrift</h3>

Dort nehme ich die Margin-Bottom per style wieder weg.

Warum? Du kannst doch auch die Subüberschrift per negativem Margin-top an die Überschrift heranrücken:

h2+h3 { margin-top: -10px }

Ggfs. wären die beiden auch in ein 'hgroup'-Element zu packen (abhängig von der gewünschten Outline):

<hgroup>  
  <h2>Überschrift</h2>  
  <h3>Subüberschrift</h3>  
</hgroup>

Dann geht auch

hgroup h2 { margin-bottom: 0 }

Qapla'

[suit]

Den Abstand relativ zur Schriftgröße anzugeben (em oder rem) scheint mir weitaus sinnvoller zu sein als in px.

Kommt drauf an :) wenn der Text z.B. passend zur Hintergrundgrafik eingerückt sein soll und diese "irgendwas in einem bestimmten Pixel-Abstand" hat, dann sind px wohl besser geeignet als em oder ex :)

[Gunnar Bittersmann]

@@suit:

nuqneH

Den Abstand relativ zur Schriftgröße anzugeben (em oder rem) scheint mir weitaus sinnvoller zu sein als in px.

Kommt drauf an :) wenn der Text z.B. passend zur Hintergrundgrafik eingerückt sein soll und diese "irgendwas in einem bestimmten Pixel-Abstand" hat, dann sind px wohl besser geeignet als em oder ex :)

_Den_ Abstand, nicht irgendeinen Abstand. Und mit _dem_ Abstand meinte ich schon T-Rex seinen* zwischen Überschrift und Subüberschrift.

Qapla'

* Das ist der Berliner Jenitiv. ;-)

[suit]

_Den_ Abstand, nicht irgendeinen Abstand. Und mit _dem_ Abstand meinte ich schon T-Rex seinen* zwischen Überschrift und Subüberschrift.

Und was ist, wenn deine hgroup ein tolles Hintergrundbild hat? :p

* Das ist der Berliner Jenitiv. ;-)

"Dem T-Rex der seine" würde[1] man hierzulande sagen :p

[1] mit Konjunktiv II, Alpen-Style :p

[Matthias Apsel]

Om nah hoo pez nyeetz, T-Rex!

Das kommt drauf an. Generell ist CSS natürlich immer besser, ich verwende an einigen Stellen jedoch trotzdem style.

was natürlich trotzdem CSS ist ;-)

Manchmal geht es auch nicht unter Verwendung von Klassen Feriendichte, dort die Deutschlandkarte.

Matthias

[Jeena Paradies]

Hallo,

Das kommt drauf an.

Nope.

Generell ist CSS natürlich immer besser,

Hier hättest du einfach "Generell ist" weglassen sollen und nach "besser" einen punkt hinmachen sollen.

ich verwende an einigen Stellen jedoch trotzdem style.

Und das ist falsch.

Das sind aber wie gesagt Ausnahme-Situationen bzw. Sonderfälle.

Das ist das erste was ich meinen Untergebenen abgewöhne. Wenn ich so was im code finde rufe ich sie erst mal zu mir und lasse sie vor allen einen sinnvollen klassennamen oder eine sinvolle Kaskade finden. Die meisten kappieren dann spätestens nach dem zweiten mal warum. Ich lasse sie das nicht mal zu testzwecken einsetzen, denn diese Testzwecke schlüpfen dann irgendwann in den richtigen Code durch und ein paar Monate später soll ich selbst an dieser stelle etwas ändern und verliere dann jedes mal einen Haufen Zeit weil es wieder mal irgendwo in den tiefen der HTML-Templates versteckt ist anstatt in der zentral in der einen CSS datei in der ich es suche.

Jetzt gibt es eine einzige Stelle wo es eine Subunterschrift gibt.

Es ist nie so dass es nur eine einzige Stelle gibt, vor allem kannst du nicht wissen wie das in der Zukunft sein wird wenn irgend jemandem einfällt etwas zu verändern. Deshalb sollte man sich das ganze einfach komplett abgewöhnen, denn es geht ja auch nicht schneller oder bequemer das ins style attribut zu schreiben als in die CSS-Datei.

Aber nur falls ich über Kaskadierung nicht den erwünschten Effekt schaffe.

Und genau das kann man grundsätzlich immer, wenn nicht dann kann man immer noch eine sinnvolle Klasse einfügen.

Jeena

[Steel]

Hm.

Ich MUSS z.B. mit inline styles arbeiten. Eine andere Option habe ich nicht. (MS Sharepoint)

[Jeena Paradies]

Hallo,

Ich MUSS z.B. mit inline styles arbeiten. Eine andere Option habe ich nicht. (MS Sharepoint)

Naja MS Sharepoint ist aber schon mal sowieso nicht web von Daher sollte man das auch nicht allzusehr miteinander vermischen.

Jeena

[Jeena Paradies]

Hallo,

Hallo,

ich benötige an einigen Stellen die Angabe "padding-left:8em".
Ist es da wirklich sinnvoll, dies in externe CSS-Datei auszulagern?

Ja.

Es geht darum den Inhalt vom Aussehen komplett abzukoppeln damit man den gleichen Inhalt (HTML) für verschiedene Ausgabegeräte komplett anders und sinnvoll formatieren kann (CSS).

Dein Beispiel ist z.b. auf dem iPhone völlig unnütz, denn da würde dann nur noch die hälfte des sowieso sehr engen Bildschirms für die Ausgabe bleiben.

Besser ist es die Klassen nach dem Inhalt zu benennen. Da du leider nicht sagst was das für Inhalt ist können alle hier nur raten und ranten, ohne dass sie dir auch nur im Ansatz weiterhelfen. Ich mache mal ein kleines Beispiel:

Nehmen wir an du möchtest eine Warnung immer mit einem margin von 8em nach links haben, zumindest auf dem normalen Desktop, dann wäre dein HTML so aussehen:

<article>  
 <p>Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor</p>  
 <p>Incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis</p>  
 <p class="warning"><strong>Warnung:</strong> Achtung! Dies ist eine Warnung.</p>  
 <p>Nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat.</p>  
 <ul>  
  <li>Duis</li>  
  <li>aute</li>  
  <li>irure</li>  
 </ul>  
 <p>Dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla</p>  
 <p class="warning"><strong>Warnung:</strong> Noch eine Warnung.</p>  
 <p>Pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui</p>  
 <p>Officia deserunt mollit anim id est laborum.</p>  
</article>

Dies ist das HTML, nirgendwo steht irgend etwas darüber wie es aussehen soll. Das Aussehen wird grundsätzlich _immer_ über eine externe CSS-Datei gesteuert. Ich habe immer verschiedene Dateien für verschiedene Media-Typen, die da zur zeit meist wären "screen" für normale Desktop-Bildschirme, "print" für Drucker und dann noch mit ein paar kleineren Tricks etwas für "handheld" Devices wie z.b. das iPhone. Die einzelnen Dateien könnten dann so aussehen (ich schreibe da nur das CSS für die Warnung rein, das andere kann man sich ja dazu denken):

/* screen.css */  
.warning {  
 color: red;  
 margin-left: 8em;  
 border: 1px solid red;  
}

/* iphone.css */  
.warning {  
 color: red;  
 margin-left: 2em; /* auf dem iPhone gibt es nicht all zu viel Platz */  
 border: 1px solid red;  
}

/* print.css */  
.warning {  
 color: black; /* die meisten Drucker drucken Schwarz-Weiß */  
 margin-left: 8em;  
 border: thin dashed black; /* Die rote dünne Linie würde nicht auffallen */  
}

Dadurch dass man einen sinnvollen Klassennamen (am besten auch in Englisch) wählt, versteht jeder der den code anschaut was das ganze tun soll, auch man selbst, wenn man 5 Jahre später daran etwas ändern müsste. Und man kann, falls neue Anzeigegeräte mit der Zeit auftauchen, einfach nur eine zusätzliche CSS-Datei dazu machen ohne den HTML code auch nur anzufassen, vor allem an den Stellen die man sowieso komplett vergessen hat.

Jeena

[Steel]

So schoen geschrieben.
*me likes*

[Gunnar Bittersmann]

@@Jeena Paradies:

nuqneH

<p class="warning"><strong>Warnung:</strong> Achtung! Dies ist eine Warnung.</p>

Hier stellt sich noch die Frage, ob "Warnung:" ins Markup gehört oder bei

<p class="warning">Achtung! Dies ist eine Warnung.</p>

per CSS

.warning:before { content: "Warnung: "; font-weight: bold }

hinzugefügt wird.

L10n:

.warning:lang(en):before { content: "Warning: " }  
.warning:lang(pl):before { content: "Ostrzeżenie: " }

Ich habe immer verschiedene Dateien für verschiedene Media-Typen

Warum? Es dürfte meist sinnvoller sein, alles per @media-Regeln in einem Stylesheet zu notieren.

und dann noch mit ein paar kleineren Tricks etwas für "handheld" Devices wie z.b. das iPhone.

Das iPhone reagiert auf @media(handheld)?

Qapla'

[Christopher]

Hallo,

.warning:before { content: "Warnung: "; font-weight: bold }

Interessant. Aber in Sachen Mehrsprachigkeit faellt einem das natuerlich vor die Fuesze.

Grusz,
Christopher

[Gunnar Bittersmann]

@@Christopher:

nuqneH

.warning:before { content: "Warnung: "; font-weight: bold }
Interessant. Aber in Sachen Mehrsprachigkeit faellt einem das natuerlich vor die Fuesze.

Nein.

[ ] Du hast mein Posting bis zuende gelesen?

Qapla'

[Christopher]

Hallo,

.warning:before { content: "Warnung: "; font-weight: bold }
Interessant. Aber in Sachen Mehrsprachigkeit faellt einem das natuerlich vor die Fuesze.
[ ] Du hast mein Posting bis zuende gelesen?

Oh 'tschuldigung. Das hatte ich, aber den i18n-Part wohl uebersehen.
Dennoch sind CSS-Files fuer Localization wohl nicht unbedingt der richtige Platz.

Grusz,
Christopher

[Gunnar Bittersmann]

@@Christopher:

nuqneH

Dennoch sind CSS-Files fuer Localization wohl nicht unbedingt der richtige Platz.

Stylesheets sind bei mehrsprachigen Websites ohnehin voll von i18n/l10n. Bspw. verschiedene Schriftengrößen und Zeilenhöhen für verschiedene Schriften: komplexe CJK-Zeichen müssen größer dargestellt werden als lateinische, griechische, kyrillische, … Buchstaben. Thailandische Zeichen verlangen einen größeren Zeilenabstand.

RTL-Schriften erfordern einiges an Spiegelei (womit nicht das Gelbe vom Ei gemeint ist). Und von oben nach unten geschriebene Schriften erst …

In anderen Kulturkreise habne Farben andere Symbolik, so dass evtl. Hintergrundfarben lokalisiert werden. Und Hintergrundbilder. Letzters umfasst nicht nur kulturell evtl. unpassende Bilder, sondern auch gespiegelte Icons für Seiten in RTL-Schriften.

„Nicht unbedingt der richtige Platz“ ist nicht unbedingt das richtige Argument, ob "Warnung:" im Markup oder im Stylesheet stehen sollte.

Die Frage ist, ob "Warnung:" zum Inhalt dazugehört. Was, wenn in Zukunft Warnungen mit einem dicken fetten roten Rahmen versehen werden, womit sie hinreichend hervorgehoben sind und "Warnung:" nicht mehr erschienen soll? Wenn’s im Stylesheet steht, kein Problem. Wenn’s im Markup steht, wird’s aufwendig.

Und wenn dir der Gedanke, bei hinzukommenden Sprachen das Stylesheet erweitern zu müssen, nicht gefällt, kannst du ja das Stylesheet per PHP generieren:

<?php  
[code lang=php]$strings = array(  
  'de' => array(  
    'warning' => 'Warnung: ',  
    // …  
  ),  
  'en' => array(  
    'warning' => 'Warning: ',  
    // …  
  ),  
  'pl' => array(  
    'warning' => 'Ostrzeżenie: ',  
    // …  
  ),  
);

?>

<?php foreach ($strings as $language=>$localized): ?>
  .warning:lang(<?php echo $language; ?>):before { content: "<?php echo $localized['warning']; ?>" }
<?php endforeach; ?>[/code]

Qapla'

[Christopher]

Hallo Gunnar,

dass Stylesheets an sich Lokalisierungen enthalten ist klar.
Mir ging es eigentlich einzig um die i18n-Strings innerhalb der CSS.. und zwar, dass die dort nichts zu suchen haben.
Denn einer Uebersetzungsagentur wird man schlieszlich keine CSS-Files ausliefern wollen.

Grusz,
Christopher

[Gunnar Bittersmann]

@@Christopher:

nuqneH

dass Stylesheets an sich Lokalisierungen enthalten ist klar.
Mir ging es eigentlich einzig um die i18n-Strings innerhalb der CSS.. und zwar, dass die dort nichts zu suchen haben.

Deshalb mein Vorschlag, das Stylesheet serverseitig zu generieren und das vorhandene String-Array zu verwenden.

(Hm, ich hätte wohl deutlich erwähnen sollen, dass sich der PHP-Block '$strings = array(…);' nicht im Stylesheet befindet, sondern per include() oder require() (bzw. deren …-once-Varianten) eingebunden wird.)

Denn einer Uebersetzungsagentur wird man schlieszlich keine CSS-Files ausliefern wollen.

Das sicher nicht.

Das $string-Array vielleicht auch nicht. Aber das muss man sich sowieso erstellen.

Qapla'

[Christopher]

Hallo,

hm, also ich kann mich nicht damit anfreunden, dass i18n was in CSS-Files zu suchen hat.
Aehnlich wie beim Markup und Design sollte m.M.n. auch hier eine klare Trennung vorliegen.

Grusz,
Christopher

[Kai345]

[latex]Mae  govannen![/latex]

Hier stellt sich noch die Frage, ob "Warnung:" ins Markup gehört oder bei

[...]

per CSS

[...]

hinzugefügt wird.

Ich würde das doch tendenziell eher als Teil des Inhalts sehen -> Markup

Stur lächeln und winken, Männer!
Kai

[Matthias Apsel]

[latex]Om\ nah\ hoo\ pez\ nyeetz,\ {\it Kai345!}[/latex]

Ich würde das doch tendenziell eher als Teil des Inhalts sehen -> Markup

Wenn man sich in unserem SELFHTML-Wiki mal die Vorlage {{Achtung}} anschaut, spricht es für CSS.

Matthias

[Kai345]

[latex]Mae  govannen![/latex]

[latex]Om\ nah\ hoo\ pez\ nyeetz,\ {\it Kai345!}[/latex]

Ich würde das doch tendenziell eher als Teil des Inhalts sehen -> Markup

Wenn man sich in unserem SELFHTML-Wiki mal die Vorlage {{Achtung}} anschaut, spricht es für CSS.

Inwiefern? Der Text „Achtung!“ ist auf dieser Seite Teil des Markups.

Ohne CSS würde der Text „Warnung!“ bzw. in obigem Fall „Achtung!“ unter den Tisch fallen. Man möchte den Besucher auf einen besonderen Umstand aufmerksam machen, also ist es Inhalt und somit Markup.

Stur lächeln und winken, Männer!
Kai

[Gunnar Bittersmann]

@@Kai345:

nuqneH

Ich würde das doch tendenziell eher als Teil des Inhalts sehen -> Markup

Ja, vielleicht. Vielleicht aucht nicht.

Qapla'

[Kai345]

[latex]Mae  govannen![/latex]

Ich würde das doch tendenziell eher als Teil des Inhalts sehen -> Markup

Ja, vielleicht. Vielleicht aucht nicht.

Eher doch.

Stur lächeln und winken, Männer!
Kai

[MudGuard]

Hi,

[latex]Mae  govannen![/latex]

Hier stellt sich noch die Frage, ob "Warnung:" ins Markup gehört oder bei
[...]
per CSS
[...]
hinzugefügt wird.
Ich würde das doch tendenziell eher als Teil des Inhalts sehen -> Markup

Die Frage dabei ist doch einfach: soll das "Warnung:" auch dann sichtbar sein, wenn kein CSS zur Verfügung steht?

cu,
Andreas

[Jeena Paradies]

Hallo,

<p class="warning"><strong>Warnung:</strong> Achtung! Dies ist eine Warnung.</p>
Hier stellt sich noch die Frage, ob "Warnung:" ins Markup gehört oder bei
<p class="warning">Achtung! Dies ist eine Warnung.</p>
.warning:before { content: "Warnung: "; font-weight: bold }

.warning:lang(en):before { content: "Warning: " }

.warning:lang(pl):before { content: "Ostrzeżenie: " }

  
Welchen Vorteil hat das? Wenn ich die Inhalte sowieso in einer anderen Sprache bereitstellen muss dann biete ich da auch an dieser Stelle das Wort "Warnung" in dieser Sprache an. Just in diesem Konkreten Beispiel erscheint es mir eher ein Esoterischer Einwand von wegen l18n-in-CSS zu sein.  
  

> > Ich habe immer verschiedene Dateien für verschiedene Media-Typen  
> Warum? Es dürfte meist sinnvoller sein, alles per `@media`{:.language-css}-Regeln in einem Stylesheet zu notieren.  

Naja erstens werden dann auch die unnützen Daten von allen Geräten heruntergeladen (wobei ich mir nicht ganz sicher bin ob das nicht in der Praxis sowieso gemacht wird) und ansonsten ja, es ist schon ein kompliziertes Biest das richtig zu machen. Ich muss gestehen dass ich das wohl vor allem deshalb aufteile weil ich dann beim deployen sowieso mit einem [Preprozessor drübergehe](http://guides.rubyonrails.org/asset_pipeline.html) der mir alles sinnvoll in große Dateien verpackt und das dann auch gleich minimalisiert.  
  

> > und dann noch mit ein paar kleineren Tricks etwas für "handheld" Devices wie z.b. das iPhone.  
> Das iPhone reagiert auf `@media(handheld)`{:.language-css}?  

Nope, leider nicht, das habe ich auch nicht geschrieben. Deshalb "mit ein paar kleinen Tricks", trotzdem empfinde ich das iPhone als "handheld device".  
  
   Jeena  
![](http://jeenaparadies.net/pavatar.png)

-- 
[Jlog](http://jeenaparadies.net/webdesign/jlog/) | [Gourmetica Mentiri](http://jeenaparadies.net/gourmetica-mentiri/)

[Gunnar Bittersmann]

@@Jeena Paradies:

nuqneH

Dadurch dass man einen sinnvollen Klassennamen (am besten auch in Englisch) wählt

Warum in Englisch?

Bei einem international zusammengesetzten Team ist das sicher eine gute Wahl. Ansonsten können Klassennamen auch deutsch, polnisch, chinesisch, … sein. Man sollte aber konsequent bei einer Sprache bleiben.

Qapla'

[Jeena Paradies]

Hallo,

Warum in Englisch?
Bei einem international zusammengesetzten Team ...

Genau, und man weiß nie mit wem man in Zukunft zusammen arbeiten wird, deshalb sollte man es sich von Anfang an angewöhnen alles was mit Programmieren zu tun (Außer vielleicht Dokumentationen) hat immer in Englisch zu machen, es hat schon seinen Grund dass "die IT" eine gemeinsame Grundsprache hat, Englisch.

Und wozu die sachen dann bei den Klassennamen anders machen wenn in HTML und CSS alle Tags, Pseudoklassen, Attribute, etc. sowieso schon in Englisch geschrieben werden müssen? Das schafft nur allgemeine Verwirrung.

Jeena

[Gunnar Bittersmann]

@@Jeena Paradies:

nuqneH

Warum in Englisch?
Bei einem international zusammengesetzten Team ...
Genau, und man weiß nie mit wem man in Zukunft zusammen arbeiten wird, […]

Für Europa mag das valide sein …

[…] deshalb sollte man es sich von Anfang an angewöhnen alles was mit Programmieren zu tun (Außer vielleicht Dokumentationen) hat immer in Englisch zu machen

… in anderen Teilen der Welt (China, Japan, …) könnte das anders aussehen.

Und warum nimmst du Dokumentationen dann raus? Bei einem internationalen Team sollten die auch von allen gelesen werden können.

Qapla'

[Jeena Paradies]

Hallo,

… in anderen Teilen der Welt (China, Japan, …) könnte das anders aussehen.

Ich arbeite ziemlich viel direkt mit Ingenieuren aus China und Indien zusammen, das scheint dort auch ziemlich normal zu sein dass die alle zumindest gut englisch lesen und schreiben können und ich habe von dort noch nie irgendwelche programmierten sachen in Chinesisch oder Indisch zurück bekommen auch wenn das in z.b. Java, Ruby und anderen Sprachen die im Quellcode UTF-8 unterstützen durchaus möglich wäre.

Und warum nimmst du Dokumentationen dann raus? Bei einem internationalen Team sollten die auch von allen gelesen werden können.

Ich muss zugeben ich schreibe alle meine Dokumentationen nur auf Englisch, aber ich sehe ein dass zusätzliche Dokumentation in anderen Sprachen Leuten den Einstieg erleichtern können. Deshalb hätte ich sie gerne rausgenommen.

Jeena