nicht angemeldet
Analyse zum Problem fester Tabellen- u.Zellbreiten im IE+Mozilla
Hallo SelfHTML-er!
Angeregt durch ein heutiges Posting (http://forum.de.selfhtml.org/?m=116194&t=20759) habe ich versucht, das Problem der festen Breitenangaben von Tabellen und Tabellenzellen etwas genauer zu beleuchten.
Das Problem:
Wenn der Inhalt einer Tabellenzelle breiter ist, als die Zelle und kein Zeilenmbruch möglich ist, wird die Zelle und unter Umständen die Tabelle automatisch breiter. Das kann aber dem Wunsch nach präzisem Layout - ohne dies an sich bewerten zu wollen - entgegenstehen.
Ich habe das Forum-Archiv von 1999 bis heute durchsucht und festgestellt, dass hierzu nur zum Teil befriedigende Lösungen gefunden wurden, die in keinem Fall für einen anderen Browser als den IE funktionieren. Mir ist es immerhin gelungen, auch für Mozilla, und damit für NS6+ eine Lösung herauszuarbeiten (siehe 3. Lösung).
Lösungen:
1. Man verwendet keine Tabellen. Sicherlich die naheliegendeste und gebräuchlichste Methode: für pixelgenaues Design bieten sich in der Regel <div>-Elemente an.
2. CSS-Lösung wie in SelfHTML:
http://selfhtml.teamone.de/css/eigenschaften/tabellen.htm#table_layout
Damit wird der überschüssige Rest einer Zelle einfach "gnadenlos" abgeschnitten. Dies ist aber der gewünschte Effekt: Die Breitenangaben sollen Vorrang haben.
<table border="1" style="table-layout:fixed">
<colgroup span="3" style=""></colgroup>
<tr>
<td style="width:100px">123456789012345678901234567890123456789012345678901234567890</td>
<td style="width:200px">123456789012345678901234567890123456789012345678901234567890</td>
<td style="width:300px">123456789012345678901234567890123456789012345678901234567890</td>
</tr>
</table>
Entscheidend ist hier neben den width-Angaben der Zellen das "table-layout:fixed" im table-tag. Aber, wie in diesem SelfHTML-Abschnitt weiter unten angemerkt wird: "Netscape 6.x interpretiert diese Eigenschaft wohl, hatte aber Probleme bei der Darstellung. Eine width-Zuweisung an das table-Element brachte ihn dazu, die Anzeige zu verhauen, und das obige Beispiel mit der width-Zuweisung an einzelne Zellen, um damit die Breite der Tabelle festzulegen, ignorierte er."
...so ist es: das funktioniert nur im IE.
3. CSS-Lösung für IE _und_ Mozilla:
Mozilla/NS6+ akzeptieren obige Lösung nur, wenn ein paar Modifikationen vorgenommen werden:
<table border="1" style="table-layout:fixed;width:602px;" cellpadding="0" cellspacing="0">
<tr>
<td style="width:100px;overflow:hidden;">123456789012345678901234567890123456789012345678901234567890</td>
<td style="width:200px;overflow:hidden;">123456789012345678901234567890123456789012345678901234567890</td>
<td style="width:300px;;overflow:hidden;">123456789012345678901234567890123456789012345678901234567890</td>
</tr>
</table>
Jede Zelle braucht die style-Angabe "overflow:hidden" zusätzlich zur width-Angabe. Darüber hinaus muss im table-tag die Gesamtbreite des Tables angegeben werden - oder einfach ein Wert der kleiner ist als die Gesamtbreite. "1px" funktioniert also immer. Wenn man aber die gesamte Tabelle auf eine exakte Breite trimmen will, sollte man wissen, wie sich ihre volle Ausdehnung zusammensetzt:
Gesamtbreite = (Summe aller Zellenbreiten)px + (Summe aller cellspacings)px + (border-Wert*2)px
Summe aller Zellen: selbsterklärend, im obigen Beispiel 100+200+300=600 Pixel.
Summe aller spacings: Hier gilt die maximale Anzahl der Spacings, falls man Gebrauch von "colspan" gemacht hat. Beispiel:bei einer Tabelle mit 3 Zellen in einer Zeile gibt es 4 spacings. Angenommen, das cellspacing beträgt 2 pixel, bedeutet das, die Gesamtbreite der Tabelle wächst um 4 mal 2 = 8Pixel.
Border-Wert mal zwei: da der Borderwert ja auf der linken und rechten Seite anfällt.
Man sollte im Prinzip immer die richtige Gesamtbreite im table-tag angeben, und nicht mit einem kleineren Wert "zaubern".
Übrigens schneiden IE und Mozilla so nicht nur überstehende Zeichenfolgen ab, sondern auch Bilder.
Diese Lösung habe ich so noch nirgends gesehen, und ich denke, sie ist ein Fortschritt gegenüber der Lösung Nr.2. Allerdings funktioniert sie nicht im Opera und schon gar nicht im NS4.
Nach wie vor gilt natürlich, dass für pixelgenaues Design andere Elemente wie <div> bevorzugt weden sollten. Aber auch das <table>-Element mit exakten Maßen kann für bestimmte Anforderungen seine Berechtigung haben.
Über Kommentare, Verbesserungsvorschläge und Anregungen würde ich mich freuen!
Grüße, Inzaire
ps: Ich wusste nicht, ob ich dieses Thema zu HTML, CSS oder Browser stecken soll - habe einfach mal CSS genommen.
-
Angeregt durch ein heutiges Posting (http://forum.de.selfhtml.org/?m=116194&t=20759) habe ich versucht, das Problem der festen Breitenangaben von Tabellen und Tabellenzellen etwas genauer zu beleuchten.
Das Problem:
Wenn der Inhalt einer Tabellenzelle breiter ist, als die Zelle und kein Zeilenmbruch möglich ist, wird die Zelle und unter Umständen die Tabelle automatisch breiter.Welch' Katastroph'! Oder anders ausgedrückt: Wer keine Probleme hat, macht sich welche.
Die eigentliche Frage, über die man sich hier doch wohl eher Gedanken machen sollte, ist, ob das Layout allen Ernstes dermaßen den Inhalt bestimmen darf bzw. -wie von Dir sogar vorgeschlagen- tottrampeln soll.
Es kann doch nicht wirklich ein Lösungsvorschl
sein, die Eigenschaften des betreffenden Eleme
so festzulegen, daß ein Teil des Inhaltes einf
abgeschnitten wird, nur damit das Element nich
zu breit wird und das Layout nicht auseinanderWer zu solchen Mitteln greift, hat in der Webseitengestaltung nichts zu suchen und sollte lieber wieder mit Bleistift und Tuschkasten auf Papier malen, denn er hat schlicht und ergreifend das zu Grunde liegende Prinzip von Webseiten nicht einmal ansatzweise verstanden.
Webseiten sind von Natur aus fließend und es kann doch eigentlich nicht so unglaublich schwer sein, sich zumindest ein kleines bißchen danach zu richten.
Gruß,
soenk.e-
Ich gehe mal zu deinen Gunsten davon aus, dass du mein posting nur nicht richtig gelesen hast ;).
Ich fordere nicht, jede Tabelle so anzulegen, wie ich es beschrieben habe. Sondern es geht um einen speziellen Fall. Und dieser Fall wird häufig in diesem Forum nachgefragt - so häufig, dass es fast schon ein Kandidat für die FAQ wäre. Nicht ich mache mir ein Problem, sondern viele haben eins, so wie ich es beschrieben habe - und so wie es in SelfHTML, an der von mir zitierten Stelle beschrieben ist. Nochmal der link, falls er dir entgangen sein sollte:
http://selfhtml.teamone.de/css/eigenschaften/tabellen.htm#table_layoutDie eigentliche Frage, über die man sich hier doch wohl eher Gedanken machen sollte, ist, ob das Layout allen Ernstes dermaßen den Inhalt bestimmen darf bzw. -wie von Dir sogar vorgeschlagen- tottrampeln soll.
Nicht zwangsläufig von mir, aber vom W3C. "table-layout:fixed" und "overflow:hidden" gibt es nunmal, und sie sind genau dafür entwickelt worden, ob es dir gefällt oder nicht :p
Wer zu solchen Mitteln greift, hat in der Webseitengestaltung nichts zu suchen
Was soll denn das? :(
und sollte lieber wieder mit Bleistift und Tuschkasten auf Papier malen, denn er hat schlicht und ergreifend das zu Grunde liegende Prinzip von Webseiten nicht einmal ansatzweise verstanden.
Ich denke, da solltest du etwas toleranter sein - das web ist es jedenfalls. Ich habe das Prinzip des fließenden Textes m.E. gut verstanden, und wenn ich einen HTML-Kurs halte, ist das mit das erste, was ich anhand von verschiedenen Browsergrößen demonstriere. Aber wie gesagt, was ich angesprochen habe, ist ein ganz spezielles, eingegrenztes Problem - ein Sonderfall, wenn du so willst, und selbst für diesen habe ich mehrfach erwähnt, dass es andere, zu bevorzugende Lösungen gibt.
Gruß und nix für ungut,
Inzaire-
Hallo Inzaire
Ich habe genau dasselbe Problem.
Sobald ich in der unteren <td> etwas schreibe, zieht es mir die obere <td> auseinader. In der oberen <td> befinden sich Grafiken und die müssen nunmal zusammenpassen!Werde dein Lösung ausprobieren, wenn ich eine andere Lösung finde, schreib ich wieder.
greez
Andre -
Nicht ich mache mir ein Problem, sondern viele haben eins, so wie ich es beschrieben habe - und so wie es in SelfHTML, an der von mir zitierten Stelle beschrieben ist. Nochmal der link, falls er dir entgangen sein sollte:
http://selfhtml.teamone.de/css/eigenschaften/tabellen.htm#table_layoutDas Problem, auf das Du Dich bezogen hattest (zu breite Texte für das existierende Layout), ist auf dieser Seite nicht beschrieben. Ich sehe da nur etwas von dem "Vorteil, dass große Tabellen schneller angezeigt werden können".
Die eigentliche Frage, über die man sich hier doch wohl eher Gedanken machen sollte, ist, ob das Layout allen Ernstes dermaßen den Inhalt bestimmen darf bzw. -wie von Dir sogar vorgeschlagen- tottrampeln soll.
Nicht zwangsläufig von mir, aber vom W3C. "table-layout:fixed" und "overflow:hidden" gibt es nunmal, und sie sind genau dafür entwickelt worden, ob es dir gefällt oder nicht :p
table-layout:fixed ist AFAIK eine Microsoft-Idee, dann würde hier auch die Microsoft-Erklärung gelten: Schnellerer Aufbau bei großen Tabellen.
"You can optimize table rendering performance by specifying the
tableLayout property. This property causes Microsoft® Internet
Explorer to render the table one row at a time, providing users
with information at a faster pace."
http://msdn.microsoft.com/workshop/author/dhtml/reference/properties/tablelayout.aspVon Abschneiden ist da nirgendwo die Rede. Und auch das W3C sagt eher etwas zur Aufbaugeschwindigkeit als zum Zementieren des Tabellenlayouts:
"User agents may use any algorithm they wish to do so, and are free
to prefer rendering speed over precision, except when the 'fixed
layout algorithm' is selected."
http://www.w3.org/TR/REC-CSS2/tables.html#width-layoutBei overflow hast Du zwar Recht, daß es dort einen Wert zum Abschnippeln gibt, aber der steht auch neben scroll und visible, nicht so ganz alleine. Und ich kann mir irgendwie nicht so recht vorstellen, daß ausgerechnet das W3C - Hort der Standards und Systemunabhängigkeit, Prediger des "Texte müssen überall angezeigt werden können" - overflow:hidden dazu erdacht hat, verhinderten Tabellen-Künstlern eine Chance zu geben.
was ich angesprochen habe, ist ein ganz spezielles, eingegrenztes Problem - ein Sonderfall, wenn du so willst,
Eben. In Deinem Sonderfall aus <?m=116194&t=20759> ging es um Texte, die nicht in eine Tabelle passen, die unbedingt 200 Pixel breit sein muß. Wahrscheinlich auch eher kein Sonderfall sondern ein Standardproblem von HTML-Anfängern, wie Du selbst ja bereits mit dem Hinweis der FAQ-Würdigkeit angedeutet hast.
Das Ergebnis Deiner Bemühungen zur Beseitigung eines meiner Ansicht nach vielmehr grundsätzlichen Verständnisproblems mit einer Handvoll Pauschallösungen habe ich dann (offensichtlich vollends erfolglos) folgendermaßen darzustellen versucht:
Es kann doch nicht wirklich ein Lösungsvorschl
sein, die Eigenschaften des betreffenden Eleme
so festzulegen, daß ein Teil des Inhaltes einf
abgeschnitten wird, nur damit das Element nich
zu breit wird und das Layout nicht auseinanderAuch wenn's übertrieben aussieht, ich halte diese Darstellung für wenig optimal und bleibe bei der enthaltenen Aussage: Wenn Text nicht in's Layout passt, hat sich das Layout zu ändern, nicht der Text zu verschwinden.
Genau da gilt es in jedem einzelnen Fall neu anzusetzen; ein pauschaler Hinweis auf overflow geht doch eher nach hinten los, wenn es noch am -sagen wir mal- grundlegenden Problembewusstsein fehlt.und selbst für diesen [Sonderfall] habe ich mehrfach erwähnt, dass es andere, zu bevorzugende Lösungen gibt
Deine Alternativen waren pixelgenaues Arbeiten mit <div>s, pixelgenaues Arbeiten mit table-layout:fixed und, weil letztere nicht immer funktioniert, pixelgenaues Arbeiten mit table-layout:fixed und overflow:hidden. In allen drei Fällen soll der Text dem Layout zu Gunsten abgeschnitten werden dürfen (auch ein <div> kann "zu breit" werden, da ist kein großer Unterschied zu einer Tabelle).
Die von mir propagierte Lösung, doch mal das Layout grundsätzlich zu überdenken, hast Du nicht genannt - allerhöchstens um drei Ecken mit dem verschämten Hinweis, daß Du Deine Vorschläge bzw. pixelgenaues Layout nicht bewerten möchtest.
Möchtest Du behaupten, daß jemand auf Grund dieses Winks mit dem Zahnstocher anfängt, sich grundlegende Gedanken über möglicherweise auftretende Probleme und ein flüssigeres Layout zu machen, wenn er zwei Zeilen darunter das Seil zum Festhalten seiner auseinanderfallenden Tabellen auf dem Silbertablett serviert bekommt? Erscheint mir etwas naiv.Gruß,
soenk.e-
Nicht ich mache mir ein Problem, sondern viele haben eins, so wie ich es beschrieben habe - und so wie es in SelfHTML, an der von mir zitierten Stelle beschrieben ist. Nochmal der link, falls er dir entgangen sein sollte:
http://selfhtml.teamone.de/css/eigenschaften/tabellen.htm#table_layoutDas Problem, auf das Du Dich bezogen hattest (zu breite Texte für das existierende Layout), ist auf dieser Seite nicht beschrieben. Ich sehe da nur etwas von dem "Vorteil, dass große Tabellen schneller angezeigt werden können".
Dann lies genauer: ich habe in meinem ursprünglichen Posting sogar wörtlich aus SelfHTML zitiert, und mache es hiermit nochmal:
"Netscape 6.x interpretiert diese Eigenschaft wohl, hatte aber Probleme bei der Darstellung. Eine width-Zuweisung an das table-Element brachte ihn dazu, die Anzeige zu verhauen, und das obige Beispiel mit der width-Zuweisung an einzelne Zellen, um damit die Breite der Tabelle festzulegen, ignorierte er."
Direkt darüber steht:
"Erläuterung:
Mit table-layout: beeinflussen Sie die Tabellenanzeige bei Breitenangaben. Folgende Angaben sind erlaubt:
fixed = Breitenangaben haben Vorrang vor dem Zelleninhalt.
auto = Zelleninhalt hat Vorrang vor Breitenangaben (Voreinstellung)."Also nochmal: fixed = Breitenangaben haben Vorrang vor dem Zelleninhalt.
Ich habe mich auf die Angabe in SelfHTML verlassen, die diese Eigenschaft als dem CSS2-Standard zugehörig markiert.
Von Abschneiden ist da nirgendwo die Rede. Und auch das W3C sagt eher etwas zur Aufbaugeschwindigkeit als zum Zementieren des Tabellenlayouts:
"User agents may use any algorithm they wish to do so, and are free
to prefer rendering speed over precision, except when the 'fixed
layout algorithm' is selected."
http://www.w3.org/TR/REC-CSS2/tables.html#width-layoutWas bedeutet: Wenn "fixed layout algorythm", also table-layout:fixed angegeben ist, muss der user agent diese Angabe respektieren. (entscheidend ist das Wort "except".) Q.e.d.
Thx übrigens für den link - genau unterhalb des von dir Angegebenen steht _explizit_ das, was ich beschreibe! :) Zitat:
"Fixed table layout
With this (fast) algorithm, the horizontal layout of the table does not depend on the contents of the cells; it only depends on the table's width, the width of the columns, and borders or cell spacing."..und weiter unten analog zu meiner Beschreibung der Gesamtbreite des tables:
"The width of the table is then the greater of the value of the 'width' property for the table element and the sum of the column widths (plus cell spacing or borders)."[...]ein pauschaler Hinweis auf overflow geht doch eher nach hinten los, wenn es noch am -sagen wir mal- grundlegenden Problembewusstsein fehlt.
Es war nicht die Intention meines kurzen Artikels dieses Problembewusstsein zu schärfen - das kann man in konkreten Fall ja tun, wenn es angezeigt ist, und du kannst mir glauben, ich tue das auch. Mein Posting befasst sich aber nur mit einer technischen Lösung.
Das wäre wie wenn ich in einem Autoschrauber-Forum beschreibe, wie man ein bestimmtes mechanisches Problem am KfZ behebt, und du mich dafür kritisierst, dass ich nicht darauf hinweise, um wieviel besser es ist, auch mal mit der Bahn zu fahren oder mit dem Fahrrad. Im Prinzip hättest du zwar Recht, aber darum geht es in diesem Moment nicht.
Passend zum Thema ein Satz aus der CSS2-Spezifikation, auch an der von dir verlinkten Stelle zu finden:
"CSS does not define an "optimal" layout for tables since, in many cases, what is optimal is a matter of taste."
Gruß,
Inzaire-
http://selfhtml.teamone.de/css/eigenschaften/tabellen.htm#table_layout
Das Problem, auf das Du Dich bezogen hattest (zu breite Texte für das existierende Layout), ist auf dieser Seite nicht beschrieben. Ich sehe da nur etwas von dem "Vorteil, dass große Tabellen schneller angezeigt werden können".
Dann lies genauer:
"Netscape 6.x interpretiert diese Eigenschaft wohl, hatte aber Probleme bei der Darstellung. Eine width-Zuweisung an das table-Element brachte ihn dazu, die Anzeige zu verhauen, und das obige Beispiel mit der width-Zuweisung an einzelne Zellen, um damit die Breite der Tabelle festzulegen, ignorierte er."
Das ist a) eine Beschreibung eines Fehlers in Netscape 6.x, b) steht da was von "width-Zuweisung [..], um damit die Breite der Tabelle festzulegen", c) kann auch ein Stefan Münz mal eine etwas unglückliche Formulierung erwischen und d) steht das in keinster Weise entgegen seiner Beschreibung des Vorteils von table-layout:fixed, die ich oben zitiert habe und die jetzt von W3C-Seite nochmal folgt:
Von Abschneiden ist [in der Microsoft-Anleitung zu table-layout] nirgendwo die Rede. Und auch das W3C sagt eher etwas zur Aufbaugeschwindigkeit als zum Zementieren des Tabellenlayouts:
"User agents may use any algorithm they wish to do so, and are free
to prefer rendering speed over precision, except when the 'fixed
layout algorithm' is selected."
http://www.w3.org/TR/REC-CSS2/tables.html#width-layoutWas bedeutet: Wenn "fixed layout algorythm", also table-layout:fixed angegeben ist, muss der user agent diese Angabe respektieren. (entscheidend ist das Wort "except".) Q.e.d.
Was hast Du damit bewiesen? Habe ich irgendwo behauptet, die Angabe table-layout:fixed sei eine Du-kannst-wenn-du-möchtest-aber-du-musst-nicht-Angabe? Natürlich soll der Browser diese Angabe respektieren.
Thx übrigens für den link - genau unterhalb des von dir Angegebenen steht _explizit_ das, was ich beschreibe! :) Zitat:
"Fixed table layout
With this (fast) algorithm, the horizontal layout of the table does not depend on the contents of the cells; it only depends on the table's width, the width of the columns, and borders or cell spacing."Das ist ja schön für Dich, ich habe nur leider nie Deine Beschreibung des _Ergebnisses_ von table-layout:fixed angezweifelt. Und putzigerweise steht dafür in Deinem Zitat wiederum die kleine Bezeichnung "(fast) algorithm", das auf die eigentliche Bedeutung von table-layout:fixed hinweist - "fast".
Es geht mir nicht darum, was table-layout:fixed veranstaltet, es geht mir darum, daß table-layout:fixed nicht, wie von Dir behauptet, dazu erfunden wurde, die Maße einer Tabelle zu zementieren (s.u.), sondern um die Anzeige einer Tabelle zu beschleunigen.
Die eigentliche Frage, über die man sich hier doch wohl eher Gedanken machen sollte, ist, ob das Layout allen Ernstes dermaßen den Inhalt bestimmen darf bzw. -wie von Dir sogar vorgeschlagen- tottrampeln soll.
Nicht zwangsläufig von mir, aber vom W3C. "table-layout:fixed" und "overflow:hidden" gibt es nunmal, und sie sind genau dafür entwickelt worden, ob es dir gefällt oder nicht :p
Nochmal: table-layout:fixed ist nicht dazu erdacht worden, Leuten, die ihre Tabellen wegen mangelhaftem Layout nicht unter Kontrolle kriegen, unter die Arme zu greifen und dient insbesondere nicht explizit dazu, Tabelleninhalte wie Texte abzuschneiden (das Abschneiden ist eine Folge, nicht der Grund für die Existenz). Es ist eine Hilfe für den Browser, die Tabelle schneller anzuzeigen.
Microsoft hat(te) auf seinen Seiten dazu extra ein Beispiel angelegt, in dem eine riesige Tabelle einmal mit und einmal ohne fixed dargestellt wurde - damit man den Geschwindigkeitsunterschied sieht.
Du könntest genauso behaupten, daß man <h1> dazu einsetzen kann, schönen, großen Text zu erzeugen. Damit hast sicher Recht, aber ist diese Behauptung auch richtig in Bezug auf den angedachten Nutzen von <h1>? Ich denke nicht. Und sollte man eine Möglichkeit nicht besser für Ihren eigentlichen Nutzen einsetzen? Gerade wenn es darum geht, daß möglicherweise auf Grund des Einsatzes abseits des angedachten Zwecks Teile verschwinden? Ich denke schon.
Bei overflow hast Du davon abgesehen wie bereits gesagt meinetwegen Recht. Aber auch hier sollte man sich zu allererst die Frage stellen, ob der Einsatz sinnvoll ist und man nicht lieber am Layout arbeitet.
[...]ein pauschaler Hinweis auf overflow geht doch eher nach hinten los, wenn es noch am -sagen wir mal- grundlegenden Problembewusstsein fehlt.
Es war nicht die Intention meines kurzen Artikels dieses Problembewusstsein zu schärfen - das kann man in konkreten Fall ja tun, wenn es angezeigt ist, und du kannst mir glauben, ich tue das auch. Mein Posting befasst sich aber nur mit einer technischen Lösung.
Das wäre wie wenn ich in einem Autoschrauber-Forum beschreibe, wie man ein bestimmtes mechanisches Problem am KfZ behebt, und du mich dafür kritisierst, dass ich nicht darauf hinweise, um wieviel besser es ist, auch mal mit der Bahn zu fahren oder mit dem Fahrrad.
Dem Problem, das ich sehe, etwas angemessener wäre der Vergleich, daß ich Dich darauf hingewiesen habe, daß man mit einem Auto, bei dem ein gerissener Gurt mit Omas Nähgarn genäht wurde, besser nicht mehr fahren sollte und stattdessen das Fahrrad nimmt. Omas Nähgarn ist nämlich für Socken und Bettwäsche gedacht, hält zwar sicher den Zug des Gurtspanners aus, aber im Falle eines Falles ganz bestimmt nicht einen außer Kontrolle geratenen Körper mit 100 kg Lebendgewicht, was dann in der Regel in einer unschönen Beule in Lenkrad, Windschutzscheibe oder Motorhaube (wahlweise die eigene oder die des Unfallgegners) endet.
Anderes, bösartiges Beispiel: Ich kann meinen Kunden auch erzählen, daß sie -rein technisch natürlich- Klingeldraht benutzen können, um auf ihrem feuchten Dachboden eine 230V-Steckdose für den Heizstrahler anzuschließen. Und das funktioniert in den meisten Fällen auch ganz prima.
Aber ist Klingeldraht tatsächlich dafür gedacht? Wenn nein, hat man sich vielleicht auch überlegt, warum er nicht dafür gedacht ist? Sicherlich.
Somit stellt sich die entscheidende Frage zu meinem rein technischen Tipp: Ist es sinnvoll, so einen Tipp "ohne [ihn] an sich bewerten zu wollen" in die Landschaft zu setzen? Kommentarlos sozusagen?Irgendwer hat mal geschrieben, das Besondere an diesem Forum sei, daß es keine Codeliefermaschine ist, sondern daß hier auch Sinn und Zweck hinterfragt wird. Und genau darauf läuft es hinaus.
Wie dem auch sei, mit der Diskussion haben wir ja vielleicht doch noch ein paar Leute auf die Sinnlosigkeit (meines Erachtens nach) solcher Schnippel- und Zementieraktionen hingewiesen - und den Rest kann man eh nicht von seinem teuflischen Tun abhalten.
Dem Ansinnen wurde genüge getan, Tee drüber, kann ich noch ein Eis haben?Gruß,
soenk.e-
http://selfhtml.teamone.de/css/eigenschaften/tabellen.htm#table_layout
Das Problem, auf das Du Dich bezogen hattest (zu breite Texte für das existierende Layout), ist auf dieser Seite nicht beschrieben. Ich sehe da nur etwas von dem "Vorteil, dass große Tabellen schneller angezeigt werden können".
Dann lies genauer:
"Netscape 6.x interpretiert diese Eigenschaft wohl, hatte aber Probleme bei der Darstellung. Eine width-Zuweisung an das table-Element brachte ihn dazu, die Anzeige zu verhauen, und das obige Beispiel mit der width-Zuweisung an einzelne Zellen, um damit die Breite der Tabelle festzulegen, ignorierte er."
Das ist a) eine Beschreibung eines Fehlers in Netscape 6.x,
Präzise das ist es, wie ich in meinem ursprünglichen posting, in meiner Antwort, und auch jetzt wieder sage.
b) steht da was von "width-Zuweisung [..], um damit die Breite der Tabelle festzulegen",
Da steht: "Breitenangaben zur Tabelle und zu Tabellenspalten".
c) kann auch ein Stefan Münz mal eine etwas unglückliche Formulierung erwischen
...und das W3C...
»» Es geht mir nicht darum, was table-layout:fixed veranstaltet, es geht mir darum, daß table-layout:fixed nicht, wie von Dir behauptet, dazu erfunden wurde, die Maße einer Tabelle zu zementieren (s.u.), sondern um die Anzeige einer Tabelle zu beschleunigen.
Das ist kein Widerspruch, sondern es sind zwei Seiten derselben Medallie. Und wenn du magst, dann kannst du die von mir beschriebene Lösung ja so sehen, dass damit auch Mozilla schneller aufbauen kann.
Gruß Inzaire
-
-
-
-
-
Hallo Sönke,
Welch' Katastroph'! Oder anders ausgedrückt: Wer keine Probleme hat, macht sich welche.
Das bist du, wie wir dich kennen und lieben.
Unqualifizierte und beleidigenede Äußerungen.Der Poster hat sich viel Mühe gegeben, ein Problem, das hier schon öfters gefragt wurde zu Lösen und weist auch auf die Schachstellen in der Lösung hin.
Wenn die die Lösung nicht gefällt und so dagegen aufbegehrst, solltest du eine bessere vorschlagen. Du bist nie müde gewesen zu betonen wie gut du doch bist, also es dürfte dir keine Schwierigkeiten bereiten eine entsprechende Lösung auszuarbeiten.
Im Übrigen wäre es wirklich an der Zeit, dass du dein Verhalten hier im Forum gegenüber Anderen etwas anderes steuerst.
Grüße
Thomas
-
-
Hi Inzaire,
Angeregt durch ein heutiges Posting
(http://forum.de.selfhtml.org/?m=116194&t=20759)
habe ich versucht, das Problem der festen Breitenangaben von
Tabellen und Tabellenzellen etwas genauer zu beleuchten.ich halte Deinen Ansatz für hilfreich, wenngleich ich auch manches aus
der Argumentation von Sönke unterstützen könnte.Was hältst Du davon, den Rahmen Deiner Ausführungen ein bißchen weiter
zu ziehen (d. h. insbesondere die Aufgabenstellung etwas mehr zu
hinterfragen) und Dich nicht nur auf die rein technischen Aspekte zu
beschränken? (Sönke hat nicht unbedingt den glücklichsten Tonfall ge-
troffen, aber an seiner Argumentation ist im Detail durchaus etwas dran.)In diesem Falle wäre Deine Zusammenfassung eventuell ein schöner
Ausgangspunkt für einen netten kleinen Feature-Artikel (mit Links auf
die jeweiligen Original-W3C-Seiten etc.)Viele Grüße
Michael-
Hi Michael,
Eigentlich keine schlechte Idee mit dem Feature-Artikel... das Thema wäre es wert! Wenn die Zeit reicht, werde ich mich damit mal befassen.
Grüße,
Inzaire
-