nicht angemeldet
Wieso nicht? Das br erzeugt einen (sichtbaren) Zeilenumbruch.
Und führt damit vermutlich dazu, dass der Firefox den page-break-before berücksichtigt. Soweit noch ok - aber warum liegt dann auch das absolut positionierte DIV-Element (innerhalb des DIV-Elements mit dem page-break-before) nun auf der zweiten Seite?
An der Position dieses Elements hat sich nichts verändert. Das eingefügte br mag auf die Interpretation des page-break-before einen Einfluss haben - dies darf sich aber nicht auf die Duckposition des absolut positionierten Elements auswirken!
Ich habe mir allerdings gerade überlegt, daß es vielleicht auch mit einem weißen border für die äußeren divs gehen oder zur Not zusätzlicher Inhalt über Pseudoelemente per CSS eingefügt werden könnte.
Mag sein, dass es eine andere Lösung gibt. Ich habe jedoch jetzt eine, die lediglich eine Modifikation durch das Einfügen von 4 Zeichen in meinem Programm bedingt und nun das gleiche Ergebnis im IE und Firefox bringt. Für Spielereien habe ich leider keine Zeit.
Meine Behauptung, dass hier ein Fehler im Firefox vorliegt, halte ich aber aufrecht. Es kann nicht angehen, dass nur durch das Einfügen eines Elements im normalen Fluss die Druckpositionierung eines absolut positionierten Elements verändert wird.
Ich bin zwar kein IE-Gläubiger, halte aber die Verherrlichung des Firefox in manchen Kreisen für maßlos überzogen.
Wer einmal per Javascript nach dem DOM Seiten mit enthaltenen Formularen manipuliert hat, weiss wovon ich schreibe.
Ralf