inline, inline-block, inline-table

[Helmut Richter]

Aus der sehr knappen Beschreibung sowohl in der Spezifikation als auch in
Benutzungsbeschreibungen kann ich nicht entnehmen, was der Unterschied
zwischen diesen dreien ist, falls es sich um eine Tabelle handelt, also

<table style="display: inline">
<table style="display: inline-block">
<table style="display: inline-table">

Was ich erreichen will, ist dass die Tabelle als ganze als Inline-Box
behandelt wird, dass also mehrere von ihnen nebeneinander in einer Zeile
stehen, solange Platz ist. Was ich nunmehr gelernt habe, ist dass inline-block
(was ich nach einer Diskussion hier fï¿œr die Lï¿œsung hielt) falsch ist, weil es
die Tabelleneigenschaft gerade *aufhebt*, wie im Beispiel

http://test.csswg.org/suites/css2.1/20101210/xhtml1/border-collapse-applies-to-005.xht

demonstriert, wo border-collapse ignoriert wird, weil es eben keine Tabelle
mehr ist. Aber woraus hï¿œtte man das entnehmen kï¿œnnen, dass ein table-Element
dann *keine* Tabelle mehr ist? inline allein bringt noch eigenartigere
Ergebnisse (margin wird ignoriert und Tabellenteile passen nicht genau in die
Tabelle). inline-table funktioniert. Ich mag aber eigentlich nicht
ausprobieren, sondern verstehen, und dafï¿œr sind mir die Beschreibungen zu kurz
und unverstï¿œndlich. Gibts da eine einfache Beschreibung, ohne dass man
entweder ausprobieren oder Zeile fï¿œr Zeile die Spezifikation nachsimulieren
muss?

Das heiï¿œt dann auch, dass es nicht *eine* Klasse fï¿œr *alles* geben kann, was
so angeordnet werden soll, seien es nun Tabellen, Bilder, Bilder mitsamt
Bildunterschrift oder Kï¿œsten (Flieï¿œtext mit Rahmen drum). Vielmehr muss sich
der Wert von display immer nach dem richten was drin vorkommt.

--
Helmut Richter

[Bjoern Hoehrmann]

* Helmut Richter wrote in de.comm.infosystems.www.authoring.misc:

>Aus der sehr knappen Beschreibung sowohl in der Spezifikation als auch in
>Benutzungsbeschreibungen kann ich nicht entnehmen, was der Unterschied
>zwischen diesen dreien ist, falls es sich um eine Tabelle handelt, also
>
> <table style="display: inline">
> <table style="display: inline-block">
> <table style="display: inline-table">

Mit 'display' gibt man sowohl das Verhalten nach innen als auch das Ver-
halten nach aussen hin an; `inline-block` ist nach aussen hin `inline`,
nach innen hin `block`. Es gibt regelm�ssig Vorschl�ge, daraus zwei Ei-
genschaften zu machen, vielleicht hilft das, Verwirrung zu vermeiden.

>demonstriert, wo border-collapse ignoriert wird, weil es eben keine Tabelle

>mehr ist. Aber woraus h�tte man das entnehmen k�nnen, dass ein table-Element

>dann *keine* Tabelle mehr ist? inline allein bringt noch eigenartigere
>Ergebnisse (margin wird ignoriert und Tabellenteile passen nicht genau in die
>Tabelle). inline-table funktioniert. Ich mag aber eigentlich nicht

>ausprobieren, sondern verstehen, und daf�r sind mir die Beschreibungen zu kurz
>und unverst�ndlich. Gibts da eine einfache Beschreibung, ohne dass man
>entweder ausprobieren oder Zeile f�r Zeile die Spezifikation nachsimulieren
>muss?

Das scheint mir hier recht einfach, `display` nachschlagen und m�gliche
Werte durchgehen, `inline-table` hat das gew�nschte Verhalten, fertig.
--
Bj�rn H�hrmann � mailto:bjo...@hoehrmann.de � http://bjoern.hoehrmann.de
Am Badedeich 7 � Telefon: +49(0)160/4415681 � http://www.bjoernsworld.de
25899 Dageb�ll � PGP Pub. KeyID: 0xA4357E78 � http://www.websitedev.de/

[Thomas 'PointedEars' Lahn]

Helmut Richter wrote:

> Aus der sehr knappen Beschreibung sowohl in der Spezifikation als auch in
> Benutzungsbeschreibungen kann ich nicht entnehmen, was der Unterschied
> zwischen diesen dreien ist, falls es sich um eine Tabelle handelt, also
>
> <table style="display: inline">
> <table style="display: inline-block">
> <table style="display: inline-table">
>
> Was ich erreichen will, ist dass die Tabelle als ganze als Inline-Box
> behandelt wird, dass also mehrere von ihnen nebeneinander in einer Zeile
> stehen, solange Platz ist. Was ich nunmehr gelernt habe, ist dass

> inline-block (was ich nach einer Diskussion hier für die Lösung hielt)

> falsch ist, weil es die Tabelleneigenschaft gerade *aufhebt*,

Dem ist natürlich nicht so.

> wie im Beispiel
>
> http://test.csswg.org/suites/css2.1/20101210/xhtml1/border-collapse-

applies-to-005.xht
>
> demonstriert, wo border-collapse ignoriert wird, weil es eben keine
> Tabelle mehr ist.

In dem Beispiel gibt es kein table-Element.

> [Ex falso quodlibet]

Unter <http://PointedEars.de/styles/test/display-inline> findest Du einen
*relevanten* Testcase. Du solltest das Folgende sehen:

TABLE-Element mit „display: table“
-----------------------------------

Das ist die Default-Darstellung. Die Tabelle erzeugt eine Block-Level-Box,
die so breit ist wie die Summe der Spaltenbreiten zuzüglich Abständen
zwischen diesen und zur Tabellenbox:

a
,---------------------.
: ,-------. ,-------. :
: : : : : :
: `-------' `-------' :
: ,-------. ,-------. :
: : : : : :
: `-------' `-------' :
`---------------------'
b

<http://www.w3.org/TR/CSS2/tables.html>


TABLE-Element mit „display: inline“
------------------------------------

Der Tabelleninhalt wird wie der eines Inline-Elements behandelt (in WebKit
äquivalent zu „display: initial“), weshalb zwar die Zellen noch in Zeilen
und Spalten angeordnet sind, aber Abstände zwischen ihnen nicht mehr
vorhanden sind und die Tabelle keinen eigenen Rahmen hat:

a
,-------.,-------.
: :: :
:-------::-------:
: :: :
`-------'`-------'
b

<http://www.w3.org/TR/CSS2/visuren.html#inline-boxes>


TABLE-Element mit „display: block“
-----------------------------------

Wie „display: table“, jedoch wird die Tabelle nun wie jedes andere Block-
Level-Element behandelt. Die Breite der Tabelle (nicht jedoch der Spalten,
deren Zellen haben weiterhin „display: table-cell“) wird von der Breite der
inneren Elternbox definiert (sofern nicht mit „width“ oder „max-width“ etwas
anderes angegeben wurde):

a
,--------------------------------------------------------------------.
: ,-------. ,-------. :
: : : : : :
: `-------' `-------' :
: ,-------. ,-------. :
: : : : : :
: `-------' `-------' :
`--------------------------------------------------------------------'
b

<http://www.w3.org/TR/CSS2/visuren.html#block-boxes>


TABLE-Element mit „display: inline-block“
------------------------------------------

Wie „display: inline“, jedoch wird die Tabelle als Inline-Level-Element
behandelt, d. h. als Teil des Fliesstextes (wie ein Wort oder Zeichen), aber
ihr Inhalt wie der eines Block-Level-Elements. Daher bleiben die Zeilen und
Spalten erhalten und die Unterkante der Tabelle befindet sich auf der
Grundlinie (mit ASCII-Art nicht exakt darstellbar):

,---------------------.
: ,-------. ,-------. :
: : : : : :
: `-------' `-------' :
: ,-------. ,-------. :
: : : : : :
: `-------' `-------' :
a `---------------------' b

<http://www.w3.org/TR/CSS2/visuren.html#propdef-display>


TABLE-Element mit „display: inline-table“
------------------------------------------

Wie „display: inline“, jedoch wird die Tabelle als Inline-Tabelle behandelt,
d. h. als Teil des Fliesstextes, aber nicht so wie Text. Daher bleibt die
Tabelle unverändert, gehört aber zur Zeile und ragt über die Grundlinie
hinaus:

,---------------------.
a : ,-------. ,-------. : b
: : : : : :
: `-------' `-------' :
: ,-------. ,-------. :
: : : : : :
: `-------' `-------' :
`---------------------'

<http://www.w3.org/TR/CSS2/tables.html#table-display>


HTH

PointedEars

--
Was funktioniert in Tabellen bei NN4 wirklich verläßlich? Nicht mal die
Abstürze in Zusammenhang mit Tabellen sind verläßlich, auch wenn sie
häufig vorkommen. (Georg Maaß in dcljs <3D6CCAEC...@vnett.de>)

[Thomas 'PointedEars' Lahn]

Michael Holzt wrote:

> Bjoern Hoehrmann wrote:
>> Mit 'display' gibt man sowohl das Verhalten nach innen als auch das Ver-
>> halten nach aussen hin an; `inline-block` ist nach aussen hin `inline`,

>> nach innen hin `block`. Es gibt regelmässig Vorschläge, daraus zwei Ei-

>> genschaften zu machen, vielleicht hilft das, Verwirrung zu vermeiden.
>

> Man kann sich die Aufteilung natürlich auch selber machen, indem man die
> fraglichen Elemente (also z.B. die Table) in ein DIV packt und dann die
> inline-block Eigenschaft nur auf das DIV anwendet.

Dann werden mehrere table-Elemente im div-Element jedoch nicht nebeneinander
dargestellt. (Und mehrere div-Elemente, die lediglich je ein table-Element
enthalten, sind ein Symptom für Divitis.) Das ist also nicht äquivalent zu
„display: inline-block“ oder „display: inline-table“ für das table-Element.

Als Alternative zur Deklaration der display-Eigenschaft für table-Elemente
gibt es für nebeneinanderstehende, automatisch an den Elementgrenzen zu
umbrechende Elemente auch noch „float: left“ bzw. „float: right“. Wobei man
dann auf mindestens „clear: left“ bzw. „clear: right“ danach achten sollte.
Floatende Block-Level-Boxen haben gegenüber Inline-Boxen den Vorteil, dass
man mit ersteren maximale Kontrolle über die Abstände zwischen den Block-
Level-Boxen hat, während die Abstände von Inline-Boxen über die „font-size“
und die Breite des Leerzeichens definiert sind.


PointedEars
--
Wo im W3C-DOM für XML ist document.write spezifiziert? Nirgendwo. Das
geht also nicht, Du mußt das Dokument Knötchen für Knötchen aufbauen.
Soviel vom W3C zum Thema "Verstehen Sie Spaß???".
(Georg Maaß in dcljs <an91cq$c0ogv$1...@ID-3551.news.dfncis.de>)

[Helmut Richter]

On Sun, 24 Mar 2013, Thomas 'PointedEars' Lahn wrote:

> Michael Holzt wrote:
>
> > Bjoern Hoehrmann wrote:
> >> Mit 'display' gibt man sowohl das Verhalten nach innen als auch das Ver-
> >> halten nach aussen hin an; `inline-block` ist nach aussen hin `inline`,
> >> nach innen hin `block`. Es gibt regelmässig Vorschläge, daraus zwei Ei-
> >> genschaften zu machen, vielleicht hilft das, Verwirrung zu vermeiden.

Ich suchte nach einer Spezifikation, die das Verhalten "inline" nach außen
erzwingt, aber dabei innen alles gleich lässt, egal was es ist: ein "div"
bleibt ein "div", eine "table" bleibt eine "table". Und das gibt es scheints
nicht.

> > Man kann sich die Aufteilung natürlich auch selber machen, indem man die
> > fraglichen Elemente (also z.B. die Table) in ein DIV packt und dann die
> > inline-block Eigenschaft nur auf das DIV anwendet.

> Dann werden mehrere table-Elemente im div-Element jedoch nicht nebeneinander
> dargestellt. (Und mehrere div-Elemente, die lediglich je ein table-Element
> enthalten, sind ein Symptom für Divitis.)

Ich nehme an, die Version in Klammern war gemeint. Was die Divitis angeht: Ich
bin kein Freund von Divitis, aber hier kommt sie mir angebracht vor: beliebige
Elemente, die so angeordnet werden sollen, haben gemeinsame Eigenschaften,
z.B. Margins, nur in der display-Eigenschaft unterscheiden sie sich: da
müssen divs zu inline-block werden, tables zu inline-tables. Das macht ein
Stylesheet unübersichtlich: lieber nur *eine* Klasse mit einer Latte
Eigenschaften für alles was inline angeordnet werden soll. Eine solche Klasse
kann aber nicht für Tabellen wie für anderes gelten, weil man das bei der
display-Eigenschaft wieder auseinanderfahren muss.

> Als Alternative zur Deklaration der display-Eigenschaft für table-Elemente
> gibt es für nebeneinanderstehende, automatisch an den Elementgrenzen zu
> umbrechende Elemente auch noch „float: left“ bzw. „float: right“. Wobei man
> dann auf mindestens „clear: left“ bzw. „clear: right“ danach achten sollte.
> Floatende Block-Level-Boxen haben gegenüber Inline-Boxen den Vorteil, dass
> man mit ersteren maximale Kontrolle über die Abstände zwischen den Block-
> Level-Boxen hat, während die Abstände von Inline-Boxen über die „font-size“
> und die Breite des Leerzeichens definiert sind.

Der Nachteil von "float" ist, dass die nicht von links nach rechts angeordnet
werden, sondern jede Box von rechts herangeschoben wird, bis sie auf
Widerstand stößt. Das wird *sehr* hässlich, wenn beim Zeilenumbruch die
vorletzte Box kürzer ist als die letzte; dann landet die nächste, die nicht
mehr in die Zeile gepasst hat, unter der vorletzten und nicht links. Sind alle
gleich groß, dann gehts. Und doch: margin funktioniert auch bei inline-block.

--
Helmut Richter

[Helmut Richter]

On Tue, 26 Mar 2013, Helmut Richter wrote:

> Der Nachteil von "float" ist, dass die nicht von links nach rechts angeordnet
> werden, sondern jede Box von rechts herangeschoben wird, bis sie auf
> Widerstand stößt. Das wird *sehr* hässlich, wenn beim Zeilenumbruch die
> vorletzte Box kürzer ist als die letzte; dann landet die nächste, die nicht

falsch: wenn sie *länger* ist: nur dann bleibt die nächste vor rechts
herangeschobene float-Box an ihr hängen.

--
Helmut Richter

[Thomas 'PointedEars' Lahn]

Helmut Richter wrote:

> On Sun, 24 Mar 2013, Thomas 'PointedEars' Lahn wrote:
>> Michael Holzt wrote:
>> > Bjoern Hoehrmann wrote:
>> >> Mit 'display' gibt man sowohl das Verhalten nach innen als auch das
>> >> Ver- halten nach aussen hin an; `inline-block` ist nach aussen hin
>> >> `inline`, nach innen hin `block`. Es gibt regelmässig Vorschläge,
>> >> daraus zwei Ei- genschaften zu machen, vielleicht hilft das,
>> >> Verwirrung zu vermeiden.
>
> Ich suchte nach einer Spezifikation, die das Verhalten "inline" nach außen
> erzwingt, aber dabei innen alles gleich lässt, egal was es ist: ein "div"
> bleibt ein "div", eine "table" bleibt eine "table". Und das gibt es
> scheints nicht.

Na sicher doch, „inline-block“. Hatte ich auch erklärt und referenziert.
Hast Du meinen Testcase überhaupt angesehen?

Deine Ansicht, dass „inline-block“ hier nicht der richtige Wert für die
display-Eigenschaft sei, ist irrig. Das „block“ in „inline-block“ definiert
(wie Björn bereits schrieb) nicht die display-Eigenschaft der Kindelemente,
sondern den Typ der *inneren Box* des so formatierten Elements. Solange die
tr-, th- und td-Elemente weiterhin „display: table-row“ und „display: table-
cell“ haben, ändert sich nichts.

„display: inline-block“ und „display: inline-table“ unterscheiden sich
AFAICS nur in der Ausrichtung der Tabelle auf der Zeile: bei „inline-block“
befindet sich die Unterkante der Tabelle auf der Grundlinie (baseline), bei
„inline-table“ hingegen ihre Oberkante auf der Höhe der k-Linie (ascent;
CMIIW) und sie ragt ggf. über die Grundlinie hinaus.

>> > Man kann sich die Aufteilung natürlich auch selber machen, indem man
>> > die fraglichen Elemente (also z.B. die Table) in ein DIV packt und dann
>> > die inline-block Eigenschaft nur auf das DIV anwendet.
>
>> Dann werden mehrere table-Elemente im div-Element jedoch nicht
>> nebeneinander dargestellt. (Und mehrere div-Elemente, die lediglich je
>> ein table-Element enthalten, sind ein Symptom für Divitis.)
>
> Ich nehme an, die Version in Klammern war gemeint.
>
> Was die Divitis angeht:
> Ich bin kein Freund von Divitis, aber hier kommt sie mir angebracht vor:
> beliebige Elemente, die so angeordnet werden sollen, haben gemeinsame
> Eigenschaften, z.B. Margins, nur in der display-Eigenschaft unterscheiden
> sie sich: da müssen divs zu inline-block werden, tables zu inline-tables.

Nein.

> Das macht ein Stylesheet unübersichtlich: lieber nur *eine* Klasse mit
> einer Latte Eigenschaften für alles was inline angeordnet werden soll.
> Eine solche Klasse kann aber nicht für Tabellen wie für anderes gelten,
> weil man das bei der display-Eigenschaft wieder auseinanderfahren muss.

Non sequitur. Jedoch ist das Problem trivial lösbar (wenn man das *so*
will):

.inline-block {
display: inline-block;
}

table.inline-block {
display: inline-table;

}

>> Als Alternative zur Deklaration der display-Eigenschaft für
>> table-Elemente gibt es für nebeneinanderstehende, automatisch an den
>> Elementgrenzen zu umbrechende Elemente auch noch „float: left“ bzw.
>> „float: right“. Wobei man dann auf mindestens „clear: left“ bzw. „clear:
>> right“ danach achten sollte. Floatende Block-Level-Boxen haben gegenüber
>> Inline-Boxen den Vorteil, dass man mit ersteren maximale Kontrolle über
>> die Abstände zwischen den Block- Level-Boxen hat, während die Abstände
>> von Inline-Boxen über die „font-size“ und die Breite des Leerzeichens
>> definiert sind.
>
> Der Nachteil von "float" ist, dass die nicht von links nach rechts
> angeordnet werden, sondern jede Box von rechts herangeschoben wird, bis
> sie auf Widerstand stößt. Das wird *sehr* hässlich, wenn beim
> Zeilenumbruch die vorletzte Box kürzer ist als die letzte; dann landet die
> nächste, die nicht mehr in die Zeile gepasst hat, unter der vorletzten und
> nicht links.

Unfug. Wofür auch immer Du hier table-Elemente zu brauchen glaubst: Auch
diese ordnen sich mit “float: left” korrekt an, wenn man die Margins
vernünftig setzt.

> Sind alle gleich groß, dann gehts.

Non sequitur. Dasselbe Problem hast Du bei „inline-block“ und „inline-
table“ auch, bloss dort hast Du keine Kontrolle über die Abstände zwischen
den Boxen, ausser Du schreibst keinen Whitespace zwischen die End- und
Start-Tags und Deine Elemente sind nie höher als allenfalls umgebender Text.

> Und doch: margin funktioniert auch bei inline-block.

Natürlich, *zusätzlich* zum Wort- und Zeilenabstand.


PointedEars
--
Use any version of Microsoft Frontpage to create your site.
(This won't prevent people from viewing your source, but no one
will want to steal it.)
-- from <http://www.vortex-webdesign.com/help/hidesource.htm> (404-comp.)

[Helmut Richter]

On Tue, 26 Mar 2013, Thomas 'PointedEars' Lahn wrote:

> Deine Ansicht, dass „inline-block“ hier nicht der richtige Wert für die
> display-Eigenschaft sei, ist irrig. Das „block“ in „inline-block“ definiert
> (wie Björn bereits schrieb) nicht die display-Eigenschaft der Kindelemente,
> sondern den Typ der *inneren Box* des so formatierten Elements. Solange die
> tr-, th- und td-Elemente weiterhin „display: table-row“ und „display: table-
> cell“ haben, ändert sich nichts.

Richtig, aber die table selbst ist nicht mehr display: table.

Weil weder das von mir angeführte Beispiel noch deine Beispiele den Fall
bringen, den ich meinte, habe ich selbst eines gemacht: das obere in
http://hr.userweb.mwn.de/srv/table.html

> Unfug. Wofür auch immer Du hier table-Elemente zu brauchen glaubst: Auch
> diese ordnen sich mit “float: left” korrekt an, wenn man die Margins
> vernünftig setzt.

Dazu das untere Beispiel a.a.O.

Man sieht dabei auch die von dir erwähnte zusätzliche Breite des Leerzeichens;
richtig -- das muss man berücksichtigen.

--
Helmut Richter

[Thomas 'PointedEars' Lahn]

Helmut Richter wrote:

> On Tue, 26 Mar 2013, Thomas 'PointedEars' Lahn wrote:
>> Deine Ansicht, dass „inline-block“ hier nicht der richtige Wert für die
>> display-Eigenschaft sei, ist irrig. Das „block“ in „inline-block“
>> definiert (wie Björn bereits schrieb) nicht die display-Eigenschaft der
>> Kindelemente,
>> sondern den Typ der *inneren Box* des so formatierten Elements. Solange
>> die tr-, th- und td-Elemente weiterhin „display: table-row“ und „display:
>> table- cell“ haben, ändert sich nichts.
>
> Richtig, aber die table selbst ist nicht mehr display: table.
>
> Weil weder das von mir angeführte Beispiel noch deine Beispiele den Fall
> bringen, den ich meinte, habe ich selbst eines gemacht: das obere in
> http://hr.userweb.mwn.de/srv/table.html

ACK. Von „border-collapse“ und Zeilenrahmen lasse ich noch die Finger
aufgrund inkompatibler Darstellung. Daher war mir der nicht
zusammenfallende Zeilenrahmen bei “display: inline-block” nie aufgefallen.
Sonst sehe da keine signifikanten Unterschiede.

Wenn das also ein Problem ist, wirst Du wohl doch zwei Regeln brauchen. Ich
sehe aber darin immer noch nicht die von Dir behaupteten grossen Probleme.

>> Unfug. Wofür auch immer Du hier table-Elemente zu brauchen glaubst: Auch
>> diese ordnen sich mit “float: left” korrekt an, wenn man die Margins
>> vernünftig setzt.
>
> Dazu das untere Beispiel a.a.O.

Faszinierend: Abnehmende Höhen der Floats machen Float-Designs „kapott“.
(Da gibt es wohl einen Fehler in der Matrix[tm].)


PointedEars
--
Man kann mit JavaScript eine große Zahl von Roundtrips eliminieren und
damit die Usability erhöhen. Allerdings übersteigen die Möglichkeiten
von JavaScript die zerebralen Fähigkeiten der meisten Webmaster bei
Weitem. -- Johann Burkard in dag°

[Helmut Richter]

On Tue, 26 Mar 2013, Thomas 'PointedEars' Lahn wrote:

> >> Unfug. Wofür auch immer Du hier table-Elemente zu brauchen glaubst: Auch
> >> diese ordnen sich mit “float: left” korrekt an, wenn man die Margins
> >> vernünftig setzt.
> >
> > Dazu das untere Beispiel a.a.O.
>
> Faszinierend: Abnehmende Höhen der Floats machen Float-Designs „kapott“.
> (Da gibt es wohl einen Fehler in der Matrix[tm].)

Der Algorithmus bei float ist schon klar: man platziert das nächste Teil ganz
an den rechten Rand des umfassenden Blocks. Solange es Konflikte gibt, schiebt
man es nach unten. Danach schiebt man es nach links, solange es keine
Konflikte gibt. An einer überstehenden Ecke bleibt es dann hängen, es sei
denn, es gibt keine bis zum linken Rand. Das Hindernis (hier ein höheres
Float) wird aber nie übersprungen, auch wenn weiter links noch Platz wäre. Der
Algorithmus bei inline-... ist einfacher: wenn rechts neben dem letzten kein
Platz ist, wird eine ganz neue, ganz leere Zeile angefangen (genau wie es bei
"float" mit "clear" gemacht würde).

Welches Verhalten schöner ist, ist (a) Geschmacksache und (b) von der
Verteilung der Höhen abhängig. Mein erster Anwendungsfall ist eine lange,
untergliederte Wörterliste zum Lernen, bei der es ärgerlich unübersichtlich
wäre, wenn 3/4 des Bildschirms weiß bleiben, ich aber nicht weiß, wieviel
Platz zum nebeneinanderschreiben da ist:
http://hr.userweb.mwn.de/kiswahili/k2/verb.html (wird verlegt, sobald ich ein
besseres Stylesheet habe -- das soll aber möglichst nicht nur gerade diesen
einen Anwendungsfall abdecken, daher die lange Diskussion). Für diese
Anwendung hat der zweite Algorithmus in der Regel die schöneren Resultate, und
aus Gründen, von denen ich erwarte, dass sie nicht *nur* genau hier gelten.

--
Helmut Richter

[Thomas 'PointedEars' Lahn]

Helmut Richter wrote:

> On Tue, 26 Mar 2013, Thomas 'PointedEars' Lahn wrote:
>> >> Unfug. Wofür auch immer Du hier table-Elemente zu brauchen glaubst:
>> >> Auch diese ordnen sich mit “float: left” korrekt an, wenn man die
>> >> Margins vernünftig setzt.
>> >
>> > Dazu das untere Beispiel a.a.O.
>>
>> Faszinierend: Abnehmende Höhen der Floats machen Float-Designs „kapott“.
>> (Da gibt es wohl einen Fehler in der Matrix[tm].)
>

> Der Algorithmus bei float ist schon klar: […]

Du hast das „[tm]“ gesehen?


PointedEars
--
realism: HTML 4.01 Strict
evangelism: XHTML 1.0 Strict
madness: XHTML 1.1 as application/xhtml+xml
-- Bjoern Hoehrmann