Styx-Edition V3.0.0

Wenn ich mein mobile quer stelle geht es. Es muss die Form entweder so neu erreichen oder neu geladen werden.

Genau. Das ist es vermutlich. Meins ist (einfach) größer! ?

Ok das ist es wohl nicht. 12 Points to Switzerland! ☺

Also wieder umstellen.

So kann es denn sein, dass es vielleicht am letzten Bee update liegt? Hat das styx.dokumenzi da eventuell noch die alte Version? Und alle neueren werfen einen error auf mobiles den wir vielleicht nicht sehen?

Test ab HUAWEI P10

Und bevor du tätig wirst, schau dir mal die pure.js an. Die ist auf deinem theme noch in einer alten Version. Irgendwann hast du nicht mitbekommen dass das ausgetauscht werden musste. Ich erinnere mich aber sehr wohl das angemerkt zu haben, weiß leider nicht mehr wo allerdings.
Vielleicht liegt da ja schon der Hase im Pfeffer! ?

Schalte mal (wieder) htmlcomment bzw den RichTextEditor an.... MOMENT, ? ich sehe gerade, dass ich letzteren wohlweislich nur pure erlaubt habe (...und habe ich das eigentlich irgendwo auch so dokumentiert? Ja das habe ich! Puh, wie die Zeit verfliegt...!).

Denn ohne htmlcomments macht das testen keinen Sinn, denn das ginge in Pure und deinem theme auch so. Das kannst du gerne mal ausprobieren.

Also müssen wir dem Dude da mal kurz etwas erlauben. Ich schreibe das gleich mal in unseren backend thread.

Ja so war das genau richtig. Ich habe es auch schon überprüft und zur Dokumentation einen kleinen mobile comment hinterlassen.

Mobile Test. Gboard funktioniert wie es soll. ?

Also ist das Problem entweder eine Frage in der Pure CSS, oder in der pure.js, oder in einer der hineingehängten CSS Teile. Ich hätte da zum Beispiel das shariff im Verdacht! Das hängt einen gewaltigen Block in den unteren Bereich des zusammengebundenen serendipity.css builds hinein (und das ja bei dir anders heißt) und hat möglicherweise irgendetwas darinnen, was im Verbunde mit dem pure.js das Verschwinden vom GBoard bei Verwendung beider Seitenleisten auslöst. Aber der Reihe nach. Wir werden - sobald du wieder kannst - das nach und nach untersuchen.

?

Inzwischen halte ich es für einen "Bug" der GBoard App, die einfach zu übersensibel reagiert auf das resize DOM element Sidebar Verschiebungsscript in Kombination mit dem CKE Skript. In dessen Historie gíbt es immer wieder mal solche Vorkommnisse. Sehr interessant wäre es in diesem Zusammenhang ja zu sehen, ob Apple Geräte ein gleiches Verhalten zeigen.

Wenn du diesen Teil im pure.js daher abschaltest, mit /* inhalt */, sollte es eigentlich wieder funktionieren. Prüfe das mal. (Allerdings hat man dann das Problem das die left sidebar auf unter 1024px Geräten oben bleibt.)

Ich sitze daran etwas anderes zu finden, bzw diese javascript gänzlich abzuschalten und das wie bei dem Dude per CSS und Media Queries zu erschlagen. Leider hätte ein Verzicht auf das doch sehr einfache aber eben so ungemein praktische javascript weitere Nachfolgewirkungen, so das dass nicht so schnell gehen wird. Und heute wahrscheinlich gar nicht mehr.

Ciao

Klasse. Ich dachte das sollte so sein. Grade eine korrigierte Version hinterlegt.

Grundsätzlich schon....
Dummerweise habe ich das kleine scriplet auch für das default theme eingesetzt, das es mich immer schon störte, dass das bezüglich Seitenleisten und Mobiles so unflexibel war. Auf diesem default theme beruhen eine ganze Reihe von themes die einfach dessen index.tpl, oder das gleiche Scriptlet nutzen. Zwar sind davon nicht alle wiederum 2-sidebar themes, aber es hat eben doch einige Nachfolgewirkungen. Diese grid CSS Geschichte ist eben auch viel neuer und benötigt aktuellere Browser zur Darstellung, als so ein simples javascript.

Ich finde aber man könnte pure als 2020er Standard Theme durchaus eben auch als solches deklarieren und damit das grid zum Browser Requirement machen. Das war u.a. einer der Gründe warum ich das Konzept the Dude entworfen hatte, um zu zeigen wie man heute damit umgehen kann.

Andererseits würde ich gerne noch herumtesten (und da kämest du ins Spiel) wie man das scriptlet eventuell verändern/verfeinern muss damit Gboard unbeeindruckt bleibt. Desktops lassen sich bestens ohne javascript betreiben, mobiles sind per se darauf angelegt. Ich könnte mir vorstellen, dass es irgendein touch event gibt mit dem man in Formfeldern das scriptlet einfach zur Laufzeit aus dem Spiel nimmt, denn der Ort wo das eine Rolle spielt ist ja extrem klar definiert, oder? Hast du im Backend mal versucht eine ähnliche Reaktion auf Mobiles zu reproduzieren? (Ich glaube es ja eher nicht.)

Ich schulde Dir noch eine Antwort von wegen Kommentieren per iPhone. Das funktioniert sowohl bei www.beatsblog.ch (mit js) und auch bei www.styx.beatsblog.ch (ohne js).

Was man aber nicht tun sollte: Den Blog mit einem iPad und Safari im Hochformat betrachten Die statische Titelseite und die Blogdarstellung (/frontpage) sieht noch o.k. aus, doch die Single-Entry-View ist zum ? heulen. Da wird in der linken SL der Content dargestellt und umgekehrt. Die rechte Seitenleiste stimmt zwar, doch sollten bei der Auflösung ja generell keine SL angezeigt werden.

Sobald man etwas nach unten scrollt, korrigiert sich SL und Content, doch die Seitenbreite ist viel zu breit. Dies liegt vermutlich am entrypaging-Plugin, welches weit rechts, ausserhalb allem noch dargestellt wird (und deshalb wird wohl auch die Seite incl. SL dargestellt, weil eine bedeutend grössere Bilschirmbreite angenommen wird).

Ich habe dann das entrypaging-Plugin deaktiviert und siehe da: nun stimmt auch die Darstellung auf dem iPad (ohne SL)

Tja: Das entrypaging-Plugin bremst nicht nur die Single-Entry-View, sondern es zerschiesst auch die Darstellung in einem Safari-Browser. Ich muss das wohl -schweren Herzens- killen. ☠

Ich sagte ja das Safari gerne mit einem auf Safari fährt.... ?

In dem Fall würde ich schätzen dass es mit dem svg Pfeilen nicht zurecht kommt. Wenn du auf die low-level Variante mit den Bilder Pfeilen downgradest sollte auch Safari damit klar kommen. Du weißt was ich meine? Bin gerade zu beschäftigt um selbst nachzuschauen...

.. habe ich das kleine JS scriplet auch für das default theme eingesetzt, [...] Auf diesem theme beruhen eine ganze Reihe andere, die einfach dessen index.tpl, bzw das gleiche Scriptlet nutzen. Zwar sind [...] es nicht alle,  es hat aber eben doch einige Nachfolgewirkungen.

Nur zur Info. Da ja dieser "bug" als Bedingung eine Folge der Nutzung [1] vom Scriptlet, [2] des CKEditors im frontend commentform und [3] der Android Gboard App ist, ist/war meine Sorge gegenüber dem default und anderen themes haltlos, denn ihnen fehlt die Bedingung [2] der genannten. Der Kommentarform (CKE) ist nur "pure" und neu dann auch "The Dude" und ihren Abkömmlingen erlaubt. Und somit ist alles bester Ordnung. ?

Gerne! ? .. wenn ich könnte...

Kannst du mal auf styx.beatsblog das s9ymarkup Plugin deaktivieren (in hidden section schieben und abspeichern). Und dann mal an umterschiedlichen Stellen des Blogs nachmessen, ob sich das mit dem +1 sec entrypaging delay verringert, oder gar verschwindet, oder gleichbleibt?! Oder hatten wir das schon mal untersucht?

Schade!
Ich hatte mir gestern nochmal die entrypaging Zusammenstellung angesehen und konnte einfach nur feststellen, dass das nicht besser geht und schon so weit minifziert ist, dass es nicht diesen delay auslösen kann. Es muss also das Zusammenwirken mit irgendeinem anderen Plugin oder Einstellung sein.