Internet Explorer lädt margin Attribut verzögert

[Rafael]

Ich bin auf ein sehr seltsames Problem mit dem IE gestoßen. Ich bastle gerade an einer Webseite, die einen Newsletter anbietet. Dazu habe ich eine Leiste mit zwei Feldern, einer für den Namen und einen für die Email. Wenn jetzt jemand auf eines der Felder klickt soll sich die Ramendicke von 1 auf 2 erhöhen, was auch passiert.

um aber den text an der gleichen stelle zu lassen, soll sich der Rand um den einen Pixel verringern und das klappt im Prinzip auch (mit Firefox, Netscape und Opera).

Nur wird die Ramenänderung mit dem IE erst aktiv, wenn ich mit der Maus über den Button fahre. Das Problem tritt nur mit dem IE auf und ich bin, sagen wir, verwirrt.

Das CSS sieht für die Eingabefelder so aus:

#rahmen {
border-width: 1px;
border-style: dashed;
border-color: #FF0066;
font-family: Verdana, Helvetica, sans-serif;
margin-right: 2px;
margin-bottom: 2px;
margin-top: 2px;
padding-bottom: 3px;
}

#rahmenmo {
border-width: 2px;
border-style: dashed;
border-color: #40BE89;
font-family: Verdana, Helvetica, sans-serif;
margin-right: 0px;
margin-left: 0px;
margin-bottom: 1px;
margin-top: 1px;
padding-bottom: 0px;
}

Zu betrachten gibt es das Problem auf:

http://www.buela.de/demo/

und eine gefixte aber leider nur semioptimale Version auf:

http://www.buela.de/kulturini/

[Gernot Back]

Hallo Rafael,

Nur wird die Ramenänderung mit dem IE erst aktiv, wenn ich mit der Maus über den Button fahre. Das Problem tritt nur mit dem IE auf und ich bin, sagen wir, verwirrt.

http://www.buela.de/demo/

Ich kann dein Problem nicht nachvollziehen, in meinem IE6 bedarf es unter WindowsXP nicht erst eines Überfahrens des Buttons mit der Maus, damit die Änderung der Rahmendicke der Eingabefelder sichtbar wird; sie wird es sofort, wie auch im Firefox.

Gruß Gernot

[wahsaga]

hi,

Ich kann dein Problem nicht nachvollziehen, in meinem IE6 bedarf es unter WindowsXP nicht erst eines Überfahrens des Buttons mit der Maus, damit die Änderung der Rahmendicke der Eingabefelder sichtbar wird; sie wird es sofort, wie auch im Firefox.

Der Rahmen "funzt" ja auch.
Aber erst wenn du den Button überfährst, "hüpft" das geänderte Inputfeld um einen Pixel nach oben, weil die geänderte margin-Angabe erst dann umgesetzt wird.

gruß,
wahsaga

[Rafael]

Das hab ich soweit auch realisiert. Ich wollte aber wissen, wie ich das unterbinden kann. Ich lade eigentlich per onClick bzw. onBlur per JS die ID ein also z.B. onClick="this.id='buttonmo';"

Wieso wird die Änderung des Rahmens vom IE erst später "nachgereicht" buw. wie schalte ich das ab?

[wahsaga]

hi,

Das hab ich soweit auch realisiert. Ich wollte aber wissen, wie ich das unterbinden kann. Ich lade eigentlich per onClick bzw. onBlur per JS die ID ein also z.B. onClick="this.id='buttonmo';"

Dass ich das für ziemlich unsinnig halte, und was ich alternativ vorschlagen würde, schrieb ich dir bereits.

gruß,
wahsaga

[wahsaga]

hi,

Nur wird die Ramenänderung mit dem IE erst aktiv, wenn ich mit der Maus über den Button fahre. Das Problem tritt nur mit dem IE auf und ich bin, sagen wir, verwirrt.

Du verwendest id="rahmen" für beide Input-Felder - was natürlich nicht erlaubt ist, eine ID soll ein Element _eindeutig_ identifizieren. (Validiere bitte deine Dokumente, damit du solche Fehler selber findest.)

Und deshalb würde ich dir auch empfehlen, bei onfocus/onblur nicht die ID des betroffenen Elementes zu ändern - das Element bleibt das selbe, deshalb ist es auch unsinnig, seine Identifikation ändern zu wollen.
Füge stattdessen per Javascript dynamisch eine Klasse hinzu bzw. entferne sie wieder, und nutze sie im CSS als Selektor für die gewünschte Formatierung.

Btw: In guten Browsern bräuchtest du dafür nicht mal Javascript, da würde :focus ausreichen. Nur der IE braucht ggf. die Javascript-Extrawurst.

Und die Seite könnte noch einiges an Überarbeitung vertragen - weg von veralteten Darstellungs-Elementen wie <center> und <font>, hin zu ordentlichem CSS.
Und die zum Layouten missbrauchte Tabelle sollte auch entsorgt werden.

gruß,
wahsaga

[Rafael]

okay, mit dem className JS hats geklappt. Hätte ich selber drauf kommen können, aber dank meinen beschränkten JS-Kentnissen dachte ich es müsste heißen this.class='Klasse' statt className...

Das verstehe wer will, das mit den IDs auch.

Ansonsten: Mein HTML ist valide, ich hatte nur keinen !Doctype und die doppelte ID. Die Seite ist aber auch noch nicht online, wie man sich vielleicht hätte denken können...

[Ashura]

Hallo Rafael.

[…] aber dank meinen beschränkten JS-Kentnissen dachte ich es müsste heißen this.class='Klasse' statt className...

Das verstehe wer will, das mit den IDs auch.

Das liegt einfach daran, dass „class“ ein seit langem <http://de.selfhtml.org/javascript/sprache/reserviert.htm#uebersicht@title=reserviertes Wort im Sprachbestand von JavaScript> ist.

Einen schönen Sonntag noch.

Gruß, Ashura

[Rafael]

Eines, das noch nicht verwendet wird, wohlgemerkt.

[Gernot Back]

Hallo Rafael,

Ich bin auf ein sehr seltsames Problem mit dem IE gestoßen. Ich bastle gerade an einer Webseite, die einen Newsletter anbietet. Dazu habe ich eine Leiste mit zwei Feldern, einer für den Namen und einen für die Email. Wenn jetzt jemand auf eines der Felder klickt soll sich die Ramendicke von 1 auf 2 erhöhen, was auch passiert.

um aber den text an der gleichen stelle zu lassen, soll sich der Rand um den einen Pixel verringern und das klappt im Prinzip auch (mit Firefox, Netscape und Opera).

Also zunächst mal:

Dein Dokument befindet sich im Quirksmodus:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">

Damit versuchen auch die von dir genannten Browser den Box-Model-Bug des IE-5.5 (und früherer Versionen) nachzuahmen, mit mehr oder weniger Erfolg:

http://www.carsten-protsch.de/zwischennetz/doctype/box_model_bug.html

INPUT-Elemente sind Inline-Elemente, denen man zwar einen Rahmen, Padding-Left und ~Right aber weder Margin (gleich welcher Himmelsrichtung) noch Padding-Top oder ~Bottom zuweisen kann, solange man sie in ihrer Default-Display-Eigenschaft belässt.

Wenn du aber deine Elemente, denen du rundherum einen Margin zuweisen willst, nebst den benachbarten Labels "Name" und "Email" floaten lässt, sie damit implizit zu Blockelementen machst, sie so vom gemeinsamen Zeilendasein mit dem Input vom Type Submit befreist und ggf. in den Compatmode:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
        "http://www.w3.org/TR/html4/loose.dtd">

wechselst, sollte sich dein Hüpf-Problem beheben lassen, das im wahrsten Sinne des Wortes so "marginal" ist, dass Wahsaga mich erst darauf hinweisen musste, worin es überhaupt besteht.

Gruß Gernot

PS: Es kann durchaus sein, dass ich mit der Analyse deines interessanten Problems selbst noch nicht ganz richtig liege; dann möge man mich korrigieren!

[wahsaga]

hi,

INPUT-Elemente sind Inline-Elemente, denen man zwar einen Rahmen, Padding-Left und ~Right aber weder Margin (gleich welcher Himmelsrichtung) noch Padding-Top oder ~Bottom zuweisen kann, solange man sie in ihrer Default-Display-Eigenschaft belässt.

Says who?

'margin':
"Applies to: all elements except elements with table display types other than table-caption, table and inline-table"

gruß,
wahsaga

[Gernot Back]

Hallo wahsaga,

Says who?

'margin':
"Applies to: all elements except elements with table display types other than table-caption, table and inline-table"

Ja, mag sein, dass zeilengebundene Inline-Elemente (schöner Pleonasmus) mit einem zugewiesenen Margin-Top oder ~Bottom sogar die eigene von der vorausgehenden oder nächsten Zeile entsprechend verrücken können, aber von der eigenen Zeile sollte das doch keinen Versatz bewirken, es sei denn der Browser befände sich in einem nicht-standard-konformen Modus.

Gruß Gernot