Befehlshilfe!!

[Timo Groß]

Hallo,

bin gerade dabei eine vorhandene CSS Datei zu ändern und bin auf den Befehl margin:1em; gestoßen und weiß nicht was dieser Befehl bewirkt!
Er steht in diesem Befehlsabschnitt:

BODY {
  font-family:Tahoma,Verdana,Arial,Helvetica,sans-serif;
  font-size:9pt;
  margin:1em;
  background-color:white;
  color:#333333;
}

Bin leider noch nicht so erfahren in css, deswegen benötige ich Eure hilfe. Danke im Voraus

Timo

[at]

Hallo.

bin gerade dabei eine vorhandene CSS Datei zu ändern und bin auf den Befehl margin:1em; gestoßen und weiß nicht was dieser Befehl bewirkt!

Eine ausführliche Referenz findest du in SelfHTML, daher nur so viel: "margin" ist der Außenabstand, "em" eine relative Maßeinheit, "1" deren Multiplikator.
MfG, at

[MudGuard]

Hi,

bin gerade dabei eine vorhandene CSS Datei zu ändern und bin auf den Befehl margin:1em; gestoßen und weiß nicht was dieser Befehl bewirkt!
Er steht in diesem Befehlsabschnitt:

CSS hat keine Befehle, sondern Eigenschaften.
Daher gibt es auch keine Befehlsabschnitte...

margin bewirkt (wie der Name ja schon andeutet) einen Rand - und zwar im Gegensatz zu padding einen Rand außerhalb des Elements.
margin:1em bewirkt also einen Außenrand in der Breite 1em, so breit wie eine Zeichenhöhe der für das Element gültigen Schrift.

cu,
Andreas

[Michael Jendryschik]

Hallo,

Er steht in diesem Befehlsabschnitt:

CSS hat keine Befehle, sondern Eigenschaften.

Ein »Befehl« wie 'margin:1em;' ist jedenfalls keine Eigenschaft.

margin bewirkt (wie der Name ja schon andeutet) einen Rand - und zwar im Gegensatz zu padding einen Rand außerhalb des Elements.

Das ist ungenau formuliert. Block-Elemente erzeugen eine sogenannte »Principal Block Box«. Diese wiederum enthält unter anderem einen Margin-Bereich. Gehört dieser nun zu dem Element oder befindet er sich, wie du schreibst, außerhalb des Elements? Ich denke, ersteres.

Gruß,

MI

[MudGuard]

Hi,

CSS hat keine Befehle, sondern Eigenschaften.
Ein »Befehl« wie 'margin:1em;' ist jedenfalls keine Eigenschaft.

Aber ein Befehl ist es auch nicht.
Es ist eine Deklaration. (laut Grammatik zu CSS, Anhang D des CSS-2-Standards, siehe auch http://www.w3.org/TR/REC-CSS2/grammar.html)

margin bewirkt (wie der Name ja schon andeutet) einen Rand - und zwar im Gegensatz zu padding einen Rand außerhalb des Elements.
Das ist ungenau formuliert. Block-Elemente erzeugen eine sogenannte »Principal Block Box«. Diese wiederum enthält unter anderem einen Margin-Bereich. Gehört dieser nun zu dem Element oder befindet er sich, wie du schreibst, außerhalb des Elements? Ich denke, ersteres.

Er gehört zum Element, befindet sich aber außerhalb (und hat deshalb z.B. keine HIntergrundfarbe...)

cu,
Andreas

[Michael Jendryschik]

Hallo,

Ein »Befehl« wie 'margin:1em;' ist jedenfalls keine Eigenschaft.

Aber ein Befehl ist es auch nicht.
Es ist eine Deklaration.

Daher ist die Aussage

| CSS hat keine Befehle, sondern Eigenschaften.

ziemlich unsinnig, ähnlich wie: »XML hat keine Befehle, sondern Attribute.«

Block-Elemente erzeugen eine sogenannte »Principal Block Box«. Diese wiederum enthält unter anderem einen Margin-Bereich. Gehört dieser nun zu dem Element oder befindet er sich, wie du schreibst, außerhalb des Elements? Ich denke, ersteres.

Er gehört zum Element, befindet sich aber außerhalb (und hat deshalb z.B. keine HIntergrundfarbe...)

Wo hört das Element deiner Ansicht nach auf? Gehört der Border-Bereich noch zum Element, oder befindet er sich schon außerhalb?

Gruß,

MI

[MudGuard]

Hi,

Wo hört das Element deiner Ansicht nach auf? Gehört der Border-Bereich noch zum Element, oder befindet er sich schon außerhalb?

M.E. gehört die Border noch dazu.
Und die Programmierer des Mozilla sehen das wohl ähnlich bzw. genauso.
Bei einem div mit breitem Margin und breiter Border (breit deswegen, weil man dann leichter sieht, wo man ist), wirkt sich :hover genau dann aus, wenn sich der Mauszeiger auf oder innerhalb der border befindet. Befindet er sich über dem Margin, werden die :hover-Formatierungen NICHT angewendet.

cu,
Andreas

[MudGuard]

Hi,

Daher ist die Aussage
| CSS hat keine Befehle, sondern Eigenschaften.
ziemlich unsinnig, ähnlich wie: »XML hat keine Befehle, sondern Attribute.«

Nein.
Die jeweils erste Aussage ("CSS hat keine Befehle" bzw. "XML hat keine Befehle") ist wahr.
Die jeweils zweite Aussage ("CSS hat Eigenschaften" bzw. "XML hat Attribute") ist ebenfalls wahr.

Die Aussage mag unvollständig sein, aber falsch ist sie nicht.

cu,
Andreas

[Michael Jendryschik]

Hallo,

Daher ist die Aussage
| CSS hat keine Befehle, sondern Eigenschaften.
ziemlich unsinnig, ähnlich wie: »XML hat keine Befehle, sondern Attribute.«

Nein.
Die jeweils erste Aussage ("CSS hat keine Befehle" bzw. "XML hat keine Befehle") ist wahr.
Die jeweils zweite Aussage ("CSS hat Eigenschaften" bzw. "XML hat Attribute") ist ebenfalls wahr.

Die Aussage mag unvollständig sein, aber falsch ist sie nicht.

Ich habe geschrieben, dass sie *unsinnig* ist, nicht dass sie falsch ist. Je mehr ich allerdings über

| CSS hat keine Befehle, sondern Eigenschaften.

nachdenke, desto mehr bin ich der Ansicht, dass die Aussage auch falsch ist oder zumindest so nicht gesagt werden sollte. Der Satz suggeriert, dass man bei CSS, anstatt von Befehlen zu sprechen, immer von Eigenschaften spricht. Aus dem Satz

»Mit dem Befehl 'border: 1px solid' zeichnet man einen ... Rahmen.«

würde dann

»Mit der Eigenschaft 'border: 1px solid' zeichnet man einen ... Rahmen.«

werden. Sprachliche Ungenauigkeiten sind damit nicht wirklich behoben. Ich halte es daher so, dass ich der Bezeichnung »Befehl« widerspreche und auf Quellen verweise, die das Vokabular ausreichend erläutern, meistens die entsprechenden Abschnitte meiner Einführung. Mit hingeworfenen Aussagen wie »x hat keine y, sondern z« ist keinem geholfen, schon gar nicht Anfängern, die von »CSS-Befehlen« sprechen.

Gruß,

MI

[molily]

Hallo,

CSS hat keine Befehle, sondern Eigenschaften.
Ein »Befehl« wie 'margin:1em;' ist jedenfalls keine Eigenschaft.

Aber ein Befehl ist es auch nicht.
Es ist eine Deklaration.

Haha, lustig, vor allem wenn man versucht, diesen aus sich selbst heraus nichtssagenden Terminus Technicus ins Deutsche zu übersetzen, denn das, was in den CSS-Specs mit »declaration« gemeint ist, findet in »Deklaration« sicherlich keine Entsprechung. Das Wort »Deklaration« hatte nie die Bedeutung, die man in es hineinlegt, wenn man es als Übersetzung für »declaration« im CSS-Kontext gebraucht. Das Abbilden von »declaration« auf »Deklaration« ist, wie man so schön sagt, arbiträr, denn die ursprüngliche Bedeutung von »Deklaration« wurde ignoriert. Es ist letztlich ein Kunstwort genau wie »Selektor«.

Wie würde man also die wirkliche, gemeinte Bedeutung von »declaration« übersetzen? (Eventuell normative, entscheidende) »Angabe« gibt den Sinngehalt nicht unbedingt wieder. Vielleicht kommt man sogar auf »Zuordnung«, »Zuweisung« (Eigenschaft->Wert)? So sehr man auf den korrekten Begriffen herumreitet, für einen Anfänger liegt das Wort »Befehl« diesen nicht fern, und zwar selbst wenn das Konzept von Statements, Regeln, Selektoren und Deklarationsblöcken einerseits und Eigenschaften und Eigenschaftswerten andererseits verinnerlicht wurde, ohne zwangsläufig mit diesen Begriffen umzugehen.

Die offizielle deutsche Version der Specs übersetzt »statement« (Oberbegriff für @-rules und rule sets) mit »Anweisung«, das schreit nach Merkbefreiung, wie kann man da bei »Deklaration« eine treffende Übersetzung erwarten, die nicht sich nicht in an sich inhaltslosen Neologismen verliert...

Mathias

[Michael Jendryschik]

Hallo,

CSS hat keine Befehle, sondern Eigenschaften.
Ein »Befehl« wie 'margin:1em;' ist jedenfalls keine Eigenschaft.

Aber ein Befehl ist es auch nicht.
Es ist eine Deklaration.

Haha, lustig, vor allem wenn man versucht, diesen aus sich selbst heraus nichtssagenden Terminus Technicus ins Deutsche zu übersetzen, denn das, was in den CSS-Specs mit »declaration« gemeint ist, findet in »Deklaration« sicherlich keine Entsprechung.

»to declare« lässt sich mit »deklarieren« übersetzen, »declaration« im technischen Zusammenhang u.a. mit »Deklaration«, eine Bezeichnung, die sich in der deutschen Sprache als Fachterminus durchgesetzt hat und imo auch verständlich ist. Ich sehe dein Problem nicht.

Das Wort »Deklaration« hatte nie die Bedeutung, die man in es hineinlegt, wenn man es als Übersetzung für »declaration« im CSS-Kontext gebraucht. Das Abbilden von »declaration« auf »Deklaration« ist, wie man so schön sagt, arbiträr, denn die ursprüngliche Bedeutung von »Deklaration« wurde ignoriert.

Was ist denn, deiner Ansicht nach, die ursprüngliche Bedeutung? Du fragst ja selbst:

Wie würde man also die wirkliche, gemeinte Bedeutung von »declaration« übersetzen?

Ist dir die »ursprüngliche Bedeutung« klar, du kannst sie nur nicht in Worte fassen?

So sehr man auf den korrekten Begriffen herumreitet, für einen Anfänger liegt das Wort »Befehl« diesen nicht fern, und zwar selbst wenn das Konzept von Statements, Regeln, Selektoren und Deklarationsblöcken einerseits und Eigenschaften und Eigenschaftswerten andererseits verinnerlicht wurde, ohne zwangsläufig mit diesen Begriffen umzugehen.

Wer zwischen all diesen unterschiedlichen Bestandteilen der CSS-Grammatik konzeptionell unterscheidet, wird es auch sprachlich tun wollen. Genau deswegen gibt es Bezeichungen. Ich sehe keinen Grund, diese nicht zu verwenden.

Gruß,

MI

[molily]

Hallo Michael,

[...] das, was in den CSS-Specs mit »declaration« gemeint ist, findet in »Deklaration« sicherlich keine Entsprechung.

»to declare« lässt sich mit »deklarieren« übersetzen,

Natürlich ist es unter dem Umstand möglich, dass die von der allgemeinen Bedeutung abgehobene spezielle Bedeutung von »deklarieren« als Fachbegriff gemeint ist. Dem allgemeinen Verständnis nach ist diese Übersetzung aber sinnverfälschend bzw. widersinnig. Das englische »declare« hat mit dem deutschen »deklarieren« höchstens die lateinischen Wurzeln gemeinsam. »Declare« wird im Englischen in anderen Zusammenhängen als das deutsche »deklarieren« verwendet, obwohl der Ursprung derselbe ist. Für diese Bedeutungsnuancen gibt es spezielle deutsche Wörter, es zeigen also mehrere deutsche Wörter auf ein englisches Wort bzw. umgekehrt. »Deklarieren« ist eines davon.
Nun stehen allgemeine und fachspezifische Bedeutung im Englischen nahe beieinander, im Deutschen m.M.n. nicht. »Deklarieren« verbessert das Verständnis des Gemeinten nicht, es ist in diesem Fall 1:1-Denglisch ohne Hintergedanken, keine deutsche Erklärung/Umschreibung für den Sinngehalt von »declaration«. Bei der Abbildung auf den deutschen Fachbegriff war die transparente Bedeutungswiedergabe durch ein gewöhnliches Wort kein Kriterium.

»declaration« [lässt sich] im technischen Zusammenhang u.a. mit »Deklaration« [übersetzen], eine Bezeichnung, die sich in der deutschen Sprache als Fachterminus durchgesetzt hat und imo auch verständlich ist. Ich sehe dein Problem nicht.

Ja, im technischen Zusammenhang lässt es sich mit »Deklaration« übersetzen, weil die Bedeutung des deutschen »Deklaration« dahingehend ausgeweitet wurde, dass es im EDV-Bereich eine bestimmte Sonderbedeutung hat, welche, wie gesagt, mit der alltäglichen Bedeutung wenig gemein hat. Es ist tatsächlich als Fachterminus bereits etabliert und die CSS-Spec greift dies nur auf. Ich kritisiere daran lediglich, dass der Fachterminus aus seinem Kontext entnommen nichtssagend beziehungsweise irreführend ist. Das soll heißen, dass ein Anfänger lernt, eine Deklaration »Deklaration« zu nennen, weil es eben der korrekte Fachbegriff dafür »Deklaration« ist - das Wort selbst kennt er aber, wenn überhaupt, nur aus anderen Zusammenhängen und warum speziell dieses Wort treffend ist, bleibt im Dunkeln, weil, anders als im Englischen, keine offensichtliche Verbindung zu den Wortursprüngen existiert, welche das Verständnis fördern würde. Für ihn scheint es also so, als hätte man eine Deklaration auch, um eine bekanntes Beispiel zu bemühen, »Spunk« nennen können.

Es geht mir darum, zu bezweifeln, dass jeder Deutschsprachige, der sich mit CSS beschäftigt, auch den äquivalenten »offiziellen« deutschen Fachterminus verwenden soll/muss, denn das Verständnis erleichtert er meiner Meinung nach nicht sonderlich. (Bei HTML sehe ich solche Probleme nicht, dort lässt sich declaration auch vergleichsweise bedenkenlos mit »Angabe« übersetzen, beispielsweise bei document type declaration, und eine XML declaration lässt sich auch als das Dokument einleitende Verarbeitungsanweisung - wie weit liegen »instruction« und »Befehl« wohl auseinander? ;-) - an den Parser beschreiben, welche grundsätzliche Angaben zum XML-Dokument enthält.) Beispielsweise sehe ich durchaus einen Sinn und keine Willkür oder schlichtes Unwissen darin, dass Selfhtml (und andere, unbedeutendere Dokus) durchgängig »Definition« anstelle von »Deklaration« verwendet (dagegen lassen sich auch Argumente finden, ohne Frage). Wer natürlich davon überzeugt ist, dass jede Doku, die sich nicht an die W3C-Terminologie hält, des Teufels ist, wird auch nicht Vor- und Nachteile abwägen können.

Das Wort »Deklaration« hatte nie die Bedeutung, die man in es hineinlegt, wenn man es als Übersetzung für »declaration« im CSS-Kontext gebraucht. Das Abbilden von »declaration« auf »Deklaration« ist, wie man so schön sagt, arbiträr, denn die ursprüngliche Bedeutung von »Deklaration« wurde ignoriert.

Was ist denn, deiner Ansicht nach, die ursprüngliche Bedeutung?

Die ursprüngliche, nicht-technische Bedeutung von Deklaration würde ich mit »Erklärung« in einem bestimmten Kontext, in einem bestimmten Sinne auch »Angabe«, daneben etwa »Verlautbarung« umschreiben.

Onkel Duden sagt:

1. Erklärung [die etwas Grundlegendes enthält].
2. a) abzugebende Meldung gegenüber den Außenhandelsbehörden (meist Zollbehörden) über Einzelheiten eines Geschäftes; b) Inhalts-, Wertangabe (z.B. bei einem Versandgut).

(»Meldung« verallgemeinert klingt an sich als mögliche Teilbedeutung nicht schlecht...)
Bzw. im Wörterbuch:

1. [feierliche, öffentliche] Erklärung grundsätzlicher Art, die von einer Regierung, einem Staat, einer Organisation od. von mehreren Staaten od. Organisationen [gemeinsam] abgegeben wird: die D. der Menschenrechte.
2. a) Zoll-, Steuererklärung; b) (Wirtsch.) Inhalts-, Wertangabe [bei einem Versandgut].

Declaratio/declarare gibt auch nicht mehr als erklären, kundgeben, ausrufen her.

Das hilft uns natürlich prächtig weiter, weil es ungemein viel mit dem Wesen von Deklarationen in CSS zu tun hat und förmlich den Schlüssel zum Verständnis der CSS-Terminologie enthält...

Du fragst ja selbst:

Wie würde man also die wirkliche, gemeinte Bedeutung von »declaration« übersetzen?

Ist dir die »ursprüngliche Bedeutung« klar, du kannst sie nur nicht in Worte fassen?

Die verbreitete Bedeutung von »Deklaration« bzw. besser gesagt die möglichen bzw. häufigen Konnotationen sind mir durchaus bewusst, deshalb sehe ich auch keine Verbindung zwischen diesen und der Vorstellung der CSS-Deklarationen.

Als naheliegende Umschreibungen für »declaration« schlug ich bereits (Formatierungs-)»Angabe« und (Eigenschafts-)»Zuweisung«/»Zuordnung« vor und nannte auch deren Nachteile. Für den syntaktischen Codebestandteil gibt es m.M.n. keinen eindeutige, alltagssprachlichen Begriff. Im Grunde ist die Zuweisung einer bestimmten Formatierungseigenschaft im Sinne einer Zuordnung bzw. Festlegung von Merkmal (Eigenschaft) und Merkmalsausprägung (Wert) gemeint. Natürlich wird das Objekt, dem etwas zugewiesen wird, wiederum in einem anderen Syntaxteils angegeben, dem Selektor.

So sehr man auf den korrekten Begriffen herumreitet, für einen Anfänger liegt das Wort »Befehl« diesen nicht fern, und zwar selbst wenn das Konzept von Statements, Regeln, Selektoren und Deklarationsblöcken einerseits und Eigenschaften und Eigenschaftswerten andererseits verinnerlicht wurde, ohne zwangsläufig mit diesen Begriffen umzugehen.

Wer zwischen all diesen unterschiedlichen Bestandteilen der CSS-Grammatik konzeptionell unterscheidet, wird es auch sprachlich tun wollen. Genau deswegen gibt es Bezeichungen.

Aus diesem berechtigten Anspruch lässt sich sicher nicht nicht die zwingende Notwendigkeit ableiten, diese Bezeichnungen mittels Phantasiebegriffen bzw. bekannten Begriffe mit neuer Bedeutung ohne eindeutig erkennbaren Bezug zur allgemeinen Bedeutung umgesetzt werden müssen.

Ich sehe keinen Grund, diese nicht zu verwenden.

Ich wollte nicht die Notwendigkeit der Unterscheidung anzweifeln. Ich bin lediglich der Meinung, dass Begriffe wie »Selektor« und »Deklaration« »aus sich selbst heraus« einem nicht mit der speziellen Bedeutung vertrauten Menschen wenig bis nichts sagen, also nicht die (dann in einem gewissen Sinne metaphorische) Erklärung einer abstrakteren Vorstellung über bereits bekannte Wörter eines begrenzteren Sprachschatzes leisten.

Die Benennung ist insgesamt ein einziges Dilemma - da beispielsweise rule set laut Spec mit »rule« abgekürzt werden kann, wären @-rules genauso rules wie rule sets, weil »rules« gegenüber »@-rules« suggeriert, »rules« sei eine allgemeinere Art und »@-rules« seien eine spezielle Ausprägung von »rules«, aber mitnichten(tm), der Oberbegriff ist »statements«, was, wie wir gelernt haben, angeblich »Anweisung« bedeutet, somit scheinen alle Regeln Anweisungen zu sein und alle Anweisungen Regeln... ;) Also nennen wir brav rule sets »Regelmengen« (argh!) anstatt einfach gleichmacherisch »Regeln«, und wer dann von selbst nicht darauf kommt, dass die Zusammenstellung der Syntaxbestandteile »dieser Code sagt, welchen Elementen unter welchen Umständen das folgende zugewiesen werden soll« und »dieser Code enthält Merkmalsangaben, welche auf die im vorher festgelegten Elemente angewendet werden soll« gemeint ist, na, dem kann auch nicht mehr geholfen werden(tm).

Grüße,
Mathias

[at]

Hallo.

Die Benennung ist insgesamt ein einziges Dilemma - da beispielsweise rule set laut Spec mit »rule« abgekürzt werden kann, wären @-rules genauso rules wie rule sets, weil »rules« gegenüber »@-rules« suggeriert, »rules« sei eine allgemeinere Art und »@-rules« seien eine spezielle Ausprägung von »rules«, aber mitnichten(tm), der Oberbegriff ist »statements«, was, wie wir gelernt haben, angeblich »Anweisung« bedeutet, somit scheinen alle Regeln Anweisungen zu sein und alle Anweisungen Regeln... ;) Also nennen wir brav rule sets »Regelmengen« (argh!) anstatt einfach gleichmacherisch »Regeln«, und wer dann von selbst nicht darauf kommt, dass die Zusammenstellung der Syntaxbestandteile »dieser Code sagt, welchen Elementen unter welchen Umständen das folgende zugewiesen werden soll« und »dieser Code enthält Merkmalsangaben, welche auf die im vorher festgelegten Elemente angewendet werden soll« gemeint ist, na, dem kann auch nicht mehr geholfen werden(tm).

Ich glaube, jetzt sind alle Klarheiten beseitigt ;-)
MfG, at

[Michael Jendryschik]

Es geht mir darum, zu bezweifeln, dass jeder Deutschsprachige, der sich mit CSS beschäftigt, auch den äquivalenten »offiziellen« deutschen Fachterminus verwenden soll/muss, denn das Verständnis erleichtert er meiner Meinung nach nicht sonderlich.

Es gibt da diese Geschichte (es wäre schön, wenn sie jemand im Web finden könnte), in der ein Mann auf die Idee kommt, einfach mal andere Bezeichnungen für Dinge einzuführen, um sein langweiliges Alltagsleben spannender zu gestalten. Er steigert sich mehr und mehr in seine Idee hinein, sodass er bald fast alle Dinge anders nennt, als die Allgemeinheit es tut. Dies führt dazu, dass ihn niemand mehr verstehen kann und er so einsam ist wie zu Beginn der Geschichte.

Warum erzähle ich das? Weißt du, es ist mir egal, ob jemand statt »Selektor« lieber »Auswähler« oder statt »Eigenschaft« eher »Attribut« sagt, wenn es ihm hilft, die Dinge auseinanderzuhalten und besser zu verstehen. Aber das bringt Probleme mit sich. Wenn jemand, gehen wir von einem Newbie aus, der sich mit uns über CSS unterhalten möchte, für ihn verständliche und »lautmalerische« Begriffe für die CSS-Syntax erfindet und sich uns gegenüber zu einem bestimmten Problem oder Sachverhalt kommunizieren möchte, dann werden wir ihn vermutlich nicht verstehen. Wir müssten die Sprachen, die wir sprechen, einander näher bringen, bevor wir uns mit dem eigentlichen Problem befassen können. Wahrscheinlich werden wir am Ende des Gesprächs unser Vokabular verwenden, nicht das des Newbies. Warum? Weil das die deutschen Fachtermini sind, die jeder versteht (oder nachschlagen kann) und die Dinge eindeutig bezeichnen.

eine XML declaration lässt sich auch als das Dokument einleitende Verarbeitungsanweisung - wie weit liegen »instruction« und »Befehl« wohl auseinander? ;-) - an den Parser beschreiben,

Eine XML-Deklaration ist keine Verarbeitungsanweisung.

Als naheliegende Umschreibungen für »declaration« schlug ich bereits (Formatierungs-)»Angabe« und (Eigenschafts-)»Zuweisung«/»Zuordnung« vor und nannte auch deren Nachteile.

Wir reden hier nicht über Umschreibungen sondern über Bezeichnungen, das ist ein Unterschied.

Ich wollte nicht die Notwendigkeit der Unterscheidung anzweifeln. Ich bin lediglich der Meinung, dass Begriffe wie »Selektor« und »Deklaration« »aus sich selbst heraus« einem nicht mit der speziellen Bedeutung vertrauten Menschen wenig bis nichts sagen, also nicht die (dann in einem gewissen Sinne metaphorische) Erklärung einer abstrakteren Vorstellung über bereits bekannte Wörter eines begrenzteren Sprachschatzes leisten.

Ein Selektor ist für mich etwas, mit dem ich etwas auswähle (selektiere), insofern passt diese Bezeichnung MUSEN sehr gut. Dass ich die Bezeichnung »Deklaration« ebenfalls für geeignet halte, habe ich bereits geschrieben. Im Gegensatz zu dir bestehe ich aber auch nicht darauf, dass alle Fachbezeichnungen sofort und für jeden Anfänger auf der Hand liegend auf das schließen lassen, was sie bezeichnen.

Also nennen wir brav rule sets »Regelmengen« (argh!) anstatt einfach gleichmacherisch »Regeln«,

Man sagt »Regelsatz«.

Gruß,

MI

[molily]

Hallo,

Es geht mir darum, zu bezweifeln, dass jeder Deutschsprachige, der sich mit CSS beschäftigt, auch den äquivalenten »offiziellen« deutschen Fachterminus verwenden soll/muss, denn das Verständnis erleichtert er meiner Meinung nach nicht sonderlich.

Es gibt da diese Geschichte (es wäre schön, wenn sie jemand im Web finden könnte), (...)

http://www.mauthner-gesellschaft.de/mauthner/intro/bichsel.html

(Björn Höhrmann weist öfters, auch in den unpassendsten Situationen, darauf hin...)

Warum erzähle ich das? Weißt du, es ist mir egal, ob jemand statt »Selektor« lieber »Auswähler« oder statt »Eigenschaft« eher »Attribut« sagt, wenn es ihm hilft, die Dinge auseinanderzuhalten und besser zu verstehen.

Ja, darauf wollte ich hinaus.

Aber das bringt Probleme mit sich. Wenn jemand, gehen wir von einem Newbie aus, der sich mit uns über CSS unterhalten möchte, für ihn verständliche und »lautmalerische« Begriffe für die CSS-Syntax erfindet und sich uns gegenüber zu einem bestimmten Problem oder Sachverhalt kommunizieren möchte, dann werden wir ihn vermutlich nicht verstehen.

Ich bin ebenfalls der Meinung, dass es einheitliche Begriffe geben soll und dass man sich möglichst mithilfe dieser austauschen soll, um Missverständnisse zu vermeiden (bzw. Kommunikation überhaupt zu ermöglichen). Wenn mir Wirrwarr am liebsten wäre, könnte es mir egal sein, dass die offizielle Begrifflichkeit Defizite aufweist und ich würde sie einfach ignorieren und meiner Meinung nach passendere Begriffe verwenden und propagieren.

Ich wollte aber kritisieren, dass bei der Ausarbeitung der quasi-normativen Übersetzung bzw. schon bei der Ausarbeitung der Spec unnötige Fehler unterlaufen sind, welche letztlich mit höherer Wahrscheinlichkeit dazu führen, dass einige Menschen eigene Begriffe für die CSS-Syntaxteile erfinden, weil sich ihnen der Sinn der offiziellen Terminologie verschließt - und das bringt letztlich niemandem etwas. Das bedeutet, wenn man sich auf bestimmte Begriffe *einigt*, begrüße ich das nur. Das Gegenteil ist aber der Fall, wenn aber das W3C Begriffe und Übersetzungen vorgibt und die Webautoren sie nur annehmen, weil ihnen nichts anderes übrig bleibt, obgleich sie sie irreführend finden. Es kommt nicht von ungefähr, dass Autoren von Dokumentationen beziehungsweise Lehrende gegenüber Lernenden zur Veranschaulichung einfachere, bereits bekannte Begriffe wählen.

(Du meinst übrigens eher »sprechende« Begriffe, »lautmalerisch« ist was anderes, aberegal. </nitpick>)

Wir müssten die Sprachen, die wir sprechen, einander näher bringen, bevor wir uns mit dem eigentlichen Problem befassen können. Wahrscheinlich werden wir am Ende des Gesprächs unser Vokabular verwenden, nicht das des Newbies. Warum? Weil das die deutschen Fachtermini sind, die jeder versteht (oder nachschlagen kann) und die Dinge eindeutig bezeichnen.

eine XML declaration lässt sich auch als das Dokument einleitende Verarbeitungsanweisung - wie weit liegen »instruction« und »Befehl« wohl auseinander? ;-) - an den Parser beschreiben,

Eine XML-Deklaration ist keine Verarbeitungsanweisung.

Hach ja, der Definition nach, um PIs von XML-Deklarationen abzugrenzen und für beide eine Grammatik zu definieren, nichtsdestoweniger sind es im allgemeinen Sinne auch besondere/eingeschränkte »Verarbeitungsanweisungen«, wenn man nicht die formale Definition der XML-Spec zugrunde legt.

Als naheliegende Umschreibungen für »declaration« schlug ich bereits (Formatierungs-)»Angabe« und (Eigenschafts-)»Zuweisung«/»Zuordnung« vor und nannte auch deren Nachteile.

Wir reden hier nicht über Umschreibungen sondern über Bezeichnungen, das ist ein Unterschied.

Das lässt sich ja gar nicht trennen. Wenn man an eine Bezeichnung für etwas Abstraktes nicht den Anspruch stellt, das Bezeichnete mit einem existenten Begriff metaphorisch (also implizit vergleichend) zu »umschreiben«, wären wir wieder bei völliger Arbitrarität und damit bei »Spunk«, man könnte also neue Wörter oder Zeichen erfinden.

Ich wollte nicht die Notwendigkeit der Unterscheidung anzweifeln. Ich bin lediglich der Meinung, dass Begriffe wie »Selektor« und »Deklaration« »aus sich selbst heraus« einem nicht mit der speziellen Bedeutung vertrauten Menschen wenig bis nichts sagen, also nicht die (dann in einem gewissen Sinne metaphorische) Erklärung einer abstrakteren Vorstellung über bereits bekannte Wörter eines begrenzteren Sprachschatzes leisten.

Ein Selektor ist für mich etwas, mit dem ich etwas auswähle (selektiere), insofern passt diese Bezeichnung MUSEN sehr gut.

Natürlich, sofern man in dem Fall hinreichend Fremdwörter kennt bzw. den nötigen Bildungsgrad hat, um diese Zusammenhänge auf Anhieb zu erkennen. Das englische »select« ist im Vergleich zum deutschen »selektieren« ein Alltagswort. Ich meinte auch, dass »Selektor« selbst, obgleich zwar eine mehr oder weniger erkennbare Verbindung zu Selektion/selektieren besteht, ein neues Wort darstellt, welches in keinem Wörterbuch zu finden ist. Wenn der Sinngehalt exakt mit »das Auswählende« bzw. »der die betreffenden Elemente bzw. Pseudoelemente und deren Zustände auswählende Ausdruck/Code« wiedergegeben werden kann, bedeutet Selektor wie du sagtest »Auswähler«, und da CSS keine Geheimwissenschaft für Philologen ist und jeder Hinz und Kunz, der im Web veröffentlichen will, tagtäglich damit umgeht, wäre es vermutlich nur konsequent, von »Auswählern« zu sprechen.

Dass ich die Bezeichnung »Deklaration« ebenfalls für geeignet halte, habe ich bereits geschrieben. Im Gegensatz zu dir bestehe ich aber auch nicht darauf, dass alle Fachbezeichnungen sofort und für jeden Anfänger auf der Hand liegend auf das schließen lassen, was sie bezeichnen.

Ich finde es eher *wünschenswert* und bin der Meinung, dass gleichzeitig auf technische Präzision/Eindeutigkeit und (relativ) gute Verständlichkeit eventuell durch Nähe zu bekannteren Begriffen geachtet werden kann.

Also nennen wir brav rule sets »Regelmengen« (argh!) anstatt einfach gleichmacherisch »Regeln«,

Man sagt »Regelsatz«.

Warum, weil »rule« »Regel« heißt und »set« »Satz«? Muha. Das ist genauso irreführend, weil es kein »Satz an Regeln« ist, was das Wort vermuten ließe (vergleiche »Datensatz« usw.), es ist nur _eine_ Regel, die aus der genannten Zusammenstellung besteht. Kein Teil davon kann autonom existieren, kein Teil davon ist für sich eine interpretierbare Formatierungsvorschrift, nur zusammen lassen sie sich vom Rechner umsetzen. Mit »Menge« in »Regelmenge« ist auch etwas spezielles gemeint, denn es ist auch keine »Menge an Regeln« gemeint.

Im Übrigen habe ich »Regelmenge« nur angeführt, weil es die (wie gesagt kritikwürdige) deutsche Übersetzung gemäß http://www.edition-w3c.de/TR/REC-CSS2 ist - ich weiß, dass diese Übersetzung keinerlei Normativität im Vergleich zur englischen Spec besitzt -, ich habe dieses Wort noch nie benutzt. Außerhalb des dciwam-Umfelds habe ich »Regelsatz« übrigens noch nirgendwo gelesen, und alle Quellen, welche von Regelsätzen in CSS sprechen, sind aus diesem Umfeld. Wenn überhaupt der W3C-Terminologie gefolgt wird, wird »Regel« benutzt, was die Specs ja auch nicht ohne Widerspruch als Abkürzung vorschlagen.

Grüße,
Mathias

[Michael Jendryschik]

Ich wollte aber kritisieren, dass bei der Ausarbeitung der quasi-normativen Übersetzung bzw. schon bei der Ausarbeitung der Spec unnötige Fehler unterlaufen sind, welche letztlich mit höherer Wahrscheinlichkeit dazu führen, dass einige Menschen eigene Begriffe für die CSS-Syntaxteile erfinden, weil sich ihnen der Sinn der offiziellen Terminologie verschließt - und das bringt letztlich niemandem etwas. Das bedeutet, wenn man sich auf bestimmte Begriffe *einigt*, begrüße ich das nur. Das Gegenteil ist aber der Fall, wenn aber das W3C Begriffe und Übersetzungen vorgibt

Du bist der Ansicht, das W3C hat die deutschen Übersetzungen für die englischen Originalbezeichnungen diktiert? Ich gehe vielmehr davon aus, dass diejenigen, die zuerst deutsche Texte über CSS verfasst haben, sich die Übersetzungen überlegt haben. Und ich gehe weiter davon aus, dass die heute verwendeten Bezeichnungen sich durchgesetzt haben, weil die Mehrheit sie für geeignet empfunden und selbst verwendet hat.

Es kommt nicht von ungefähr, dass Autoren von Dokumentationen beziehungsweise Lehrende gegenüber Lernenden zur Veranschaulichung einfachere, bereits bekannte Begriffe wählen.

Das können sie gern tun. Weshalb ich das unklug finde, habe ich dargelegt.

Eine XML-Deklaration ist keine Verarbeitungsanweisung.

Hach ja, der Definition nach, um PIs von XML-Deklarationen abzugrenzen und für beide eine Grammatik zu definieren, nichtsdestoweniger sind es im allgemeinen Sinne auch besondere/eingeschränkte »Verarbeitungsanweisungen«, wenn man nicht die formale Definition der XML-Spec zugrunde legt.

Nach Definition ist es keine, wenn man aber darüber hinwegsieht, dann ist es eine? So werde ich das nächste Mal argumentieren, wenn ich mal wieder rausgewunken werde, weil ich über diverse Verkehrsschilder großzügig hinweggesehen habe. ;-)

Gruß,

MI

[molily]

Hallo,

Ich wollte aber kritisieren, dass bei der Ausarbeitung der quasi-normativen Übersetzung bzw. schon bei der Ausarbeitung der Spec unnötige Fehler unterlaufen sind, welche letztlich mit höherer Wahrscheinlichkeit dazu führen, dass einige Menschen eigene Begriffe für die CSS-Syntaxteile erfinden, weil sich ihnen der Sinn der offiziellen Terminologie verschließt - und das bringt letztlich niemandem etwas. Das bedeutet, wenn man sich auf bestimmte Begriffe *einigt*, begrüße ich das nur. Das Gegenteil ist aber der Fall, wenn aber das W3C Begriffe und Übersetzungen vorgibt

Du bist der Ansicht, das W3C hat die deutschen Übersetzungen für die englischen Originalbezeichnungen diktiert?

Nein, bin ich nicht, aber das ist einerlei: Zwar steht es den Übersetzern prinzipiell frei, was aber nichts daran geändert hat, dass sie sich teilweise sklavisch wortwörtlich an den Originalbezeichnungen orientiert haben, sodass dabei Denglisch wie »Deklaration« und »Selektor« herauskam. Damit wurden etwaige Defizite der Originalbezeichnungen nicht nur übernommen, sondern vervielfacht durch die sogenannte Übersetzung. Zu den Einzelheiten dieser habe ich mich bereits geäußert.

Ich gehe vielmehr davon aus, dass diejenigen, die zuerst deutsche Texte über CSS verfasst haben, sich die Übersetzungen überlegt haben.

Und das soll beweisen, dass das Huhn zuerst war? Auch diejenigen, die sich bereits vor der Erarbeitung einer Spec-Übersetzung Gedanken um mögliche deutsche Äquivalente gemacht haben, wurden mit Sicherheit maßgeblich von der englischen Spec beeinflusst. Darüber hinaus verfassen diejenigen, die sich in den Anfangsstunden mit den Originalquellen beschäftigen, m.E. anfangs Sekundärquellen von Proggern für Progger in entsprechender Sprache und mit entsprechender Zielgruppe. Sie machen sich keine Gedanken über die Angemessenheit eines Begriffes, wenn er aus abgeschotteten Sozialräumen dringt und plötzlich von jedem x-beliebigen Webautor in den Mund genommen wird. Das sieht man an den 1:1-Übertragungen nach Buchstaben und nicht nach Sinn, die sich Übersetzungen nennen.

Und ich gehe weiter davon aus, dass die heute verwendeten Bezeichnungen sich durchgesetzt haben, weil die Mehrheit sie für geeignet empfunden und selbst verwendet hat.

Eine quasi einvernehmliche, basisdemokratische Entscheidungsfindung herbeizureden und damit die Übersetzung für sakrosankt zu erklären, ist an den Haaren herbeigezogen. Die Bezeichnungen sind sicherlich nicht aus dem Grund in die Spec-Übersetzungen geflossen, weil sie vorher bereits dominierender Standard in einer ausreichend großen Gruppe waren, in welcher sie sich aufgrund von Aussagekraft und Präzision durchgesetzt haben, sich als Produkt einer Selektion der möglichen Begriffe als meistgemochte Begriffe herausgeschält haben bzw. in einer öffentlichen Diskussion einzeln besprochen und konsensuell beschlossen wurden. Dieses Gremium muss ich anscheinend verschlafen haben. Mir kommt es eher so vor, als habe man nicht darüber nachgedacht und als ob kein Hintersinn existiere. Selbst wenn die von dir angesprochene »Mehrheit« existiert, handelt es sich dabei der Logik nach um Profis und Technokraten, deren Vertretungsanspruch ich anzweifeln möchte, womit sich die Frage stellt, warum gerade deren Jargon in eine Übersetzung fließen sollte, welche sich um Verständlichkeit bemüht und von jedem Webautor gelesen wird.

Eine XML-Deklaration ist keine Verarbeitungsanweisung.

Hach ja, der Definition nach, um PIs von XML-Deklarationen abzugrenzen und für beide eine Grammatik zu definieren, nichtsdestoweniger sind es im allgemeinen Sinne auch besondere/eingeschränkte »Verarbeitungsanweisungen«, wenn man nicht die formale Definition der XML-Spec zugrunde legt.

Nach Definition ist es keine, wenn man aber darüber hinwegsieht, dann ist es eine?

Ja, was ist daran widersprüchlich: Nach der formalen Definition des Begriffes »Verarbeitungsanweisung« in der XML-Spec ist die XML-Deklaration keine PI, anders herum hat sie die Gestalt und, vom besagten allgemeinen Wortsinne ausgehend, auch die Wirkung einer Verarbeitungsanweisung, nur in dem Falle die einer speziellen, abgegrenzten. Eine Anweisung an den Prozessor die Verarbeitung betreffend ist es sowieso.
Ist eine XML-Deklaration im SGML-Sinne eine Verarbeitungsanweisung?

So werde ich das nächste Mal argumentieren, wenn ich mal wieder rausgewunken werde, weil ich über diverse Verkehrsschilder großzügig hinweggesehen habe. ;-)

Das ist ein denkbar unpassender Vergleich.

Grüße,
Mathias

[at]

Hallo.

Das ist ein denkbar unpassender Vergleich.

"Jeder Vergleich hinkt." ;-)
MfG, at

[Michael Jendryschik]

Du bist der Ansicht, das W3C hat die deutschen Übersetzungen für die englischen Originalbezeichnungen diktiert?

Nein, bin ich nicht, aber das ist einerlei: Zwar steht es den Übersetzern prinzipiell frei, was aber nichts daran geändert hat, dass sie sich teilweise sklavisch wortwörtlich an den Originalbezeichnungen orientiert haben, sodass dabei Denglisch wie »Deklaration« und »Selektor« herauskam.

Wie gesagt, ich halte diese Bezeichnungen nicht für Denglisch, und es sei an dieser Stelle erwähnt, dass ich ein Gegner von Anglizismen und bestrebt bin, keine zu verwenden.

Ich gehe vielmehr davon aus, dass diejenigen, die zuerst deutsche Texte über CSS verfasst haben, sich die Übersetzungen überlegt haben.
...
Und ich gehe weiter davon aus, dass die heute verwendeten Bezeichnungen sich durchgesetzt haben, weil die Mehrheit sie für geeignet empfunden und selbst verwendet hat.

Eine quasi einvernehmliche, basisdemokratische Entscheidungsfindung herbeizureden und damit die Übersetzung für sakrosankt zu erklären, ist an den Haaren herbeigezogen.

Tut mir leid, aber ich glaube nicht an das Märchen vom bösen schwarzen Mann, der Leid und Elend über die Welt gebracht hat, indem er absichtlich ungeeignete Übersetzungen verbreitet hat. Gäbe es ihn, würde er sich vermutlich köstlich über diese Diskussion hier amüsieren.

Selbst wenn die von dir angesprochene »Mehrheit« existiert, handelt es sich dabei der Logik nach um Profis und Technokraten, deren Vertretungsanspruch ich anzweifeln möchte, womit sich die Frage stellt, warum gerade deren Jargon in eine Übersetzung fließen sollte, welche sich um Verständlichkeit bemüht und von jedem Webautor gelesen wird.

Du möchtest ein Gremium von unbeteiligten Personen ins Leben rufen, ähnlich einem amerikanischen Geschworenengericht, und diese dann darüber diskutieren und abstimmen lassen, welche deutsche Übersetzungen für englische Bezeichnungen geeignet sind? :-)

Tut mir leid, dass ich mich in Sarkasmus flüchte, aber ich finde es lustig, wie du dich ereiferst, vor allem, da ich so gar nicht deiner Meinung bin. Aber ich denke dennoch, dass zumindest ich bei folgenden Übersetzungen ein wenig mehr darauf achten werde, wie ich Begriffe übersetze, insofern hat diese Diskussion vielleicht etwas gebracht, mal sehen.

Gruß,

MI

[at]

Hallo.

Tut mir leid, aber ich glaube nicht an das Märchen vom bösen schwarzen Mann, der Leid und Elend über die Welt gebracht hat, indem er absichtlich ungeeignete Übersetzungen verbreitet hat. Gäbe es ihn, würde er sich vermutlich köstlich über diese Diskussion hier amüsieren.

Harharhar... ;-)
MfG, at

[molily]

Hallo Michael,

Tut mir leid, aber ich glaube nicht an das Märchen vom bösen schwarzen Mann, der Leid und Elend über die Welt gebracht hat, indem er absichtlich ungeeignete Übersetzungen verbreitet hat. Gäbe es ihn, würde er sich vermutlich köstlich über diese Diskussion hier amüsieren.

»Regelsatz« geht beispielsweise auf Björn Höhrmann zurück (http://groups.google.at/groups?selm=3bc75a43.37997157%40news.bjoern.hoehrmann.de), alle Regulars und die FAQ übernahmen es und für dich ist es schon selbstverständlich, dass »man« »Regelsatz« sagt. Fazit: Björn Höhrmann ist der ominöse böse kranöse schwarze Mann! Auf ihn trifft auch meine Technokratenweltverschwörungstheorie. Und falls wir ihn tatsächlich zum Schmunzeln gebracht haben, hat diese Diskussion die Welt verbessert.

Mathias

[Michael Jendryschik]

Hallo,

Tut mir leid, aber ich glaube nicht an das Märchen vom bösen schwarzen Mann, der Leid und Elend über die Welt gebracht hat, indem er absichtlich ungeeignete Übersetzungen verbreitet hat. Gäbe es ihn, würde er sich vermutlich köstlich über diese Diskussion hier amüsieren.

»Regelsatz« geht beispielsweise auf Björn Höhrmann zurück (http://groups.google.at/groups?selm=3bc75a43.37997157%40news.bjoern.hoehrmann.de), alle Regulars und die FAQ übernahmen es und für dich ist es schon selbstverständlich, dass »man« »Regelsatz« sagt.

Und du bist sicher, dass die Übersetzung »Regelsatz« mit diesem Posting geboren wurde?

Gruß,

MI

[molily]

Hallo,

»Regelsatz« geht beispielsweise auf Björn Höhrmann zurück (http://groups.google.at/groups?selm=3bc75a43.37997157%40news.bjoern.hoehrmann.de), alle Regulars und die FAQ übernahmen es und für dich ist es schon selbstverständlich, dass »man« »Regelsatz« sagt.

Und du bist sicher, dass die Übersetzung »Regelsatz« mit diesem Posting geboren wurde?

Nein, das meinte ich auch nicht. Die Verbreitung des Begrifes ist lediglich bis dahin zurückverfolgbar, darüber hinaus kann man nur spekulieren. Björn Höhrmann brachte es damit erstmals in einer folgenreichen Weise nach dciwam, in die FAQ, in deine Einführung und andere Dokumente von dciwam-Lesern und u.a. über dich in dieses Forum. Der zumindest lokal maßgebliche Einfluss ist für mich evident, wobei ich nicht andere Einflüsse leugnen will, mir allerdings keine vorstellen kann. Ich wollte aufzeigen, dass das heutiger Lehrbuchinhalt einst von einer Einzelmeinung ausging, die jeder übernahm, weil jeder es ganz simpel und logisch fand, dass »rule set« »Regelsatz« heißt. Das Argument war von Anfang an: »man sagt ... dazu«. Dabei war ständig »ich sage ... dazu« gemeint; aber so entstehen nunmal Urban Legends.

Mathias

[Michael Jendryschik]

Ich wollte aufzeigen, dass das heutiger Lehrbuchinhalt einst von einer Einzelmeinung ausging, die jeder übernahm, weil jeder es ganz simpel und logisch fand, dass »rule set« »Regelsatz« heißt.

Und genau das meine ich, wenn ich in [pref:t=55944&m=313961] schreibe:

| Und ich gehe weiter davon aus, dass die heute verwendeten Bezeichnungen sich
| durchgesetzt haben, weil die Mehrheit sie für geeignet empfunden und selbst
| verwendet hat.

Das hat nichts mit einer »quasi einvernehmliche(n), basisdemokratische(n) Entscheidungsfindung« zu tun, wie du noch süffisanz kommentiert hast, nein, wir fanden den Begriff einfach gut. Glaub mir, Björn hat uns nicht befohlen, seine Übersetzung zu verwenden. Hätten einige geglaubt, »Regelsatz« wäre als Übersetzung ungeeignet, wäre es in der Gruppe diskutiert worden.

Gruß,

MI

[stefan]

Die offizielle deutsche Version der Specs übersetzt »statement« (Oberbegriff für @-rules und rule sets) mit »Anweisung«, [...]

Womit wir schon fast wieder bei "Befehl" angekommen wären ...

[Zwomble]

erst suchen dann fragen:
http://selfhtml.teamone.de/css/formate/wertzuweisung.htm#numerische
grüße zwomble

[wahsaga]

hi,

bin gerade dabei eine vorhandene CSS Datei zu ändern und bin auf den Befehl margin:1em; gestoßen und weiß nicht was dieser Befehl bewirkt!

zum x-ten mal: weder html noch css haben befehle!

Bin leider noch nicht so erfahren in css, deswegen benötige ich Eure hilfe. Danke im Voraus

die selfhtml quickbar kennst du sicher (ansonsten lerne sie jetzt kennen). dort wählst du 'css' aus, anschliessend 'margin'.

in der beschreibung zu margin ist ein link, der dir sagt, welche werte für margin erlaubt sind. dort findest natürlich auch 'em'.

gruss,
wahsaga

[Siechfred]

Hi,

bin gerade dabei eine vorhandene CSS Datei zu ändern und bin auf den Befehl margin:1em; gestoßen und weiß nicht was dieser Befehl bewirkt!

Lies einfach:
http://selfhtml.teamone.de/css/eigenschaften/randabstand.htm
http://selfhtml.teamone.de/css/formate/wertzuweisung.htm#numerische

Viele Grüße
Torsten