IE zu Firefox... ein paar Fragen

[Hans Dampf]

Hallo,
also bisher hab ich immer nur auf den IE geachtet, Firefox und Co. waren mir eigentlich immer egal.

Aber da es ja nun mal so ist, das Firefox immer mehr genutzt wird und die Leute ja der Meinung sind, man müsste die Browser nicht kompatibel machen, hab ich hier erstmal nur 2 Fragen.

1. Beim ersten Versuch eine Seite in der CSS-Formatierungen vorkommen mit Firefox zu öffnen, musste ich feststellen, das diese teilweise nicht übernommen wurden. Es hat mich "Stunden" an Arbeit gekostet herauszufinden wo der Fehler liegt, denn die Befehle als solches waren alle korrekt und sollten auch von beiden Browsern unterstützt werden.
Der Fehler war Schlussendlich die REIHENFOLGE von den CSS-Befehlen, die dem IE egal waren, Firefox hingegen nicht.
In dem Fall handelt es sich um Link-Formatierung, also hover, active...etc.

Hier mal die Seite wo das Grundgerüst her ist:

http://www.cssplay.co.uk/menus/cross.html#nogo1

Dort hab ich die Formatierung nur die Reihenfolge geändert, was ich für mich übersichtlicher fand... nur halt Firefox nicht mochte.

Nun aber zur Frage, da dies auch hier auf SELF-HTML nicht dabei steht, gibt es noch mehr "Stolpersteine", wo dies eine Rolle spielt ?

Damit auch gleich zur 2.Frage, noch so ein Stolperstein:

2. Unter anderen hab ich per CSS auch was relativ simples gemcht, wieder eine Linkformatierung, nur fast ohne Spielereien... klappt auch soweit, nur leider gibt es auch da ein Haken, den BORDER.

Wenn ich beim IE ein Feld formatierte mit WIDTH:100px, HEIGHT:100px und einem BORDER:5px... bleibt das Gesamtfeld beim IE 100x100, beim Firefox wird daraus aber 105x105.

Das Problem ist nun, will man in diesem Feld Text anordnen (LINE-HEIGH), muss man für den IE 95px nehmen und für Firefox 100px, da bei dem einen der Border zum Feld gehört und beim anderen "draufgepackt" wird.

Gibt es da eine Möglichkeit beide unter einem Hut zu bringen ???

Gruß

HD

[Jörg Peschke]

Hallo,

Nun aber zur Frage, da dies auch hier auf SELF-HTML nicht dabei steht, gibt es noch mehr "Stolpersteine", wo dies eine Rolle spielt ?

Generell kannst Du davon ausgehen, dass sich der Firefox eher an den vom W3C-definierten CSS-Standard hält, als der Internet Explorer.

Wenn etwas vom Firefox anders/"falsch" dargestellt wird, ist in den meisten Fällen das CSS fehlerhaft. Der IE rumpelt über "falsche" CSS-Angaben unter Umständen einfach drüber, ohne sich um die Korrektheit zu scheren, deswegen gehen bestimmte Dinge dann doch, die eigentlich nicht gehen dürften.

Am besten, Du entwickelst Dein CSS erst einmal für den Firefox und DANACH optimierst du für den IE nach.
Wenn Du auf der sicheren Seite sein willst, kannst Du mit dem
CSS-Validator vom W3C überprüfen, ob Dein CSS vollständig valide ist.

2. Unter anderen hab ich per CSS auch was relativ simples gemcht, wieder eine Linkformatierung, nur fast ohne Spielereien... klappt auch soweit, nur leider gibt es auch da ein Haken, den BORDER.

Dies ist die meiste Ursache für Kompatibilitätsprobleme zwischen IE und Firefox, das sog. Box Model - auch hier ist aber die Darstellung des Mozillas die eigentlich "richtige" (=standardisierte).

Um beide unter einen Hut zu kriegen, kannst Du CSS-Hacks (VORSICHT: Einige funktionieren ab IE 7 nicht mehr!),
oder  (für den IE) Conditional Comments verwenden.

Hope that helps,

Joerg

[Hopsel]

Hi Hans!

[...] denn die Befehle als solches waren alle korrekt und sollten auch von beiden Browsern unterstützt werden.

Und da bist du dir natürlich 100%ig sicher...

Der Fehler war Schlussendlich die REIHENFOLGE von den CSS-Befehlen, die dem IE egal waren, Firefox hingegen nicht.

Das ist bekannt und durchaus Standard

Dort hab ich die Formatierung nur die Reihenfolge geändert, was ich für mich übersichtlicher fand... nur halt Firefox nicht mochte.

Weil er sich an gewisse Standards hält.

Nun aber zur Frage, da dies auch hier auf SELF-HTML nicht dabei steht, [...]

Doch.

[...] gibt es noch mehr "Stolpersteine", wo dies eine Rolle spielt ?

Der IE legt dir doch die meisten Stolpersteine in den Weg.

MfG H☼psel

[Ingo Turski]

Hi,

Aber da es ja nun mal so ist, das Firefox immer mehr genutzt wird und die Leute ja der Meinung sind, man müsste die Browser nicht kompatibel machen

Nunja, die IE-Entwickler haben sich zumindest bemüht, die Version 7 etwas standard-kompatibler zu machen. ;-)

Dort hab ich die Formatierung nur die Reihenfolge geändert, was ich für mich übersichtlicher fand... nur halt Firefox nicht mochte.

Du solltest die Reihenfolge halt nicht so angeben, wie sie für Dich übersichtlich erscheint, sondern abhängig von den gewünschten Effekten.

Wenn ich beim IE ein Feld formatierte mit WIDTH:100px, HEIGHT:100px und einem BORDER:5px... bleibt das Gesamtfeld beim IE 100x100, beim Firefox wird daraus aber 105x105.

Versetze den IE sowie alle übrigen Browser durch einen vollständigen DOCTYPE in den standard-kompatiblen Modus.

freundliche Grüße
Ingo

[Patrick Andrieu]

Hallo!

Dieser Beitrag ist keine Antwort auf Ingos Nachricht, eher eine - wieder mal - generelle Anmerkung von mir, ihr seid's ja gewohnt ;)

Wenn ich beim IE ein Feld formatierte mit WIDTH:100px, HEIGHT:100px und einem BORDER:5px... bleibt das Gesamtfeld beim IE 100x100, beim Firefox wird daraus aber 105x105.

Sicher, was Firefox hier macht ist der Standard, und so muss man leider rechnen...

...worüber ich mich allerdings auf ewig aufregen könnte! Wer hat sich das ausgedacht? Wissen sie beim W3C nicht, wobei naheliegt zu vermuten, dass es mehrheitlich anglophon besetzt ist, was Wörter der eigenen Sprache bedeuten?

Was ist unter einer Box zu verstehen?

<cite>
Der Ausdruck Box (v. lat. buxis Büchse) bezeichnet

einen kastenförmigen Behälter, siehe Kasten
</cite>

Wenn jemand zu einer Schreinerei geht und eine stabile 200cm*200cm große Kiste (hier brauchen wir noch die Höhe, sagen wir mal auch 200cm) bestellt, wozu der Schreiner 4cm dickes Holz braucht, was würde dieser jemand sagen, wenn er eine Kiste von 208*208*208cm bekommt?

Er würde die "Box" nicht abnehmen, weil er 200*200*200cm bestellt hat, weil vielleicht die Ladefläche seines Kastenwagens nur 204cm breit ist, eine größere Kiste würde nicht reinpassen.

Aber der Schreiner würde das nicht machen, weil er annimmt, dass der Kunde sehr wohl weiß, wie breit/hoch/tief der Inhalt ist, den er in die Box einpacken will. Wenn er ein guter Schreiner ist, fragt er womöglich nach.

In einem Dokument ist eine Box natürlich zweidimensional und im übertragenen Sinne zu verstehen, jedoch sollte das Prinzip stimmen: Boxmaßen = Außenmaßen.

Aber nein, das W3C versteht es anders. Obwohl es mich eigentlich nicht wundert, dass bei Standards, die aus einem Land kommen, das noch mit Gallonen, Yards und Feet und Miles rechnet, so eine verkorkste Berechnungsgrundlage heraus kommt.

Ist genauso, als wenn man beim Hausbau erst denn Innenausbau vor den Außenwänden anfängt!

Viele Grüße aus Frankfurt/Main,
Patrick

[Ingo Turski]

Hi,

In einem Dokument ist eine Box natürlich zweidimensional und im übertragenen Sinne zu verstehen, jedoch sollte das Prinzip stimmen: Boxmaßen = Außenmaßen.

warum? Es ist schlicht Definitionssache, ob man ohne nähere Angaben die Innen- oder Außenmaße meint. Und im Webdesign können auch Innenmaße sinnvoll sein, wenn ich nämlich Platz für ein Bild mit 200px in einer Box benötige, warum sollte ich dann noch extra border und padding hinzurechnen müssen?
Natürlich können im anderen Fall auch die Außenmaße relevant sein, aber hier kommt dem Autor oft entgegen, dass Block-Elemente automatisch den gesamten zur Verfügung stehenden Platz einnehmen können.

freundliche Grüße
Ingo

[Patrick Andrieu]

Hallo Ingo!

warum? Es ist schlicht Definitionssache, ob man ohne nähere Angaben die Innen- oder Außenmaße meint. Und im Webdesign können auch Innenmaße sinnvoll sein, wenn ich nämlich Platz für ein Bild mit 200px in einer Box benötige, warum sollte ich dann noch extra border und padding hinzurechnen müssen?

Ja, aber das ist eben das, was für mich verkorkst rechnen nenne! Der Schreiner-Kunde in meinem Beispiel, er kennt seinen Inhalt (content, nicht Box) und will eine Box in welcher eben dieser Inhalt reinpaßt, und die auch noch in seinen Wagen passt. Er addiert schon sein Padding (Sicherheitsabstand wg. evtl. Stöße o.Ä.) und denkt sicher auch, dass der Schreiner mindestens 3 oder 4cm dickes Holz nehmen wird.

Hier im Webdesign definiert man eine Box, die man 200px breit haben will, stellt dann fest, dass Holzdicke (Border) und Sicherheitsabstand zum Inhalt (Padding) dazu addiert werden und die Box größer machen. Das ist für mich verkorkst, oder der Name _BOX_ ist in der ganzen Sache falsch gewählt und sollte anders benannt werden ;)

Viele Grüße aus Frankfurt/Main,
Patrick

[Ingo Turski]

Hi,

Der Schreiner-Kunde in meinem Beispiel, er kennt seinen Inhalt (content, nicht Box) und will eine Box in welcher eben dieser Inhalt reinpaßt

und genau das kann auch zu dem Auftrag führen, eine Box mit genau definierten Dimensionen zu erstellen, z.B. eine Box für CDs, in die diese _exakt_ passen sollen. Dann wird der Schreiner die verwendete Holzstärke auch nach dem W3C-Modell hinzurechnen...

freundliche Grüße
Ingo

[Bud]

Hi.

In einem Dokument ist eine Box natürlich zweidimensional und im übertragenen Sinne zu verstehen, jedoch sollte das Prinzip stimmen: Boxmaßen = Außenmaßen.
warum? Es ist schlicht Definitionssache

Einerseit ja. Andereseits kann eine komplette Seitenkonstruktion zusammenbrechen, nur weil in irgend einer Ecke ein Margin oder Padding verändert wurde. Das ist unlogisch. Hier hat man die _Außenwirkung_ einer Box nicht beachtet. Ich weiß ja nicht, wer genau sich diesen Unsinn ausgedacht hat, ein praktisch veranlagter Mensch war es wohl kaum. ;-)

Oder gehst du etwa in ein Küchengeschäft mit einer Liste unterm Arm, auf der du die Maße deines Geschirrs notiert hast? Oder nicht doch eher mit einem Aufriss der Raumes, in dem die Küche eingebaut werden soll?

vg Bud

[Timo "God's Boss" Reitz]

Einerseit ja. Andereseits kann eine komplette Seitenkonstruktion zusammenbrechen, nur weil in irgend einer Ecke ein Margin oder Padding verändert wurde. Das ist unlogisch. Hier hat man die _Außenwirkung_ einer Box nicht beachtet. Ich weiß ja nicht, wer genau sich diesen Unsinn ausgedacht hat, ein praktisch veranlagter Mensch war es wohl kaum. ;-)

Kommt darauf an, was du unter "zusammenbrechen" verstehst. Ich weiß nämlich zur Zeit gar nicht, was du eigentlich meinst.

Oder gehst du etwa in ein Küchengeschäft mit einer Liste unterm Arm, auf der du die Maße deines Geschirrs notiert hast? Oder nicht doch eher mit einem Aufriss der Raumes, in dem die Küche eingebaut werden soll?

Ein schlechter Vergleich. Meine Küche ist immer gleich groß, aber der Platz, in dem eine Webseite angezeigt werden soll, kann erheblich schwanken, sowohl in der Breite als auch in der Höhe, wobei Letzteres weniger bedeutsam ist. Dementsprechend müssen die Elemente einen Weg finden, wie sie allesamt Platz haben und die komplexen Regeln, die dafür aufgestellt werden, lassen eben auch ein (wie du es nennst) "zusammenbrechen" zu.

[Bud]

Hi.

Kommt darauf an, was du unter "zusammenbrechen" verstehst. Ich weiß nämlich zur Zeit gar nicht, was du eigentlich meinst.

Angenommen du hast drei Spalten (float left) unterschiedlicher Farbe auf einer Seite, (33%, 34%, 33%). Alle mit Text gefüllt. Jetzt kommst du auf den Gedanken, der mittleren Spalte einen winzig kleinen Rahmen von einem Pixel zu geben. Oder ein Padding. Und, was passiert? Richtig, der rechte Block rutscht sofort eine Etage tiefer.

Ich kann zu Beginn eines Entwurfes zwar schon wissen, dass ich drei Spalten haben will, aber nicht unbedingt die genaue Größe von inneren oder äußeren Abständen. Die muss ich bei diesem Boxmodel aber wissen. Ich bin gezwungen, gleichzeitig an mehreren Größenangaben zu schrauben. Um bei meinem Beispiel zu bleiben, um wieviel Prozent verringert sich die Breite der mittleren Spalte, wenn du ein Padding von einem em möchtest? Merkst du was?

Jede klassische Entwurfstechnik geht von den großen zu den kleinen Formen. Das ist bei diesem Boxmodell nicht bzw. nur mit Verrenkungen möglich. Ich müsste von den kleinen zu den Großen Formen arbeiten - welch ein gestalterischer Unsinn.

vg Bud

[Detlef G.]

Hallo Bud

Angenommen du hast drei Spalten (float left) unterschiedlicher Farbe auf einer Seite, (33%, 34%, 33%). Alle mit Text gefüllt. Jetzt kommst du auf den Gedanken, der mittleren Spalte einen winzig kleinen Rahmen von einem Pixel zu geben. Oder ein Padding. Und, was passiert? Richtig, der rechte Block rutscht sofort eine Etage tiefer.

Das kann dir aufgrund von Rundungsdifferenzen auch ganz ohne Rahmen oder Padding passieren. Dann gibt es den tolllen Effekt, dass die Spalte je nach Fenstergröße lustig runter- und wieder hochhopst.
Wichtig ist, immer etwas Luft zu lassen oder/und einer der Spalten keine Breite zuzuweisen, damit sie den Rest einnimmt.
Empfehlenswert ist auch, Padding nicht den Spalten selbst sondern den darin enthaltenen Absätzen zu geben.

Jede klassische Entwurfstechnik geht von den großen zu den kleinen Formen.

Sie gehen auch von einem definierten Format aus. Beim Webdesign ist die Größe des Browserfensters nicht bekannt.

Auf Wiederlesen
Detlef

[Timo "God's Boss" Reitz]

In einem Dokument ist eine Box natürlich zweidimensional und im übertragenen Sinne zu verstehen, jedoch sollte das Prinzip stimmen: Boxmaßen = Außenmaßen.
Aber nein, das W3C versteht es anders. Obwohl es mich eigentlich nicht wundert, dass bei Standards, die aus einem Land kommen, das noch mit Gallonen, Yards und Feet und Miles rechnet, so eine verkorkste Berechnungsgrundlage heraus kommt.

Nein, das W3C versteht es *exakt* so: Die Maße der Box sind content+padding+border+margin. Ich denke, *du* verstehst etwas nicht und zwar Folgendes: width und height legen *nicht* die Boxgröße fest, sondern lediglich die Größe des Bereichs, der für den Inhalt reserviert sein soll.
Es ist ja auch viel logischer: Es gibt Eigenschaften, die die Größe von margin, border und padding festlegen und solche, die die Größe des Inhalts festlegen.
Du möchtest hingegen: Es gibt Eigenschaften, die die Größe von margin, border und padding festlegen und solche, die die Größe von Inhalt und padding festlegen, Letzteres gebündelt.
Welches ist wohl die einfachere Variante?