HTML vs XHTML
- Ersteller Mark
- Erstellt am
W
Wustersoss
Guest
@NetAktiv
Ich habe das selbst ausprobiert nur mit HTML5 Doctype und ohne XML... am Anfang. Selbiges Verhalten. Es lag definitiv nicht am Doctype, sondern an den unterschiedlichen Browservoreinstellungen im CSS.
Ich habe das selbst ausprobiert nur mit HTML5 Doctype und ohne XML... am Anfang. Selbiges Verhalten. Es lag definitiv nicht am Doctype, sondern an den unterschiedlichen Browservoreinstellungen im CSS.
Es tut mir schon leid, aber das passt immer noch nicht.
Du hast die Höhe von 50 auf 20 verkleinert, wobei Schrift plus margin auch 20 ergibt, dadurch macht jetzt auch FF die Zelle 20px plus Rahmen hoch, aber nicht, weil die Einstellungen passen, sondern weil der Inhalt höher ist als die height Angabe.
Nehme ich height:50px habe ich immer noch im IE 50px plus Rahmen und im FF 50px inkl. Rahmen.
Jetzt mal eine ganz dumme Frage:
Nachdem der IE es ohne DOCTYPE genauso anzeigt, wie FF mit DOCTYPE, ich den DOCTYPE aber auf jeden Fall brauche, kann man nicht herausfinden, was genau der IE im Quirks-Modus am Boxmodell ändert, und diese (vermutlich nur eine) Einstellung nachträglich dem Standards-Modus via CSS hinzufügen?
Du hast die Höhe von 50 auf 20 verkleinert, wobei Schrift plus margin auch 20 ergibt, dadurch macht jetzt auch FF die Zelle 20px plus Rahmen hoch, aber nicht, weil die Einstellungen passen, sondern weil der Inhalt höher ist als die height Angabe.
Nehme ich height:50px habe ich immer noch im IE 50px plus Rahmen und im FF 50px inkl. Rahmen.
Jetzt mal eine ganz dumme Frage:
Nachdem der IE es ohne DOCTYPE genauso anzeigt, wie FF mit DOCTYPE, ich den DOCTYPE aber auf jeden Fall brauche, kann man nicht herausfinden, was genau der IE im Quirks-Modus am Boxmodell ändert, und diese (vermutlich nur eine) Einstellung nachträglich dem Standards-Modus via CSS hinzufügen?
W
Wustersoss
Guest
Testumgebung:
Wir haben eine HTML-Tabelle mit 25 Reihen(TR) zu 25 Zellen(TD). Um gleiche Ausgangsbedingungen zu schaffen, wird das CSS-Reset-Script von Eric Meyer - Wikipedia, the free encyclopedia eingesetzt.
Die Tabelle bekommt die CSS-Angaben border-collapse:separate; border-spacing: 2px; border:2px solid black;
Somit haben die Tabellenfelder Abstände zueinander von 2Pixel und die Tabelle hat einen schwarzen Rahmen. die Tabelle passt sich der Grösse an.
Tabellenreihen bleiben ohne CSS.
Tabellenzellen erhalten eine Höhe von 50 Pixel und einen roten Rahmen von 1 Pixel.
Testumgebung ist Windows XP mit SP3 und die Kandidaten sind FF 8, Opera 11, Chrome, IE 8 sowie IE 7, in dieser Reihenfolge.
So sieht es aus:
Wenn man nach unten schaut sieht man wunderbar die Problematik. FF und Opera verhalten sich identisch und fügen den Zellen keine Pixel hinzu, das heisst die Zelle bleibt 50 Pixel hoch inklusive Rahmen.
Chrome, übrigens auch Safari, IE8 und der kleine Bruder IE7 fügen den Tabellen 2 Pixel hinzu(vom Rahmen) und vergrössern somit die Höhe auf 52 Pixel. Die Schrift von unserem "g" bleibt überall gleich.
Wer sich an Zeiten an von IE5.5 und IE6 zurück erinnert, dem fällt sofort ein, das es da mal einen 3 PixelBug und auch unterschiedliche Boxmodelle gab.
Wir schauen also was wir heute mit CSS machen können und finden bei CSS3 die Eigenschaft Box-Sizing. Mit Box-Sizing kann man das Boxmodell einstellen. Also wie sich ein Blockelement verhalten soll wenn es einen Rahmen erhält. Bis auf IE7 beherrschen alle Browser diese Eigenschaft.
Ein Blick noch beim CSS3 Basic User Interface Module
Das W3C sagt dazu:"Applies to: all elements that accept width or height "
Na prima, also verpassen wir alle Browser das verhalten des IE7, weil der ja das nicht kann und somit die Vorgabe stellt.
Browser-sizing:content-box und einmal auch mit browser-sizing:border-box sowie auch mit Browser-Präfixes getestet.
Das Ergebnis überrascht und enttäuscht. Nur der viel geschmähte IE8 wechselt sein verhalten. Wir können also beim IE8 angeben, ob er sich so verhalten soll wie der IE7 und Chrome und Safari oder wie FF und Opera.
Was also bei DIVs klappt funktioniert hier nicht.
Puh, das stellt uns jetzt vor ein Problem.
Wie gesagt, wir haben hier alle CSS-Angaben auf gleiches Niveau gebracht und alle Margins sowie Paddings haben Null-Wert.
Irgendwie scheint keiner das Problem bis jetzt gehabt zu haben. In Zeiten wo auf Tabellendesign verzichtet wird, fällt es halt nicht sofort auf, wann braucht der normale User schon eine Tabelle.
Übrigens - lässt man den Rahmen in den Tabellenzellen weg, sieht es überall gleich aus.
Die Lösung:
Wir lassen die Tabellenrahmen in den Zellen weg, schreiben in jede Zelle noch ein Div und geben dem Div den Rahmen.
Und siehe da. Es klappt.
Das hat mich jetzt echt Nerven gekostet, aber hier ist das Ergebnis als verkürzte Tabelle:
Das Ergebnis kann sich sehen lassen.
Ein gleiches Aussehen in allen Browsern.
Wir haben eine HTML-Tabelle mit 25 Reihen(TR) zu 25 Zellen(TD). Um gleiche Ausgangsbedingungen zu schaffen, wird das CSS-Reset-Script von Eric Meyer - Wikipedia, the free encyclopedia eingesetzt.
Die Tabelle bekommt die CSS-Angaben border-collapse:separate; border-spacing: 2px; border:2px solid black;
Somit haben die Tabellenfelder Abstände zueinander von 2Pixel und die Tabelle hat einen schwarzen Rahmen. die Tabelle passt sich der Grösse an.
Tabellenreihen bleiben ohne CSS.
Tabellenzellen erhalten eine Höhe von 50 Pixel und einen roten Rahmen von 1 Pixel.
Testumgebung ist Windows XP mit SP3 und die Kandidaten sind FF 8, Opera 11, Chrome, IE 8 sowie IE 7, in dieser Reihenfolge.
So sieht es aus:
Wenn man nach unten schaut sieht man wunderbar die Problematik. FF und Opera verhalten sich identisch und fügen den Zellen keine Pixel hinzu, das heisst die Zelle bleibt 50 Pixel hoch inklusive Rahmen.
Chrome, übrigens auch Safari, IE8 und der kleine Bruder IE7 fügen den Tabellen 2 Pixel hinzu(vom Rahmen) und vergrössern somit die Höhe auf 52 Pixel. Die Schrift von unserem "g" bleibt überall gleich.
Wer sich an Zeiten an von IE5.5 und IE6 zurück erinnert, dem fällt sofort ein, das es da mal einen 3 PixelBug und auch unterschiedliche Boxmodelle gab.
Wir schauen also was wir heute mit CSS machen können und finden bei CSS3 die Eigenschaft Box-Sizing. Mit Box-Sizing kann man das Boxmodell einstellen. Also wie sich ein Blockelement verhalten soll wenn es einen Rahmen erhält. Bis auf IE7 beherrschen alle Browser diese Eigenschaft.
Ein Blick noch beim CSS3 Basic User Interface Module
Das W3C sagt dazu:"Applies to: all elements that accept width or height "
Na prima, also verpassen wir alle Browser das verhalten des IE7, weil der ja das nicht kann und somit die Vorgabe stellt.
Browser-sizing:content-box und einmal auch mit browser-sizing:border-box sowie auch mit Browser-Präfixes getestet.
Das Ergebnis überrascht und enttäuscht. Nur der viel geschmähte IE8 wechselt sein verhalten. Wir können also beim IE8 angeben, ob er sich so verhalten soll wie der IE7 und Chrome und Safari oder wie FF und Opera.
Was also bei DIVs klappt funktioniert hier nicht.
Puh, das stellt uns jetzt vor ein Problem.
Wie gesagt, wir haben hier alle CSS-Angaben auf gleiches Niveau gebracht und alle Margins sowie Paddings haben Null-Wert.
Irgendwie scheint keiner das Problem bis jetzt gehabt zu haben. In Zeiten wo auf Tabellendesign verzichtet wird, fällt es halt nicht sofort auf, wann braucht der normale User schon eine Tabelle.
Übrigens - lässt man den Rahmen in den Tabellenzellen weg, sieht es überall gleich aus.
Die Lösung:
Wir lassen die Tabellenrahmen in den Zellen weg, schreiben in jede Zelle noch ein Div und geben dem Div den Rahmen.
Und siehe da. Es klappt.
Das hat mich jetzt echt Nerven gekostet, aber hier ist das Ergebnis als verkürzte Tabelle:
HTML:
<!DOCTYPE html>
<html>
<head>
<title>Irgendwas
</title>
<style>
* {padding:0;margin:0;}
table, caption, tbody, tfoot, thead, tr, th, td,
{
margin: 0;
padding: 0;
border: 0;
font-size: 100%;
font: inherit;
vertical-align: baseline;
}
body: {line-height:1;}
table {border-collapse:separate; border-spacing: 2px; border:2px solid black;}
tr{}
td{}
td div{height:50px;border:1px solid red;}
</style>
</head>
<body>
<table>
<tr>
<td><div> g</div></td><td><div> g</div></td><td><div> g</div></td><td><div> g</div></td>
</tr>
<tr>
<td><div> g</div></td><td><div> g</div></td><td><div> g</div></td><td><div> g</div></td>
</tr>
<tr>
<td><div> g</div></td><td><div> g</div></td><td><div> g</div></td><td><div> g</div></td>
</tr>
<tr>
<td><div> g</div></td><td><div> g</div></td><td><div> g</div></td><td><div> g</div></td>
</tr>
</table>
</body>
</html>
</body>
</html>Das Ergebnis kann sich sehen lassen.
Ein gleiches Aussehen in allen Browsern.
Nachtrag:
Das selbe Ergebnis lässt sich auch erzielen, wenn man den Tabellenzellen keine height gibt, sondern in die Zelle ein <div> mit der gewünschten Innenhöhe der Zelle macht.
Jetzt machen alle Browser padding, margin und Rahmen zur Höhe des <div> dazu und das Ergebnis ist immer 50px inkl. Rahmen.
Um ganz sicher zu gehen, dass die Browser dafür keine verschiedenen defaults haben, kann man die Werte für padding und margin auch selber angeben.
Das selbe Ergebnis lässt sich auch erzielen, wenn man den Tabellenzellen keine height gibt, sondern in die Zelle ein <div> mit der gewünschten Innenhöhe der Zelle macht.
Code:
<!DOCTYPE html>
<html>
<head>
<title>Irgendwas
</title>
</head>
<body>
<table border="1">
<tr>
<td>
<div style="height:44px">
<div>
</td>
</tr>
</table>
</body>
</html>Jetzt machen alle Browser padding, margin und Rahmen zur Höhe des <div> dazu und das Ergebnis ist immer 50px inkl. Rahmen.
Um ganz sicher zu gehen, dass die Browser dafür keine verschiedenen defaults haben, kann man die Werte für padding und margin auch selber angeben.
W
Wustersoss
Guest
Wo du die Formatangaben hinschreibst, also ob du sie als Style-Atribut definierst, wie du es gemacht hast oder in den Header schreibst, als Style-Tag, wie ich es gemacht habe oder ob du sie in eine CSS-Datei auslagerst, spielt keine Rolle. Einzig die Priorität macht sich bemerkbar. Formatangaben werden in umgekehrter Reihenfolge überschrieben.
Siehe dazu auch Doku:CSS/Grundlagen von CSS/Stylesheets in Dokumente einbinden
