Hallo,

ich habe hier ein Problem mit einem DIV-Container. Alle Absätze in diesem Div-Container sollen als Blocksatz (justify) ausgerichtet werden. Es soll aber auch möglich sein, einige wenige Absätze links- und rechtsbündig als auch zentriert auszurichten.

Wie bekomme ich das hin?

Wenn ich sag

und eine Klasse erstelle

dann funktioniert die Klasse nicht.


Hat jemand eine Lösung parat?

Danke!

Zu spät habe ich bei Deinem Code oben bemerkt:

Wolltest Du nicht eher schreiben:


Um das obig von mir infrage gestellte Doppelkreuz vor dem div bereinigt (ich nehme an, es ist ein Schreibfehler von Dir gewesen), funktioniert bei mir hingegen die Klasse sehr wohl -- es ist also zumindest bei meinem Test-Code entgegen obig von mir gemachter Aussage in diesem Fall doch kein !important-Zusatz notwendig:


Das Doppelkreuz, welches in CSS ja eine ID repräsentiert, gehört da also vor das erste von Dir genannte div nicht hin, weil Du ja, nehme ich jetzt mal stark an, das div-Element ansprechen willst (nehme ich mal an) und nicht eine ID mit der Bezeichnung "div" (so wie in Deinem Code oben). Oder?

Hallo,

um genau zu sein, sieht der Code so aus:




Mit anderen Worten: ja, das "Div" steht für eine ID, welches einem DIV-Container zugewiesen ist.

Entschuldige bitte die Verwirrung.


MfG

Überlege bitte mal selber, ob man/ich Dir wirklich helfen kann, wenn Du nur den halben Code oder Code-Fetzen preisgibst. Sprich: ohne zugehörigen HTML-Code, aus dem man die Struktur und Schachtelung der einzelnen HTML-Elemente erkennen kann, kann man/ich Dir nicht helfen, weil mir die Bezüge fehlen und man außerdem nicht erkennen kann, ob Dein CSS an der betreffenden Stelle passt ("matcht") oder nicht.

Bitte also den CSS-Code immer zusammen mit dem dazugehörigen HTML-Code zeigen.
Entweder hier oder irgendwo online z.B. bei Pastebin . Sonst ist es schwierig bis unmöglich zu helfen.

Außerdem mal als gute gemeinten Rat grundsätzlicher Art: bezeichne Deine IDs und Klassen möglichst immer so, dass sie aus sich selber heraus "sprechend" sind; will heißen: dass allein durch ihre Namensgebung deutlich wird, was sie darstellen sollen, wähle deren Bezeichnung also möglichst nah an der Semantik (Bedeutung) des von einem HTML-Element umschlossenen Inhalts. Willkürlich ausgesuchte Zahlen und Buchstaben für ID- und Klassenbezeichner, wie Du sie bislang offenbar verwendest, erschweren unnötigerweise das Leseverständis beim Analysieren des Codes. Als angenehmen Nebeneffekt erreichst Du außerdem mit solch "sprechenden" Bezeichnern eine bessere Lesbarkeit auch durch Suchmaschinen wie Google und Bing, die ein Dokument lesen und ihrerseits Zusammenhänge herstellen können, was aich wiederum durchaus positiver auswirken kann in puncto besserer Suchergebnisse, besserer Suchmaschinenplatzierung, besserem Ranking.

Hallo,

OK. Einverstanden.

Hier zunächst der CSS-Code:



Nun der HTML-Code:





MfG

Ursache: So, wie Du das geschrieben hast, klappt das direkte Überschreiben an der betreffenden Stelle nicht, weil Deine im CSS gemachte Angabe nicht deckungsgleich "matcht" bei dem betreffenden p-Element.

Es gibt zwei mögliche Lösungen:

1. Du machst es so wie als erstes von mir geschrieben, indem Du dem gewünschten p-Element per !important die entsprechenden CSS-Eigenschaften quasi aufzwingst.
2. Oder Du verfasst Dein CSS mit einer ganz minimalen Änderung so, dass die beiden betreffenden CSS-Regeln in dem, was sie beschreiben, deckungsgleich sind.

Also:

Entweder so (zur visuellen Verdeutlichung schreibe ich mal beide Regeln auf, obwohl nur eine, nämlich die 1. Regel, die bezüglich der Klasse rk, geändert werden muss:

Variante 1:

In Worten gesprochen Variante 1:
1. Regel: Der Inhalt jedes beliebigen p-Elements innerhalb eines beliebigen Elements der ID inhalt soll in Blocksatz dargestellt werden.
2. Regel: Der Inhalt jedes beliebigen Elements der Klasse rk soll unbedingt! rechtsbündig formatiert dargestellt werden und die Font-Größe 8pt haben.


Oder so:

(Variante 2):

In Worten gesprochen Variante 2:
1. Regel: Der Inhalt jedes beliebigen p-Elements innerhalb eines beliebigen Elements der ID inhalt soll in Blocksatz dargestellt werden.
2. Regel: Der Inhalt jedes beliebigen p-Elements der Klasse rk und sich innerhalb eines beliebigen Elements der ID inhalt befindend soll rechtsbündig formatiert dargestellt werden und die Font-Größe 8pt haben.

Beide aufgezeigten Wege führen zum selben gewünschten Ergebnis.
Ich empfehle die zweite Variante, ich finde sie irgendwie "sauberer" und inhaltlich sinnvoller, weil die Vererbung von CSS vorbildlich ausnutzend, während ich die Variante 1, also die Methode via !important nur eher im Notfall nehmen würde, wenn's gar nicht mehr anders geht als etwas zu erzwingen. Vorausgesetzt, die Klasse rk soll sich tatsächlich nur und allein auf alle p-Elemente beziehen, welche innerhalb eines beliebigen Elemnts mit der ID inhalt vorkommen und nicht etwa auch mal auf ein anderes Element außer dem p-Element.

Du könntest es sogar, als weitere Variation auf Basis der Variation 2, also quasi als Variante 2a, noch treffgenauer/zielgerichteter schreiben, wenn Du schriebest:

In Worten gesprochen Variante 2a:
1. Regel: Der Inhalt jedes beliebigen p-Elements innerhalb des div-Elements der ID inhalt soll in Blocksatz dargestellt werden.
2. Regel: Der Inhalt jedes beliebigen p-Elements der Klasse rk und sich innerhalb des div-Elements der ID inhalt befindend soll rechtsbündig formatiert dargestellt werden und die Font-Größe 8pt haben.

Nachtrag:

Zudem eine kleine Anmerkung zu Deiner gewählten Font-Maßeinheit pt (point, zu deutsch: Punkt). pt als Größenangabe ist eigentlich bei Bildschirm-Ausgaben unklug und eigentlich sinnfrei gewählt und nur sinnvoll im Druck- und Papierbereich. Die Pixeldichte pro Quadratzoll Bildschirmfläche ist i.A. niedriger als die vergleichbare Punktdichte eines Blatt Papiers. Im Druckbereich rechnet man mit Punkten, pt (point, zu deutsch: Punkt) oder Einheiten wie cm oder mm. Auf dem Bildschirm rechnet man eher und besser in Pixeln bzw. in relativen Angaben zu einer bestimmten Bezugsgröße (entweder die Browservoreinstellungen oder als Bezugsgröße irgendein übergeordnetes Element, dessen Größe man schon mal zuvor definiert hat). Also entweder in em (wo möglich, zu bevorzugen) oder in ex oder % (Prozent) oder in (bildschirmbezogenen absoluten) Pixeln (px).

Siehe dazu auch: CSS 2 (deutsche Übersetzung), Kapitel 4.3.2 Längen: [url]http://www.edition-w3.de/TR/1998/REC-CSS2-19980512/kap04.html#heading-4.3.2[/url]

em hat eine uralte Entsprechung in der Typografie-Sprache: Geviert.

Wikipedia (de): Geviert (Typografie)
Wikipedia (de): em (Schriftsatz)

"ex" ist die Variation von "em", hat als Bezugsgröße aber nicht die Höhe des großen "M"s, sondern die des kleinen "x".

Relative Größen sind auf dem Bildschirm im Gegensatz zu festen Größen gerade bei Schrift deshalb äußerst sinnvoll, weil man sie skalieren kann, z.B. im Browser größer und kleiner stellen, was besonders für ältere Menschen bzw. Menschen mit einer Leseschwäche besonders hilfreich ist, wenn sie die Schriftgröße manuell und passend zu ihren Bedürfnissen anpassen wollen. Auch für die Wiedergabe auf großen und hochauflösenden Bildschirmen kann es durchaus sinnvoll sein, wenn sich mindestens die Schrift (oder ggf. auch noch mehr) skalieren und entweder automatisch oder manuell dem betreffenden Bildschirm oder den eigenen Sehgewohnheiten anpassen lässt.


*** Info am Rande, Offtopic***
Übrigens kleine Offtopic-Notiz am Rande: die Spezifikation von CSS 2.1 hat vor wenigen Tagen (und rechtzeitig zum 15. Gebrurtstag von CSS), am 07. Juni 2011, nun endlich den lange erwarteten endgültigen Status "Recommendation" erreicht (habe ich ja vor Monaten schon in so mancher hitzigen Diskussion anklingen lassen, dass dieser Tag nicht mehr so fern ist und noch diesen Frühsommer kommen wird).

CSS 2.1 hat damit nun nach jahrelanger Arbeit daran und teilweise langem regungslosen Verharrens auf einem der vorgeschalteten Stati nun endgültig den formalen End-Status "Fertig" ereicht. Zuvor war der Status von CSS 2.1 lange Zeit und ohne dass sich inhaltlich was in der Zwischenzeit geändert hat, Candidate Recommendation bzw. Proposed Recommendation. Verschiedene CSS 3-Teilspezifikationen, die inhaltlich an CSS 2.1 hängen bzw. an dessen Status formal gebunden sind, werden durch den nun endgültigen Status von CSS 2.1 automatisch um jeweils eine Stufe mit nach oben gezogen, deren Status ändert sich dadurch auch automatisch (ist entweder schon geschehen oder geschieht in den nächsten Tagen).
Die Spezifikation von CSS 2.1 ist also schon jahrelang in alltäglichem Gebrauch gewesen und hat jetzt vor wenigen Tagen erst seinen formalen Endstatus erreicht.

Siehe dazu auch die offiziellen Statements seitens des W3C: , und erste Reaktionen dazu aus der Fachwelt .

Das nur mal nebenbei als Info und Beispiel, dass die inhaltliche Stabilität und Abgeschlossenheit einer W3C-Spezifikation weiter und "fertiger" sein kann als der offizielle nach außen hin in ein oder zwei Worte gefasste formale Status. Weil es ja weltweit ein paar unzureichend informierte Leute gibt, denen die internen formalen Abläufe beim W3C nicht geläufig sind und welche meinen, HTML5 dürfe man noch nicht anfassen und noch nicht verwenden, weil die Spezifikation ja noch nicht ihren formalen endgültigen Status erreicht habe. Die Core-HTML5-Spezifikation wird ab diesem Sommer ebenfalls den Status Proposed Recommendation bekommen wenn nicht sogar gleich sogar, eine Status-Stufe überspringend, in den Status Candidate Recommendation übergehen. Man erwägt seitens des W3C einen formalen Status zu überspringen (weil das bisher Erreichte schon so sehr ausgereift und stabil ist), um dem Inhalt besser gerecht zu werden und damit auch auf dem Papier den formalen endgültigen Status "Recommendation" schneller zu erreichen.

Bzgl. CSS 2.1 hat es jahrelang auch keinen geschert und davon abgehalten CSS 2.1 zu nutzen, obwohl die CSS 2.1-Spezifikation jetzt erst vergangene Woche formal den endgültigen Status erreicht hat. Stabil spezifiziert und benutzbar in allen Browsern umgesetzt ist CSS 2.1 schon lange. Es gab da keinen Grund, es nicht einzusetzen im Web-Alltag. Und genauso sieht es im Grunde bezüglich HTML5 aus. Wobei sowieso HTML5 wie auch CSS 3 als Ganzes im Grunde nie wirklich fertig sein werden und immer ein "work in process" sein werden, also ein sich ständig in der Weiterentwicklung befindliches Gebilde mit immer neu hinzukommenden und das Ganze erweiternden Spezifikations-Modulen.
*** /Info am Rande, Offtopic ***

Hallo,

Gibt es denn eine sinnvolle Alternative zur Angabe "10pt" etc.?

Ja. Die habe ich oben bereits genannt. Zum Beispiel px für feststehende Größenangaben bei Schriften und Boxen und Linien etc. pp.), die NICHT skaliert werden können/sollen (die also ihre Größe behalten sollen, selbst wenn man das Browser-Fenster größer oder kleiner macht oder per Browser rein- oder rauszoomt bzw. versucht, die Schrift größer oder kleiner zu machen per Zoom). Und z.B. em und Prozentangaben für alles, was skalierbar und veränderbar sein soll, wo also Linien, Boxen und Schriften sich dynamisch anpassen sollen, je nachdem, ob man die fenstergröße ändert oder dem Benutzer erlauben will, die Schrift im Browser z.B. zu vergrößern, wenn sie ihm zu klein ist und er es mit größerer schrift besser lesen kann. Und damit es Dir beim Zoomen bzw. Schrift-Vergrößern nicht gleich das gesamte Layout zerhaut, muss sich das Layout in manchem Fall zumindest in gewissen Grenzen halt entsprechend mitbewegen, damit die Proportionen und Abstände relativ gesehen eben noch bestehenbleiben können und das Gesamtbild nicht zerstört wird, wenn man z.B. zoomt und die Schrift größer macht.

Es gibt Webauftritte, die sind so geartet, dass sie umfänglich dynamisch reagieren, die machen jede Änderung mit, da kann man das Browserfenster aufziehen wie man will oder bis zu einer gewissen Grenze klein machen wie man will, da wird alles nachgeführt (um bei Skalierbarkeit Mindestgrößen oder auch Maximalgrößen zu definieren, stellt CSS u.a. die Begriffe min-height, max-height, min-width, max-width zur Verfügung, mit denen man bei Bedarf einen Rahmen abstecken kann, in dessen sich dann dynamisch was abspielen kann und darf). Und wenn der Benutzer der Meinung ist, er müsse da mal die Schrift größer machen, um überhaupt was zu erkennen (nicht jeder hat dieselben Augen wie der Seitenersteller, und nicht jeder hat auch die gleichen Displayvoraussetzungen wie der Seitenersteller), dann kann er das tun. Ohne dass es ihm das Layout zerschlägt und es ihm um die Ohren fliegt. Im Grunde und eigentlich gibt es nur wenige Bereiche, wo man überhaupt feste und absolute Größen braucht. Jeder Webauftritt ist natürlich anders, aber man kann ihn schon von Grund auf so gestalten, dass er solche dynamischen Veränderungen initiiert durch den Benutzer einkalkuliert bzw. ihm diesbzgl. entgegenkommt.

Ich muss ein wenig ausholen, um einen anderen Punkt zu benennen.

Kurzer Exkurs:

--- Exkurs ---
Die Browser haben alle ein sog. Default Stylesheet eingebaut. Darin sind gewisse Grundgrößen und Abstände etc. eingetragen für alle Elemente von HTML. Dieses Default-Stylesheet ist in der HTML 4 Spezifikation z.B. hier definiert. Es basiert auf einer alten Idee, die auf Todd Fahrner und das von ihm ins Spiel gebrachte Base Stylesheet bzw. Core Stylesheet zurückgeht und war noch nicht immer fester Bestandteil der HTML- bzw. CSS-Spezifikation. In früheren Jahren wichen die Browser untereinander teilweise noch mehr oder weniger stark voneinander ab, was diese fest verdrahteten Basis-Größen angeht, deshalb steht's auch seit einigen Jahren als empfehlender Bestandteil in der CSS2-Spezifikation.
Heute halten sich die Browser da inzwischen auch alle dran und weichen im Großen und Ganzen von dieser Empfehlung nicht oder nur in Nuancen ab. Diese Werte werden also beim Anzeigen zugrundegelegt, wenn Du dem Browser z.B. nacktes HTML ohne irgendwelches CSS vorlegst, denn irgendwie, auf irgendeiner Basis muss der Browser das ja anzeigen.

Paranoiker bzw. ganz gründliche CSS-Fetischisten machen sogar Folgendes: um 100% sicher zu gehen und für alle Browser eine eineindeutige Nulllinie zu ziehen, also bis hin zum letzten Abstandspixel in den Browsern identische Voraussetzungen zu schaffen, gibt es mittlerweile sogar eine Gegenbewegung, die es sich zur Aufgabe gemacht hat, ein sog. Reset-Stylesheet zu entwerfen und zu benutzen, das, wenn man es einbindet, komplett und für alle Browser gleich, alle Elemente und Abstände auf Null setzt. Damit der Webentwickler danach seine von ihm gewünschten Abstände und Größen setzen kann in der Gewissheit, dass das dann garantiert für alle Browser identisch aussieht (weil zuvor von ihm ja per Reset-CSS alles auf Null gesetzt worden ist, also die internen in den Browsern verdrahteten Größenangaben damit quasi nivelliert worden sind).

Eric Meyer: Reset CSS
Eric Meyer: Reset Reloaded

Ich halte von Reset Stylesheets nicht viel, setze sie auch nicht ein. Es gibt sowohl Pro-Argumente als auch Gegenargumente, und ich stehe da eher auf der Seite von Jens Meiert und seinen Contra-Argumenten, welche für ihn und auch mich die Pro-Argumente überwiegen:

Jens Meiert: Why “Reset” Style Sheets Are Bad


--- /Exkurs ---

Warum der Exkurs? Um deutlich zu machen, worum es geht: der Browser bringt fest definierte Größen mit. Auf denen kann man aufbauen. Sprich: alles was man selber dann per eigenem CSS verändert und oben draufsetzt, kann man weitgehend mit dynamischen Größen machen. Die Grundgröße für Fließtext ist z.B. 1 em bzw. 100%. Sprich: wenn ich die Textgröße nicht verändere, dann ist der Text genauso groß, wie im Browser vordefiniert (lässt sich in jedem Browser per Einstellungsmenü ändern: Standardschrift und Standardgröße, voreingestellt sind z.B. in den Browsern in der Regel Times in der Größe 16 px).

Und ausgehend von diesen Grundgrößen kann man alles andere als relative Größen in seinem CSS definieren.

Die Überschrift 1. Ordnung, h1, ist in CSS2.1 z.B. so definiert und sicher auch in den Base-Stylesheets der Browser so übernommen:
h1 { font-size: 2em; margin: .67em 0 }
Die Überschriften 2. und 3. Ordnung, h2 und h3, z.B. so.
h2 { font-size: 1.5em; margin: .75em 0 }
h3 { font-size: 1.17em; margin: .83em 0 }

Ausgehend von dem, was der Browser als voreingestellte Grundgröße für die Standardschrift hat, nämlich 16 Pixel (16px).
Sprich: standardmäßig ist eine unveränderte h1-Überschrift doppelt (2em) so groß wie das große "M" ( das sagt em nämlich aus) der im Browser voreingestellten Standardschrift, welche mit voreingestellten 16 Pixel daherkommt. Eine Überschrift 1. Ordnung (oder auch so ausgedrückt: 1. Wichtigkeit), eine h1-Überschrift, ist also standardmäßig 32 Pixel hoch.

Und wenn Dir als Webentwickler oder Webautor zu groß oder zu klein ist, dann passt Du das mit deinem eigenen CSS einfach an und überschreibst es. Indem Du es auch wiederum mit relativen Größen machst, also genau wie das von CSS2.1 vorgeschlagene und vom Browser übernommene Base-Stylsheet auch. Dann ist bei Dir eine h1-Überschrift nicht 2em groß, sondern meinetwegen nur 1.5 em, also 1.5 mal 16 Pixel (px) hoch, also unterm Strich und faktisch 24 Pixel (px) hoch. Man hätte statt 2em als Größenangabe auch schreiben können: 200%. Das Ergebnis ist identisch und bedeutet in beiden Fällen: doppelt so hoch, doppelt so groß (hier: bezogen auf die Größe der Grundschrift.

Du könntest sie auch direkt als 24 Pixel-Schrift definieren, indem Du bei Dir im Stylesheet schreibst: h1 { font-size: 24px }, Du nimmst damit dann aber dem Benutzer die Möglichkeit, sie ggf. bei sich auf dem Monitor mit Hilfe des Browsers größer oder kleiner anzeigen zu lassen, wenn er das gerne tun möchte, weil's für ihn dann beser lesbar wäre.

Man kann sich selber auch den Referenzpunkt in seinem Stylesheet setzen, indem man sagt: die Grundschrift meiner Webseite, die ist ohne weitere Veränderungen grundsätzlich und im Minimum 10 Pixel (px) groß. Und alles andere, was darauf aufbaut, das bezieht sich relativ zu dieser von mir festgelegten Grundgröße. Da CSS sehr auf Vererbung aufbaut, zieht das angenehme Effekte nach sich, weil man eine feste Größe dann eigentlich nur einmal definieren muss, und diese wird dann weitervererbt bzw. man kann dann diese Vererbung nutzend, schön mit relativen Größenangaben weitermachen und kann auf diese Weise den Vorteil der weitgehenden Skalierbarkeit nutzen bzw. sie dem Nutzer nutzbar machen. Es obliegt dabei Dir und Deiner Gewohnheit, ob Du nun lieber auf Prozentangaben baust dabei oder lieber die Einheiten em oder ex wählst. Gerade für Schriften hat sich eigentlich die Einheit em (in der Typografie traditionell auch als Geviert bezeichnet) sehr eingebürgert, zumindest für Fließtext, bei Überschriften entweder ebenfalls em oder Prozentangaben %, je nach Bedarf und Geschmack.

Das alles dürfte Dir vor Augen geführt haben, dass es eben doch zum Teil sehr wesentlichde Unterschiede zwischen Bildschirm und Druck gibt. Schrift und Größen auf einem Blatt Papier sind nicht skalierbar, sind nicht veränderlich. Gedruckt ist gedruckt. Der Leser kann's nicht mehr verändern. Schrift und Größen auf einem Bildschirm bzw. im Web hingegen sind skalierbar, man kann sie verändern bzw. verändern/anpassen lassen (entweder automatisch oder vom Nutzer veranlasst).

Da wollte ich mal nachhaken.

Ist es demnach sinnvoll, immer die Einheit em für Schriftgrößen sowie für Abstände (margin und padding) zu verwenden?

Denn ich habe den Eindruck, daß beispielsweise eine Schriftgröße von 16 px bei manchen Bildschirm zu groß und bei manchen zu klein geraten ist.

Zusätzlich habe ich den Eindruck, daß die Schriften bei Angaben in px manchmal stellenweise verwaschen / verwischt aussehen.

Definier beides, also p und .pk als class
Sprich <p class="class1"> und <p class="pk">


wenn eines eine id ist und eines eine klasse gibts konflikte...
Zumal eine id nur einmal in html definiert werden soll...


Alternativ kannst du es auch so machen <p><span class="">
oder <p><div class="">


wenn du mehrere classen hast, kannst du auch konbinieren:
z.b. <div class="pk white>

white ist im css dann wie folgt definiert:
.white{}

und pk: .pk{}



cheers

@doom

Verwende px oder % für web

Verwende pt für print

Verwende em z.b. für fernseher oder für Schriftsetzer...


Cheers