Aloha ;) > > Ich! … > > hehe... das könnte einmal auf einen längeren Besuch hinauslaufen (endlich mal)... 😉 Hehe, du weißt, ich bin nicht weit weg 😛 Grad ist bei mir noch viel los, aber das ändert sich in den nächsten Wochen wahrscheinlich. Ich werde dich dann vielleicht einfach mal belästigen, egal ob mit Android-Kumpan oder ohne 😛 > > > … und kann das mit dem dortigen Stock-Browser testen? > > > > … äh, doch nicht. Ich habe den Stock-Browser leider nicht > > Mit größter Wahrscheinlichkeit nutzt dieser Dein Browser eine Android-Webview im Hintergrund, um die Seiten zu rendern. Damit ist es quasi "der Stockbrowser". Nein, ich verwende Chrome und der benutzt tatsächlich nicht die Android-Webview (Stock-Browser-Bugs kommen im mobilen Chrome nicht vor). Ich hatte versucht, deine Seite über die Google-App aufzurufen, weil ich vermute, dass da tatsächlich ne Stockbrowser-Webview dahinter steckt. Konnte aber damit auf deiner Seite keine Auffälligkeiten feststellen. > Zumindest konnte ich [bei Samsung ein Java-Applet nutzen, das mir eines der Samsung-Geräte live zum Ausprobieren anbietet](http://developer.samsung.com/remotetestlab/rtlDeviceList.action). Da kann ich in 5 Minuten (kostenloses Zeitmaximum) zumindest testen, ob etwas wie gewünscht im Browser dargestellt wird, oder nicht. Das ist doch schonmal was! Danke für den Link, kann sehr nützlich sein. > Durch das Einblenden des Softkeyboards wird anscheinend ein mehrmaliges Neuzeichnen ausgelöst, denn die Seiteninhalte werden mindestens zwei mal "bewegt", um für das Keyboard Platz zu schaffen. Dabei rutscht das zentrierte Kindelement von <dialog> nach links und nach oben. Lustig. Bei mir im mobilen Chrome nicht. Da rutscht die Seite allerdings auch seltsam! Konkret habe ich sogar das Gefühl, dass mein Browser die Dialogbox (unabsichtlich-) absichtlich hinter die Tastatur fährt, da mir nicht ohne weiteres klar ist, was die Dialogbox SO weit unten überhaupt verloren hat oder warum die da platziert werden könnte. Vielleicht tut die virtuelle Tastatur bisher Unbekanntes mit der Seitenstruktur bzw. ihren auslesbaren / für CSS verfügbaren Abmessungen? Nach dem ersten Neuzeichnen der Seite ist der Dialog bei mir nämlich tatsächlich in der Bildschirmmitte, für nen Sekundenbruchteil. Dann erst, sobald die Tastatur merkt, Hoppla, ich bin gefragt, rutscht der Dialog weiter nach unten. Und bleibt da unten, wenn ich die Tastatur schließe. Das betrifft allerdings nur den „Dialog“, das weiß verblendete `dialog`-Element wird ja immer richtig angezeigt. Abgefahrene Theorie: Aus irgendeinem Grund bezieht der Dialog seinen oberen margin auf den Beginn der Tastatur und rutscht von diesem aus noch 25% des noch ohne Tastatur verfügbaren Platz weiter hinunter. Das würde für mich ziemlich gut erklären, warum die Box da hängt wo sie hängt (denn wenn meine Tastatur ausgefahren ist, ist im Breitformat tatsächlich weniger Browser- als Tastaturfläche und rein optisch könnte das dann hinhauen. Und jetzt kommt eine noch interessantere Beobachtung: Sobald ich auf Hochformat drehe ist alles paletti. Und die Box hängt in der oberen Bildhälfte. Wenn ich wieder drehe, nicht mehr, dann hängt sie wieder unten... > > Es ist und bleibt einfach so, dass der Android-Stock-Browser in manchen Belangen ziemlicher Müll ist, man kann sich da auf nicht viel verlassen > > Wenn ich will, dass meine Quizze bedienbar sind, nützt mir kein Klagen. Da muss ich im Rahmen des Machbaren (diesen Rahmen gilt es noch zu definieren/ergründen) eben alles umsetzen. Ich weiß schon. Es tut nur so gut auf die vermaledeite moderne Technik zu schimpfen, und das obwohl ich mich noch gar nicht nach „früher, als die Gummistiefel noch aus Holz waren“ alt fühle 😂 > > - und Debugging-Möglichkeiten gibts ja auch kaum bis keine. > > Da hoffe ich doch stark auf Android Studio und Konsorten. Das muss ich mir auch noch anschauen. Ich dachte nur, dass damit schon jemand genügend Erfahrung hätte, um mir bereits konkrete Tipps geben zu können. Bei Chrome gibt es Debugging-Tools, die man am PC laufen lassen kann, wenn man das Mobilgerät damit verbindet. Nur für den Stockbrowser, der ja die meisten Probleme macht, hilft das leider nicht viel. Und ob da noch was kommt, was sich für sinnvolles Debugging einsetzen lässt... Weiß ja nicht. Bin ich mal gespannt. Wenn sie der Chrome-Philosophie folgen würden bräuchtest du aber dafür auch erstmal ein Gerät mit besagtem Stock-Browser. > Aber die Sache mit "unter der Tastatur" ist natürlich ärgerlich. Mein Denkkonzept dabei ist folgendes: > > ~~~ ascii > +---------------------------------------+ > | dialog {position:fixed;top:0;left:0;} | > | | > | +-----------------------------+ | > | | div {margin:25% auto;} | | > | | | | > ~~~ Richtig - verstehe ich und ist auch das, was bei mir im Hochformat tatsächlich passiert. > Dadurch, dass es die Tastatur über die Anzeigefläche legt, wird im Browser einiges verschoben. Was da genau passiert, verstehe ich noch nicht. Inwiefern ich mein <div> in den noch sichtbaren Bereich bekomme, habe ich auch noch nicht verstanden. Anstatt mit `margin:25% auto;`{: .language-css} habe ich schon mit anderen Werten experimentiert. Aber wenn "überbreite" Elemente auf der Seite sind, die ein Scrollen der gesamten Seite nach rechts ermöglichen, dann ist "die Mitte" eben auch "weiter rechts", weshalb es mir das Dialogfeld nach links verschiebt, denn für `position:fixed;`{: .language-css} ist die Mitte eben nur das gerade sichtbare Feld, und das beginnt immer ganz am linken Seitenrand, für die Tastatureingabe wird aber offensichtlich zur "echten" Seitenmitte hin gescrollt. o_O Siehe meine Anmerkungen oben. Falls meine abgespacete Theorie zutrifft wäre `margin` schuld. Versuch doch mal temporär, das ohne margin zu lösen. Nimm der Dialog-Box doch mal den margin weg und schenk dafür seinem parent ein padding. Oder mach die Dialog-Box auch zu einem `position:fixed`. Wobei. --- Äh. Ich glaube ich sehe jetzt das Problem hier bei mir. Verwend doch mal bitte keine Prozente, sondern `vh` für das margin nach oben. Der Bereich links und rechts über meiner Dialogbox sieht verdächtig quadratisch aus. Vielleicht nimmt der da Breiten-Prozente..? Das erklärt, warum es im Hochformat klappt (Seitenbreite < Seitenhöhe) und im Querformat nicht mehr. Aber freu dich nicht zu früh, kann mich auch irren. Grüße, RIDER -- Camping_RIDER a.k.a. Riders Flame a.k.a. Janosch Zoller # [Twitter](https://twitter.com/Camping_RIDER) # [Steam](http://steamcommunity.com/id/Camping_RIDER) # [YouTube](https://www.youtube.com/user/RidersFlame) # [Self-Wiki](http://wiki.selfhtml.org/wiki/Benutzer:Camping_RIDER) # [Selfcode](http://community.de.selfhtml.org/fanprojekte/selfcode.htm): sh:) fo:) ch:| rl:) br:^ n4:? ie:% mo:| va:) js:) de:> zu:} fl:( ss:) ls:[

Aloha ;) > > Ich! … > > hehe... das könnte einmal auf einen längeren Besuch hinauslaufen (endlich mal)... 😉 Hehe, du weißt, ich bin nicht weit weg 😛 Grad ist bei mir noch viel los, aber das ändert sich in den nächsten Wochen wahrscheinlich. Ich werde dich dann vielleicht einfach mal belästigen, egal ob mit Android-Kumpan oder ohne 😛 > > > … und kann das mit dem dortigen Stock-Browser testen? > > > > … äh, doch nicht. Ich habe den Stock-Browser leider nicht > > Mit größter Wahrscheinlichkeit nutzt dieser Dein Browser eine Android-Webview im Hintergrund, um die Seiten zu rendern. Damit ist es quasi "der Stockbrowser". Nein, ich verwende Chrome und der benutzt tatsächlich nicht die Android-Webview (Stock-Browser-Bugs kommen im mobilen Chrome nicht vor). Ich hatte versucht, deine Seite über die Google-App aufzurufen, weil ich vermute, dass da tatsächlich ne Stockbrowser-Webview dahinter steckt. Konnte aber damit auf deiner Seite keine Auffälligkeiten feststellen. > Zumindest konnte ich [bei Samsung ein Java-Applet nutzen, das mir eines der Samsung-Geräte live zum Ausprobieren anbietet](http://developer.samsung.com/remotetestlab/rtlDeviceList.action). Da kann ich in 5 Minuten (kostenloses Zeitmaximum) zumindest testen, ob etwas wie gewünscht im Browser dargestellt wird, oder nicht. Das ist doch schonmal was! Danke für den Link, kann sehr nützlich sein. > Durch das Einblenden des Softkeyboards wird anscheinend ein mehrmaliges Neuzeichnen ausgelöst, denn die Seiteninhalte werden mindestens zwei mal "bewegt", um für das Keyboard Platz zu schaffen. Dabei rutscht das zentrierte Kindelement von <dialog> nach links und nach oben. Lustig. Bei mir im mobilen Chrome nicht. Da rutscht die Seite allerdings auch seltsam! Konkret habe ich sogar das Gefühl, dass mein Browser die Dialogbox (unabsichtlich-) absichtlich hinter die Tastatur fährt, da mir nicht ohne weiteres klar ist, was die Dialogbox SO weit unten überhaupt verloren hat oder warum die da platziert werden könnte. Vielleicht tut die virtuelle Tastatur bisher Unbekanntes mit der Seitenstruktur bzw. ihren auslesbaren / für CSS verfügbaren Abmessungen? Nach dem ersten Neuzeichnen der Seite ist der Dialog bei mir nämlich tatsächlich in der Bildschirmmitte, für nen Sekundenbruchteil. Dann erst, sobald die Tastatur merkt, Hoppla, ich bin gefragt, rutscht der Dialog weiter nach unten. Und bleibt da unten, wenn ich die Tastatur schließe. Das betrifft allerdings nur den „Dialog“, das weiß verblendete `dialog`-Element wird ja immer richtig angezeigt. Abgefahrene Theorie: Aus irgendeinem Grund bezieht der Dialog seinen oberen margin auf den Beginn der Tastatur und rutscht von diesem aus noch 25% des noch ohne Tastatur verfügbaren Platz weiter hinunter. Das würde für mich ziemlich gut erklären, warum die Box da hängt wo sie hängt (denn wenn meine Tastatur ausgefahren ist, ist im Breitformat tatsächlich weniger Browser- als Tastaturfläche und rein optisch könnte das dann hinhauen. Und jetzt kommt eine noch interessantere Beobachtung: Sobald ich auf Hochformat drehe ist alles paletti. Und die Box hängt in der oberen Bildhälfte. Wenn ich wieder drehe, nicht mehr, dann hängt sie wieder unten... > > Es ist und bleibt einfach so, dass der Android-Stock-Browser in manchen Belangen ziemlicher Müll ist, man kann sich da auf nicht viel verlassen > > Wenn ich will, dass meine Quizze bedienbar sind, nützt mir kein Klagen. Da muss ich im Rahmen des Machbaren (diesen Rahmen gilt es noch zu definieren/ergründen) eben alles umsetzen. Ich weiß schon. Es tut nur so gut auf die vermaledeite moderne Technik zu schimpfen, und das obwohl ich mich noch gar nicht nach „früher, als die Gummistiefel noch aus Holz waren“ alt fühle 😂 > > - und Debugging-Möglichkeiten gibts ja auch kaum bis keine. > > Da hoffe ich doch stark auf Android Studio und Konsorten. Das muss ich mir auch noch anschauen. Ich dachte nur, dass damit schon jemand genügend Erfahrung hätte, um mir bereits konkrete Tipps geben zu können. Bei Chrome gibt es Debugging-Tools, die man am PC laufen lassen kann, wenn man das Mobilgerät damit verbindet. Nur für den Stockbrowser, der ja die meisten Probleme macht, hilft das leider nicht viel. Und ob da noch was kommt, was sich für sinnvolles Debugging einsetzen lässt... Weiß ja nicht. Bin ich mal gespannt. Wenn sie der Chrome-Philosophie folgen würden bräuchtest du aber dafür auch erstmal ein Gerät mit besagtem Stock-Browser. > Aber die Sache mit "unter der Tastatur" ist natürlich ärgerlich. Mein Denkkonzept dabei ist folgendes: > > ~~~ ascii > +---------------------------------------+ > | dialog {position:fixed;top:0;left:0;} | > | | > | +-----------------------------+ | > | | div {margin:25% auto;} | | > | | | | > ~~~ Richtig - verstehe ich und ist auch das, was bei mir im Hochformat tatsächlich passiert. > Dadurch, dass es die Tastatur über die Anzeigefläche legt, wird im Browser einiges verschoben. Was da genau passiert, verstehe ich noch nicht. Inwiefern ich mein <div> in den noch sichtbaren Bereich bekomme, habe ich auch noch nicht verstanden. Anstatt mit `margin:25% auto;`{: .language-css} habe ich schon mit anderen Werten experimentiert. Aber wenn "überbreite" Elemente auf der Seite sind, die ein Scrollen der gesamten Seite nach rechts ermöglichen, dann ist "die Mitte" eben auch "weiter rechts", weshalb es mir das Dialogfeld nach links verschiebt, denn für `position:fixed;`{: .language-css} ist die Mitte eben nur das gerade sichtbare Feld, und das beginnt immer ganz am linken Seitenrand, für die Tastatureingabe wird aber offensichtlich zur "echten" Seitenmitte hin gescrollt. o_O Siehe meine Anmerkungen oben. Falls meine abgespacete Theorie zutrifft wäre `margin` schuld. Versuch doch mal temporär, das ohne margin zu lösen. Nimm der Dialog-Box doch mal den margin weg und schenk dafür seinem parent ein padding. Oder mach die Dialog-Box auch zu einem `position:fixed`. Wobei. --- Äh. Ich glaube ich sehe jetzt das Problem hier bei mir. Verwend doch mal bitte keine Prozente, sondern `vh` für das margin nach oben. Der Bereich links und rechts über meiner Dialogbox sieht verdächtig quadratisch aus. Das erklärt, warum es im Hochformat klappt (Seitenbreite < Seitenhöhe) und im Querformat nicht mehr. Grüße, RIDER -- Camping_RIDER a.k.a. Riders Flame a.k.a. Janosch Zoller # [Twitter](https://twitter.com/Camping_RIDER) # [Steam](http://steamcommunity.com/id/Camping_RIDER) # [YouTube](https://www.youtube.com/user/RidersFlame) # [Self-Wiki](http://wiki.selfhtml.org/wiki/Benutzer:Camping_RIDER) # [Selfcode](http://community.de.selfhtml.org/fanprojekte/selfcode.htm): sh:) fo:) ch:| rl:) br:^ n4:? ie:% mo:| va:) js:) de:> zu:} fl:( ss:) ls:[