Sehr einfache .htm Seite zeigt "unvorhersehbares" Verhalten.

[ScoutX]

Eine von dem Programm TagScanner (nur zur Vollständigkeit) generierte und von mir abgeänderte .htm Seite zeigt merkwürdiges Verhalten. Siehe die beiden Screenshots im Anhang. Dort sind aus vielen richtig angezeigten div Bereichen exakt zwei Elemente, die verschoben sind.
Zu den Screenshots: Bewusst einmal mit Bild und einmal ohne gefundenes Bild. Die Bilder scheinen keine Rolle zu spielen.
Das ist nur auf meinem Arbeitsrechner mit Server 2008 R2 so: Mit allen Browsern (Chrome, Firefox, Vivaldi, Opera - neueste Versionen) außer dem IE 11. Ich kann mir nicht erklären, woran dies liegt. Der Fehler tritt bei der typischen Monitorauflösung bei 1080p auf. Zwei weitere physikalische Maschinen bleiben von dem Fehler verschont.
Hat jemand eine Erklärung oder vielleicht sogar die gleichen Fehler?. Die besagte .htm ist in der Zip Datei im Anhang.

 

[andredc]

sieht bei mir so aus wie es soll einheitlich untereinander
2560x1440 auflösung

 

[ScoutX]

Bei mir fängt die Verschiebung bei etwa 1550 Breite an. Die beiden Stellen reagieren marginal unterschiedlich bei Breitenreduktion. Kleinere Breite ist alles OK. Wie gesagt: das ist suspekt. Ich sehe keine Steuerzeichen, die dies verursachen könnten. Arbeitsspeicher korrupt? Aber immer an der selben Stelle? Wohl auch nicht. Gegenüber der Menge an den anderen DIVs mit selber Struktur sehe ich auch hier keine Gemeinsamkeiten der beiden Elemente.

Noch jemand eine Idee oder ein Tool, um dem nachzugehen?

 

[r0b0t]

Das liegt an dem style = float; siehe: https://wiki.selfhtml.org/wiki/CSS/Eigenschaften/Positionierung/float
Wenn nicht genügend Platz ist, verschiebt der Browser die Elemente entsprechend.
Wenn man da eine schöne Tabelle haben will, muss man halt eine Tabelle (innerhalb der bereits vorhandenen) definieren.

 

[thehintsch]

evtl. ein (nicht sichtbares) Sonderzeichen drin? Wenn ich mir den Quelltext in Firefox anzeigen lasse fällt auf, dass vor den betroffenen Einträgen die Zeilanabstände irgendwie größer sind. Man sieht es besser, wenn man Teile des Textes mit der Maus markiert. Da ist die markierte Fläche unterschiedlich groß, bei den anderen Zeilen ist dies nicht der Fall

 

[r0b0t]

Die unterschiedliche Zeilenhöhe entsteht, weil das I in "Menuett Ⅰ" und das II in "Menuett Ⅱ" spezielle Unicodezeichen sind, die wohl je nach Font etwas mehr Platz benötigen.

 

[ScoutX]

"Float" ist mir leidlich bekannt, dass es dort Probleme geben kann.
Es ging mir darum, dass es an einem von drei Rechnern mit 1080p Auflösung genau an zwei Stellen von über 300 zu Problemen kommt.
Jetzt frag ich mich warum? Was ist an den zwei Stellen so besonders auf meinem Rechner. Es sind nicht die "längsten" Div Container. Oberhalb und unterhalb der betroffenen Zeilen sind keine offensichtlich ungewöhnlichen padding - marging Probleme, die andere (viel mehr) Zeilen nicht mindestens auch haben müssten.

Klar ist, dass die Größe der Schritart, die Font-Familie, die Breite bzw. respektive die Auflösung und der Zoomfaktor eine Rolle spielen. Spiele ich z. B. mit dem Zoom, kann ich noch weitere wenige Container zum Kippen bringen. Interessant auch, dass hier keine Regelmäßigkeiten vorliegen. Manchmal kippen Zeilen bei 70% - 90%, manche nur bei 150%.

Für mich ist dieses Verhalten unvorhersehbar. Interessant auch das der IE hier keine aber auch gar keine Probleme hat.
Somit kann ich nur vermuten, dass es mit der Art und Weise, wie Float Elemente über Betriebssystemschnittstellen plaziert werden unter Microsoft und vor allem bei meinem 2008 R2 mit Desktopdarstellung zu "falschen" Abfragewerten kommt.

EDIT: Nochmals 3 Anhänge, die zeigen, was ich meine. Nur auf der Zoomstufe 100%, aber weder größer als noch kleiner, kippt der Eintrag bei der Klassiksammlung 6.

Ergänzung (11. April 2018)

Ursache erkannt

Was alle Browser bis auf den IE bei meinem Arbeitsrechner nicht perfekt können.
Ursache bei 100% Zoom. Ein Zeichen der darüberliegenden Zeile:
1. Charles‐François --> der Bindestrich erzeugt diesen Fehler
2. Titel: Feuerwerksmusik in D-Dur: Menuett Ⅰ--> Hier tatsächlich das I

Einen Dank an r0b0t für die Idee am Text des eigentlichen Quelltextes herumzuspielen.

Was sehe ich bei diesen Zeilen, wenn ich diese Zeichen lösche? Nur noch einen Font!
Diese zwei Zeichen erzeugen nur hier jeweils einen Extra-Font
1. Lucida Sans Unicode
2. DejaVu Serif

gegenüber meinem Systemfont für Browser "Tahoma".

Obwohl ich die HTM in UTF 8 abgespeichert habe, sind diese Zeichen auch nicht sauber im Quelltext enthalten.
Da habe ich nicht dran gedacht, vor allem, da das HTM bis auf den Layoutfehler richtig geparst wurde.

Diese Layoutfehler entstehen, wenn zwei Fonts gleichzeitig "gefloatet" werden.