page-break-before und Firefox (mal wieder)
0 0 0 0 0 0 0 0 0 
at
page-break-before und Firefox (mal wieder)
Hallo,
ich habe festgestellt, dass der Firefox (bei mir 1.5.0.1) page-break-before:always ignoriert, wenn innerhalb des Blocks Elemente mit position:absolute verwendet werden.
Ich vermute einen Fehler in der Darstellung des Firefox (beim IE6 wird wie erwartet auf der nächsten Seite fortgesetzt) oder mache ich etwas in folgendem Beispiel falsch?
<body>
<div style="position: relative; width: 201.54mm; height: 286mm;">
<div style="border: 1px solid black; overflow: hidden; position: absolute; width: 61.54mm; height: 64mm; left: 140mm; top: 222mm;">
<table border="0" cellspacing="0" cellpadding="0"><tr><td width="100%">
<div style="left: 0cm; top: 0cm; width: 5.6cm; height: 0cm; position: relative">
<font face="Arial" size="2">Druckbereich</font>
</div></td></tr>
</table>
</div>
</div>
<div style="page-break-before:always; position: relative; width: 201.54mm; height: 286mm;">
<div style="border: 1px solid black; overflow: hidden; position: absolute; width: 61.54mm; height: 64mm; left: 0mm; top: 0mm;">
<table border="0" cellspacing="0" cellpadding="0"><tr><td width="100%">
<div style="left: 0cm; top: 0cm; width: 5.6cm; height: 0cm; position: relative">
<font face="Arial" size="2">Druckbereich</font>
</div></td></tr>
</table>
</div>
</div>
</body>
Das wirkt vielleicht etwas konstruiert, liegt aber daran, dass es automatisch erzeugt wird und ich auf den Inhalt der Tabelle keinen Einfluss habe.
Die Angaben für width und height der äußeren Blöcke sind auf A4 berechnet und berücksichtigen bereits Druckränder.
Ralf
-
Hi,
Ich vermute einen Fehler in der Darstellung des Firefox (beim IE6 wird wie erwartet auf der nächsten Seite fortgesetzt) oder mache ich etwas in folgendem Beispiel falsch?
Jein. Du ignorierst die Spezifikation:
"User Agents must apply these properties to block-level elements in the normal flow of the root element. User agents may also apply these properties to other elements, e.g., 'table-row' elements."
Es ist demnach wohl beides richtig um Sinne von zulässig. Verzichte auf die absolte Positionierung.freundliche Grüße
Ingo-
Jein. Du ignorierst die Spezifikation:
"User Agents must apply these properties to block-level elements in the normal flow of the root element. User agents may also apply these properties to other elements, e.g., 'table-row' elements."
Es ist demnach wohl beides richtig um Sinne von zulässig. Verzichte auf die absolte Positionierung.Ich kann auf die absolute Positionierung nicht verzichten, weil die Ausgabe exakt an der angegebenen Stelle auf der Seite erfolgen muss. Zumindest ist mir keine andere Lösung eingefallen.
Die absolute Positionierung ist ja auch nicht absolut in Bezug auf das Gesamtdokument, sondern nur in Bezug auf den Block, welcher mit page-break-before auf eine neue Seite gezwungen werden soll.
Ich sehe daher nicht, dass ich die genannte Spezifikation ignoriere. Wo finde ich diese übrigens?Ralf
-
Nachtrag:
Die Spezifikation habe ich gefunden:
<www.w3.org/TR/CSS21/page.html>Und es liegt auch eindeutig an position:absolute, weil es mit position:relative (in diesem Beispiel) funktioniert.
Für die Positionierung nur eines Elements ist es ja auch unbedeutend, ob absolute oder relative verwendet wird.
In meinem Fall sind es aber sehr viele Elemente, deren Position auf dem Blatt absolut recht einfach zu berechnen ist.
Nun muss ich mir überlegen, ob ich mir die Mühe mache, die Positionen relativ zu berechnen.Ich bin aber nach wie vor der Ansicht, dass hier der FF Mist macht, weil mit meiner Ausgangskonstruktion die Spezifikationen eingehalten werden.
Ralf
-
Hi,
Nun muss ich mir überlegen, ob ich mir die Mühe mache, die Positionen relativ zu berechnen.
Warum verwendest Du nicht einfach margin (ggfls. mit float)?
Ich bin aber nach wie vor der Ansicht, dass hier der FF Mist macht, weil mit meiner Ausgangskonstruktion die Spezifikationen eingehalten werden.
Nö, er hat sich nur dafür entschieden, die optionale Möglichkeit, die die Spezifikation bietet, nicht anzunehmen.
freundliche Grüße
Ingo-
Hallo Info,
Warum verwendest Du nicht einfach margin (ggfls. mit float)?
Wie sollte das in meinem konkreten Fall funktionieren? Die mit position:absolute versehenen Blöcke sind die Druckbereiche von Etiketten und da muss die Positionierung exakt berechnet werden können. Je Seite sind es x*y solcher Blöcke und nicht nur einer wie im Beispiel.
Nö, er hat sich nur dafür entschieden, die optionale Möglichkeit, die die Spezifikation bietet, nicht anzunehmen.
Dann verstehe ich wohl was falsch, denn "User Agents must apply these properties to block-level elements in the normal flow of the root element." bedeutet für mich, dass die Angabe für das DIV-Element zu berücksichtigen ist.
DIV ist ein Block-Element und m.E. im Beispiel auch im "normal flow". Was innerhalb eines Blocks dann noch per position:absolute passiert, dürfte keine Rolle spielen.Ralf
-
Hi,
Warum verwendest Du nicht einfach margin (ggfls. mit float)?
Wie sollte das in meinem konkreten Fall funktionieren? Die mit position:absolute versehenen Blöcke sind die Druckbereiche von Etiketten und da muss die Positionierung exakt berechnet werden können. Je Seite sind es x*y solcher Blöcke und nicht nur einer wie im Beispiel.
Du kannst Breiten, Höhen und Abstände (vom Rand und zwischen den Elementen) doch pixelgenau oder auch in mm angeben. Wo siehst Du hier ein Problem?
DIV ist ein Block-Element und m.E. im Beispiel auch im "normal flow". Was innerhalb eines Blocks dann noch per position:absolute passiert, dürfte keine Rolle spielen.
Nun, Firefox zumindest sieht das offenbar anders - auch wenn an Deiner Argumentation vielleicht etwas dran ist. Tatsache ist jedoch, daß es hier keine sichtbaren Elemente im normalen Fluß gibt.
freundliche Grüße
Ingo-
Hallo Ingo,
Du kannst Breiten, Höhen und Abstände (vom Rand und zwischen den Elementen) doch pixelgenau oder auch in mm angeben. Wo siehst Du hier ein Problem?
Vermutlich in der technischen Umsetzung. Ich habe eine (verkleinerte) Vorschau, die Original-Darstellung und den Ausdruck. Es basiert alles auf den absolut positionierten DIV-Elementen und funktioniert für IE und FF völlig problemlos. Nur der Ausdruck für mehr als eine Seite geht im FF nicht.
Rein logisch betrachtet solltet es auch mit Breiten, Höhen und Abständen realisierbar sein. Es wäre jedoch eine erhebliche Umstrukturierung innerhalb des Programms erforderlich und von daher nicht so schnell umzusetzen.
Tatsache ist jedoch, daß es hier keine sichtbaren Elemente im normalen Fluß gibt.
Sehe ich nicht so. Aber vielleicht ist auch mein Verständnis des normalen Flusses falsch. Eine Definition habe ich dafür nicht gefunden.
Ich habe aber mal testweise "<span style=display:none></span>" am Anfang des DIV-Elementes mit dem page-break-before eingefügt - und dann stellt es der FF auch korrekt dar!
Er scheint sich also daran zu stören, dass zuvor in dem Element kein Inhalt - abgesehen von absolut positionierten Elementen - vorhanden war.
Das Verhalten ist in meinen Augen zumindest inkonsistent und verdient die Bezeichnung Fehler.
Aber egal, mit diesem kleinen Kunstgriff lässt sich die Sache lösen und der Programmieraufwand ist minimal.
Vielen Dank für die Diskussion, die für mich zu einer Lösung geführt hat!
Ralf
-
Ich muss mich etwas korrigieren.
Mein letzter Test war mit einer Datei gewesen, wo zuvor testweise position:relative statt position:absolute benutzt wurde.
Und damit klappte es natürlich ...Ich habe aber das SPAN Element mit einem simplen <br> ersetzt und dann geht es auch mit position:absolute.
Verstehen muss ich das nicht ...
Ralf
-
Hi,
Ich habe aber das SPAN Element mit einem simplen <br> ersetzt und dann geht es auch mit position:absolute.
Verstehen muss ich das nicht ...
Wieso nicht? Das br erzeugt einen (sichtbaren) Zeilenumbruch.
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.freundliche Grüße
Ingo-
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
-
Hi,
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!Moment! Das br befindet sich im relative positionierten Element, welches somit einen Inhalt bekommt, der im Elementfluß zu berücksichtigen ist. Dadurch steht es dem Browser nicht mehr frei, für das relative positionierte Element page-break-before nicht zu berücksichtigen, er muß es also umbrechen. Und da sich die absolute Positionierung an diesem Element orientiert, muß dieses DIV natürlich mit umgebrochen werden.
Ich sehe das pragmatisch und könnte mir vorstellen, daß die Berücksichtigung von absolute positionierten Elementen aufwendiger ist und sich Firefox dies einfach spart, solange es zulässig ist.freundliche Grüße
Ingo
-
-
-
-
Hallo.
Tatsache ist jedoch, daß es hier keine sichtbaren Elemente im normalen Fluß gibt.
Sehe ich nicht so.
Kunststück, sind ja auch keine sichtbaren.
MfG, at
-
-
-
-
-
-
-