FOUC wegen live-Uhrzeit

[bernhard]

Ich bin sicher, dass die Ursache des Problems bei KeyHelp liegt
ja

KeyHelp-Version + Build-Nummer
23.1.1 (Build 3016)

Problembeschreibung / Fehlermeldungen
Bei einer ganz bestimmten Bildschirmauflösung springt das Layout durch unterschiedlich breite Zeitangaben herum:



Erwartetes Ergebnis
Das Design sollte nicht abhängig von der Zeit sein

Tatsächliches Ergebnis
Beim Datum/Zeit sind verschiedene Werte unterschiedlich breit, zB ist 1 viel weniger breit als 0 oder 7 etc.

Schritte zur Reproduktion
Wenn man im Panel 10 Sekunden auf eine beliebige live-Uhrzeit schaut, sieht man das PM am Ende immer wieder links/rechts hüpfen. Bei einer bestimmten Bildschirmauflösung kann das dazu führen, dass abhängig von der aktuelle Sekunde die Anzeige mehrzeilig wird oder sich noch auf einer Zeile ausgeht.

Zusätzliche Informationen
Man könnte das lösen, indem man für die live-Uhrzeit per CSS eine fixe Breite für die Ziffern forciert:
https://stackoverflow.com/questions/101 ... -using-css

[Tobi]

Da das weder ein Bug oder ein Problem ist, verschiebe ich es mal nach "Wunschecke".

Davon abgesehen kannst du das von dir gewünschte Verhalten mit den White-Label-Einstellungen selbst einstellen.

[24unix]

Das Design sollte nicht abhängig von der Zeit sein

Muss man unbedingt mit dem Handy ins Panel?



Mit einem normalem Computer sehe ich da echt kein Problem.

Ja, ich hasse es, wenn Leute mit Handies "surfen" …

[tab-kh]

Ist mir unklar, mit welchem Smartphone das bei welcher Bildschirmbreite passiert. Ebenso, welcher Font da im Einsatz ist. Bei mir auf dem Bildschrim und auch auf dem Smartphone flattert da nichts und alle Uhrzeiten sind gleich breit.

[bernhard]

Kein Mensch hat irgendwas davon gesagt, dass das in der Mobil-Version der Fall ist.

Ich hätte eine Auflösung genannt, bei der das vorkommt. Das Problem tritt aber zu unterschiedlichen Zeiten bei unterschiedlichen Auflösungen auf.

Warum man das nicht als Bug bezeichnen darf versteh ich zwar nicht, aber dann ist es halt ein Funktionswunsch...

Font und Layout ist alles Standard KeyHelp. Und ich habe auch einen "normalen" Computer. Mit einem recht großen Screen, wo ich links meist VSCode offen habe und rechts den Browser. Und da ist mir das Problem - sorry, der Funktionswunsch - heute erstmals mehr oder weniger zufällig aufgefallen.



Man sollte das recht gut reproduzieren können, wenn man das Fenster so lange kleiner macht, bis die Zeitangabe im Dashboard zweizeilig wird. Dann wieder ein bisschen größer machen, bis es bei Sekunde "1" einzeilig klappt und bei allen anderen Sekunden-Werten zweizeilig. Dann hüpfen die einzelnen Panels doch ganz ordentlich am Screen herum, was aus meiner Sicht nicht schön ist.

[tab-kh]

Ja,nach nochmaligem Lesen des Threads sehe ich, dass Du kein Mobilgerät erwähnt hast, das war 24unix. Genau so, wie von dir beschrieben habe ich es ja bei mir ausprobiert. Und es passiert bei mir einfach nicht. Deswegen frage ich ja nach dem Font, Device oder auch Browser. Weil ich vermute, dass das Problem am verwendeten Font oder irgendwelchen Systemeinstellungen hängt. Kerning oder irgend sowas. Bei mir wackelt da nichts, kein Pixel und auch kein Zehntel-Pixel. Vielleicht ist ja im angegebenen Fontstack irgendein Font drin, mit dem es nicht funktioniert. Was nicht heißt, dass man das nicht verhindern könnte. Viele Proportionalschriften haben (ggf zusätzliche) Ziffern für Tabellen, die gleich breit sind. Betrifft natürlich normalerweise nur Proportionalschriftarten. Bei den anderen sind ja eh alle Zeichen gleich breit. Nicht unbedingt die Zeichen selbst, aber die Zelle, in der sie sitzen.

[Tobi]

Na es ist ganz einfach deswegen kein Bug, weil es nur zu bestimmten Uhrzeiten bei einer ganz speziellen Auflösung auftritt und ausser dem Hin- und Hergezappel keinerlei Auswirkungen auf die Funktion von KeyHelp hat.

Und wenn der Fehler nur bei 2034x893 Pixeln zwischen 03:23 und 03:27 Uhr auftritt, wäre meine pragmatische Lösung entweder dem Browserfenster drei Pixel mehr in der Breite zu spendieren oder einfach erst um 03:45 Uhr wieder KeyHelp verwenden.

Oder eben White-Label nutzen.

So viele Lösungen für ein Nicht-Problem…

[bernhard]

@tab-kh, danke, dass du meinen Post ernst nimmst und versucht zu einer Lösung beizutragen! Ich habe das aufgrund der anderen ignoranten Antworten leider missverstanden, sorry dafür!

Ich hab es jetzt nochmal mit den Devtools versucht:



In diesem Fall tritt der Funktionswunsch bei 1283 Pixel breite auf.

Ich bin auf Mac unterwegs mit Chrome. Hab gerade die Font geprüft:

Code: Select all

body, button, input, optgroup, select, textarea {
    font-family: BlinkMacSystemFont,-apple-system,"Segoe UI","Roboto","Oxygen","Ubuntu","Cantarell","Fira Sans","Droid Sans","Helvetica Neue","Helvetica","Arial",sans-serif;
}

Ich hab jetzt "font-family: arial !important", aber auch da tritt der Funktionswunsch auf, was ja nicht weiter überraschend ist, da das keine monospace font ist. Zum Reproduzieren empfiehlt es sich übrigens die Browser Devtools zu verwenden und dort den "Responsive" Moduls zu wählen, dann kann man die Fensterbreite pixelgenau setzen.

Mit "courier new" klappt es, sieht aber ziemlich hässlich aus:



Sieht also aus meiner Sicht so aus, als könnte das nur Mac-User betreffen? Kann das vielleicht ein anderer Mac-User nachprüfen?

[24unix]

Sieht also aus meiner Sicht so aus, als könnte das nur Mac-User betreffen? Kann das vielleicht ein anderer Mac-User nachprüfen?

Ich kann Dir auf jeden Fall bestätigen, dass derTeil "PM (Europe/Berlin)" hinter der Uhrzeit links/rechts wandert.
Ist mir vorher noch nie aufgefallen.
(Ventura mit Safari).

Ausserdem bin ich gerade verwundert, dass ich 12h Zeit habe, ich verwende eigentlich überall en_GB statt us_US, um military time (24h) zu bekommen.

[tab-kh]

Mit Mac kann ich nicht dienen und habe das Problem nicht, was deine Vermutung unterstützt. Bei mir (Windows 11) kommt, weil "BlinkMacSystemFont" und "-apple-system" natürlich nicht verfügbar sind, "Segoe UI" zum Einsatz. Damit bewegt sich da überhaupt nichts, obwohl auch das kein Monospace Font ist. Wenn es nur bei Apple/MAC auftritt, ist es wahrscheinlich ein Feature .

[24unix]

Wenn es nur bei Apple/MAC auftritt, ist es wahrscheinlich ein Feature .

Zumindest mit Safari, Chrome und Fx.

Edit:

Code: Select all

body, button, input, optgroup, select, textarea {
    font-family: BlinkMacSystemFont,-apple-system,"Segoe UI","Roboto","Oxygen","Ubuntu","Cantarell","Fira Sans","Droid Sans","Helvetica Neue","Helvetica","Arial",sans-serif;
}

Führt dazu, dass das ganze im Safari von .AppleSystemUIFont gerendert wird.
Disabled man die Rule sieht es besser aus.

[Tobi]

Wie man an deinem Farbschema sehen kann verwendest du bereits ein angepasstes CSS.

Dann poste doch bitte einfach deine Lösung hier und Alex wird das sicherlich dankend in die nächste CSS Korrektur mit aufnehmen.

Danke

[24unix]

Wie man an deinem Farbschema sehen kann verwendest du bereits ein angepasstes CSS.

Das ist der normale DarkMode der Pro-Version.

Dann poste doch bitte einfach deine Lösung hier und Alex wird das sicherlich dankend in die nächste CSS Korrektur mit aufnehmen.

Danke

Es gab hier einen Thread mit einem DarkMode via WhiteLabel, den verwende ich auf meiner Dev-Kiste, da tritt das Problem nicht auf.

Dort sieht das CSS so aus:

Code: Select all

body, button, input, optgroup, select, textarea {
	font-family: IBM Plex Mono,monospace;
}

[Tobi]

Also ich habe jetzt bei beiden Versionen nachgesehen.
Sowohl bei Standard als auch Pro.

Beide Male steht die Zeitangabe in einem SPAN Tag mit der id: app-server-time
Macht ja auch Sinn, da das JS wissen muss wo die neue Zeit hinzuschreiben ist.

Also sollte folgende CSS Anpassung den gewünschten Effekt bringen.

Code: Select all

#app-server-time{

	    white-space: nowrap;

}

Ich muss jedoch zu meiner Schande gestehen, dass es mir unmöglich war den Funktionswunsch nachzustellen.
Egal in welche Auslösung ich meinen Browser gezupft habe, immer kurz bevor es tatsächlich eng geworden wäre ist ohnehin die gesamte Ansicht weiter zusammengerutscht. Responsivität lässt grüßen.

Daher würde ich mich ungemein freuen falls einer der Betroffenen den Patch ausprobieren könnte und uns hier berichtet wie die Zeitsprünge nun verlaufen.

[bernhard]

@tobi white-space nowrap würde das Problem nicht lösen. Das Problem ist ja nicht der Zeilenumbruch an sich, sondern dass unterschiedliche Zeiten unterschiedlich breit dargestellt werden. Das ist zwar minimal und fällt kaum auf, aber manchmal führt es dann eben zu wechselnden Umbrüchen, wenn man Pech hat mit der Auflösung.

Mit nowrap würde man die einzeilige Darstellung erzwingen und müsste dann auf kleinen Screens irgendetwas anderes machen, zB ein text-overflow ellipsis, was dazu führen könnte, dass man gar keine Zeitangabe mehr sieht. Da ist eine mehrzeilige Darstellung aus meiner Sicht sinnvoller.

Ich habe deshalb in meinem ersten Post einen Link zu einem Lösungsvorschlag gepostet, und zwar "font-variant-numeric: tabular-nums;"

Das mag vielleicht auch nicht in 100% der Fälle funktionieren, aber es würde die Anzahl der Betroffenen User sicherlich nochmal massiv reduzieren. Mich eingeschlossen, weil ich hab das schon erfolgreich getestet

Bezüglich des Custom Styles: Da sind nur Farben geändert, sonst wie gesagt alles default Keyhelp font. Ich hab's zum Testen auf zwei Servern ausprobiert um zu sehen, ob sich einer anders verhält als der andere. Ist aber auf beiden das exakt gleiche Verhalten.