Texte mit margin:auto - Bilder mit margin:0
Hallo,
Edit: Ich habe mittlerweile sämtliche Vorgaben für den Entwurf nochmal übersichtlich auf eine Webseite gestellt: http://borumat.de/html-und-css-tipps...d-volle-breite ein typisches Markup lautet: Code:
<div class="inhalt"> * Textbereich zentriert innerhalb DIV CLASS="INHALT" * Der Textbereich enthält diverse Elemente wie P, UL, OL, DL, TABLE, BLOCKQUOTE etc. * Textbereich mit Polsterung zu DIV CLASS="INHALT" von 1em links und rechts Die Polsterung kommt erst zum Tragen, wenn der Schriftgrad groß genug ist. * Textbereich maximal 65 Zeichen breit. Bezug für Zeichenbreite ist der Fließtext. * Bilder ganz links am Box DIV CLASS="INHALT" ausgerichtet und ohne Beschränkung in der Breite. Sie können also auch bis zum rechten RAND der Box DIV CLASS="INHALT" reichen, falls nötig. http://borumat.de/bilder/misc/temp/hc-050.png http://borumat.de/bilder/misc/temp/hc-051.png Das Motiv: Die Lesbarkeit von Fließtext verbessert sich durch eine Beschränkung der Zeilenlänge auf eine maximale Zeichenzahl enorm. Große Bilder passen jedoch in so schmale Boxen nicht hinein. Das sehe ich gestalterisch nicht als Not an. Mir gefällt es ausgesprochen gut, wenn Bilder nach links gegenüber dem Text ausgerückt erscheinen. Der Wunsch ist mit einer Verschmutzung des Markups problemlos realisieren. Code:
<style type="text/css"> Edit 7.10.2006 Ergänzung der Polsterung für den Text, die ich vergessen hatte. Entfernung des DIV CLASS="BILD" im "unverschmutzten" Markup. |
Nur so ein Gedanke:
Code:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> p hat jetzt die maximale Breite, für deine Aufgabenstellung scheint mir anderes nicht nötig. |
@andir
Danke erstmal für Deinen Vorschlag. Du hast mich jedoch missverstanden. Besser als in Worten ist mein Gestaltungswunsch eigentlich in den beiden Screenshots aus dem Ursprungsposting erklärt. Ich ergänze nochmal: Die H1-Box soll exakt die gleiche Breite besitzen wie die P-Box. Die Boxbreite soll 65ex (von P) betragen. Das Bild soll linksbündig an DIV class="inhalt" ausgerichtet sein. Dein Code produziert http://borumat.de/bilder/misc/temp/hc-052.png Hier sind die H1-Box und die P-Box nicht gleich breit und das Bild ist nicht linksbündig an DIV class="inhalt" ausgerichtet. |
Das dürfte deinen Erwartungen entsprechen:
Es muß lediglich nach dem p gecleart werden - wenn der Text weniger Platz braucht als das Bild hoch ist, da sonst ein nachfolgendes Bild seitlich rutschen kann. Das geht auch eleganter als mit br... aber es fällt mir grad nicht ein, vielleicht mit content:after. EDIT: Code geändert, das h1 hat mit ex ein paar Schwierigkeiten, mit em gehts. Das span dürfte mittlerweile überflüssig sein, habe damit rumprobiert, könnte aber raus. EDIT 2: Verschlankte Version hier zu sehen :) EDIT 3: Jetzt durch 30em Breite 68 Anschläge/Zeile. Maße H! / P angepasst, damit die Breite immer gleich bleibt. So: Jetzt bleibt Dir kaum noch was zu tun :) Code:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> |
Zitat:
http://borumat.de/html-und-css-tipps...ide-clear-both Ob dann Widrigkeiten auftauchen, habe ich noch nicht getestet. Ich betrachte jetzt zunächst einmal Deine interessanten Vorschläge und kommentiere sie in Bezug auf meine Intentionen. Zitat:
Zitat:
Was ist vielleicht noch wichtig für Euch zu wissen? Der Code im Ausgangsposting ist selbstverständlich nur ein stark vereinfachtes Testcase. Im richtigen Dokument kommen im Inhalt alle typischen Standardelemente vor: ULs, OLs, DLs, TABLEs, PREs, BLOCKQUOTEs Alle Stilregeln sollen für diese Elemente also nur innerhalb von DIV CLASS="INHALT" gelten. Es müssen also stets abhängige Selektoren gewählt des Typs DIV.INHALT ELEMENT{...}. Ein wichtiges Teilziel ist die gute Kontrollierbarkeit des CSS für den Autor. Dies wäre nicht mehr gegeben, wenn das CSS voll mit Hacks und komplexen Reaktionen auf diverse Widrigkeiten wäre. Dies sage ich hier nur allgemein, damit ihr meine Intention versteht. Es bezieht sich nicht auf Deinen Entwurf konkret. Essentiell für ein akzeptables CSS ist für mich, dass keine manuellen Breitenangaben notwendig sind. Zu weiteren Details Deines Entwurfs: Code:
p, h1 { Der Text soll, bei entsprechenden hohen Schriftgraden, bis an den Rand der Box DIV CLASS="INHALT" heranreichen. Code:
h1 { Sie hängt von der Breite für P ab. Eine solche Notwendigkeit möchte im CSS vermeiden. Code:
img { Ein IMG ohne umhüllendes Blockelement, wird doch automatisch als Blockelement gerendert. Den Fachjargon aus den Specs dafür habe ich gerade nicht parat. Ich habe Deinen Ansatz, zunächst P und H1 ein 1em zuzuweisen und danach H1 erst das 1.5em, ausprobiert. Aber ohne Erfolg. Code:
<style type="text/css"> Im folgenden Beispiel greife ich Deinen Ansatz, dem H1 manuell eine maximale Breite zuzuweisen, auf. Code:
<style type="text/css"> 1 Manuelle Breitenangabe im Stylesheet für H1 bzw. alle Elemente, die nicht 1em Schriftgröße besitzen. 2 Längliche Aufzählung im Stylesheet für jedes einzelne Element Code:
.inhalt p, .inhalt h1, .inhalt ul {...} Vor allem wird die typische und nützliche Zuweisung von Margins überschrieben. Beispiel UL. Hier müsste mit spezifischen Regeln nachgebessert werden. Ob die entstehenden Probleme überhaupt lösbar wären, weiß ich noch nicht. 3 Es scheint keinen Weg zu geben, bei einem Padding für DIV CLASS="INHALT" das IMG über die gesamte Boxbreite darzustellen. Ein Code:
.inhalt img{ Es gibt eben keinen Weg "zusammengesetzte" Marginbreiten zu setzen: 100%+2em Hier noch ein einfaches Testcase für dieses Detail: Code:
<style type="text/css"> |
Haben sich deine Vorgaben geändert??
Bisher waren die Überschriften doch in einer Linie mit dem Text gesetzt- was ich insofern nutzerfreundlicher finde, als ich eine direkte Zuordnung zum Text vornehmen konnte - Prinzip der Ähnlichkeit, die Zuordnung zu einer Funktion ( hier: Textbezug) ist so leichter möglich. Daher auch das Getue mit den Werten von ex oder em und das entstehende Anpassungserfordernis aufgrund unterschiedlicher Schriftgrößen. Betrachte deine Screenshots: Ich sehe bereits jetzt 3 vertikale Achsen: Überschrift, Bild, Text. Das ist mir zu unruhig. Zitat:
Zitat:
Zitat:
Meiner Empfindung nach ist der Lesefluss deutlich besser, wenn die Bilder gefloated sind und ein Text sich einem vorhergehenden optisch anschließt. Zu enge Lesespalten bei größeren Bildern könnte man durch eine min-width der entsprechenden Elemente vorbeugen. Aber vielleicht hast Du andere Vorlieben. Alternativ könntest Du ein testcase bauen und die User hier ( in einem neuem Thread, vielleicht im Forum Barrierefreiheit) zur besseren oder schlechteren Lesbarkeit der unterschiedlichen Gestaltung befragen. Davon könnten alle profitieren. Zitat:
Zitat:
Zu h1 Zitat:
Zitat:
Zitat:
Code:
Alle Kindelemente von xx {...} Mit dem Kindkombinator Code:
.inhalt > * Zitat:
Das Kindelement kann die Vorgaben des Elternelements nicht überschreiben. Was die Textpolsterung soll, hm... da würde ich doch lieber .inhalt nach außen "polstern" und ein entsprechendes margin mitgeben oder 2% weniger von 70% Breite einsetzen. Du willst ein möglichst sauberes HTML und ein möglichst schlankes CSS ohne Abhängigkeiten. Beides geht nur in bestimmten Fällen, in einfachsten Gestaltungsfragen. CSS ist ja prinzipell als dependent ( wenn auch hierarchisch dependent) angelegt. Daher erfordern Unterschiede auf einer Hierarchieebene Mehraufwand. Letztlich wird eine Entscheidung, ein Kompromiss nötig sein, wobei meine Entscheidung im Zweifel jene für das saubere HTML ist. Der leicht geänderte Code: Code:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> |
Zitat:
Ich sehe als großen Vorteil der ausgerückten Hn, dass das Auge leicht zum nächsten ähnlichen Objekt (denn Ähnlichkeit wirkt sich aus, da bin ich mit Dir einig, nur nicht über die konkrete Folgerung) springen kann: zur nächsten Überschrift. Und zum besseren Zusammenhalt von Hn plus nachfolgender Inhalt: Was genau soll zusammengehalten werden? Zu einer Überschrift gehört nicht nur der erste ihr folgende Absatz, sondern eventuell weitere Blöcke mit untergeordneten Überschriften. Kurz: ich bin mir nicht sicher, welcher Effekt der Lesbarkeit insgesamt mehr nützt. Untersuchungen zu einem direkten Vergleich der beiden diskutierten Gestaltungsvarianten kenne ich leider auch nicht. Ich gebe in einem Medium mit reichlich Platz dem Ausrücken den Vorzug - lasse mich jedoch gerne von der Unangemessenheit überzeugen. Nachdem ich auf meiner bescheidenen Seite das Ausrücken der Hn eingeführt hatte und ein halbes Dutzend Freunde um eine Bewertung hinsichtlich der Auswirkung auf die Lesbarkeit gebeten hatte, war deren Urteil eindeutig: besser. Aber so eine winzige Stichprobe sagt natürlich kaum was aus. Zitat:
Hier hat für mich das Vermeiden von Querscrollerei den höheren Rang. Aber dennoch: Dein Vorschlag, auf die Ausrückung von Hn zu verzichten, würde eine Achse weniger bedeuten und damit mehr Ruhe bedeuten. Da stimme ich Dir voll zu. Es gibt übrigends noch weitere Achsen: die Zeilenanfänge von Listen und - bei gefloateten Bilder - die neuen Achsen für die Ränder der Textboxen, etc. Zitat:
Die habe ich im Beispiel jedoch nicht betrachtet um es so prägnant wie möglich zu halten. Zitat:
Ich werde mich dann allein auf den Vergleich der Merkmale "ausgerückte/nicht ausgerückte Hn" beschränken. Etwas Geduld bitte noch. Zitat:
Ich meinte Größen, die sich daraus ableiten und die für das Funktionieren einer Gestaltung nötig sind. Es ist unschön, wenn der Autor rechnen und editieren muss, nur weil er sich entscheidet den Schriftgrad von Hn zu ändern. Zitat:
Mir liegt jedoch sowohl daran, Hn frei Schriftgrade zuweisen zu können, als auch an der Ausrückung. Zitat:
Zitat:
Ist eigentlich bei E{ margin: 0 -1em; width: 100%; } die korrekte zu rendernde Breite für E "100% plus 2em"? Zitat:
Zitat:
In aller Regel verzichte ich auch lieber beim Markup auf Verschmutzungen. Wenn die Pflegbarkeit und Verständlichkeit des CSS jedoch stark leiden würde, mache ich Zugeständnisse. In der Hoffnung, dass mit besser unterstütztem CSS, insbesondere die diversen bisher nicht unterstützten mächtigen Selektoren, das überflüssige Markup beizeiten entfernt werden kann. Zitat:
Wir können Deinen Entwurf so stehen lassen. Er befriedigt etwas andere Vorgaben als meine eigenen, ist aber auf jedenfall interessant - nicht nur, weil er das Markup nicht verschmutzt. Das CSS für Listen kann man sicher auch noch anpassen. Übrigends: sehr angenehme Diskussion mit Dir :) |
Zitat:
Textbereiche zentriert und mit maximaler Zeichenzahl pro Zeile - Bilder linksbündig und die volle Breite nutzend - kein zusätzliches Markup - Ãœberschriften nicht ausgerückt | borumat.de Ich sehe noch keine elegante Lösung für Elemente wie TABLE, die keine 100% einnehmen, oder für verschachtelte UL. Vielleicht fällt Dir noch was ein. Zum Vergleich nochmal das gleiche Dokument mit verschmutztem Markup: mit umhüllenden DIVs für die Textbereiche und mit "meinem" CSS. Textbereiche zentriert und mit maximaler Zeichenzahl pro Zeile - Bilder linksbündig und die volle Breite nutzend - mit zusätzlichen DIVs - mit ausgerückten Hn | borumat.de |
Zitat:
Das ist eben das schmutzige dran- entweder schmutzigen Code oder dickes CSS außer in Ausnahmefällen. Was haben wir denn? Einen Fließtext, q's die sich wie Fließtext verhalten können, aber mit display:block versehen werden müssen, damit sie gerückt werden können, Überschriften, Tabellen, hm, hm.... Grob gesagt: Drei Textelemente, Bilder und der ganze Rest. Macht drei Gruppen. Damit ließe sich vermutlich etwas Ordnung reinbringen- aber frag mich jetzt nicht wie. Es war ein langer Tag. Zitat:
Zu deiner Frage: Das kann ich (noch) nicht beantworten. Zitat:
Aah, es gibt eine neue Version mit Multi-Zitier-Funktion. vBulletin.com Running 3.6 - vBulletin Community Forum Mal schauen ob und wie das was taugt ;) |
Zitat:
... und die Usability der Netzwelt-Diskussionen wäre um Dimensionen besser. Klar: So eine Ketzerei richtet sich natürlich in keiner Weise gegen Dich persönlich, Hemfrie. Es ist eben Pech, dass sich so viele Webforennutzer mit so wenig Usability zufrieden geben - obwohl das objektiv bessere Medium schon lange existiert. Ich wäre schon glücklich, wenn wenigsten mehr Forentypen existieren würden, die ein Web2News- und News2Web-Gateway besitzen, wie z.B. Olympus E-System, FourThirds, E-1, E-300, E-330, E-400, E-500, E-10, E-20, E-100RS: Forum Aber die Entwickler der modernen Webforensysteme scheinen Newsserver nicht zu lieben. Leider. Sagte ich schon, dass auch Mailinglisten saugen - im Vergleich zu Newsgroups ;) |
Alle Zeitangaben in WEZ +2. Es ist jetzt 12:35 Uhr. |
Powered by vBulletin® Version 3.8.11 (Deutsch)
Copyright ©2000 - 2024, vBulletin Solutions, Inc.
© Dirk H. 2003 - 2023