Nur um das noch einmal öffentlich zu sagen: Es tat mir ja wirklich leid, daß die Besitzer von iPads und solchen Dingern darunter leiden, daß bei einem Drehen des Geräts sowohl das ganze Browserfenster selbst (durch das iDings) gedreht wird als auch dann noch einmal das Bild durch das Forum gedreht wird. Nur war das nicht mein Problem (mein Problem war, daß mich Leute deshalb nervten). Es ist schlicht und einfach ein undurchdachtes Verhalten von eurem iDings. Was da passiert, ist folgendes: Das iDings dreht das Fenster, und im nächsten Moment meldet dann der Browser an die Seite, daß das Gerät gedreht wurde. Nun ist mein MacBook wichtiger als eure iDinger. Ja, ich weiß, das sagt nichts Gutes über mich… aber egal. Das zugrundeliegende Problem ist, daß jemand nicht nachgedacht hat - oder vielleicht auch ganz viele Leute nicht nachgedacht haben. Man könnte so argumentieren, daß das die Leute waren, die die "DeviceOrientation Event Specification" geschrieben haben, denn die teilt der Anwendung im Browser nicht mit, daß der Browser selbst gedreht hat, aber die können sich damit herausreden, daß sich die Spezifikation ja nur mit dem Drehen der Hardware befaßt. Das wäre nicht hilfreich, aber richtig. Was es ganz frisch gibt ist eine Spezifikation einer Funktion, mit der man das automatische Drehen verhindern kann, aber die ist so neu, daß es die Funktion noch nirgends gibt - und darüber hinaus bringt die Spezifikation eher weiteres Chaos als Klarheit. Was es allerdings gibt ist eine Möglichkeit, Höhe und Breite von Bildschirm oder Fenster abzufragen. Die Bildschirmbreite zu aktualisieren hat Apple ausgerechnet beim Drehen des Browserfenster vergessen, also bleibt nur die Fenstergröße (window.innerWidth und so solche Sachen), aber die ist in der Praxis eben doch nicht nutzbar, weil sie auf einigen Tablets (diesmal nicht Apple) zu irgendeinem absolut unlogischen Zeitpunkt aktualisiert werden (nämlich mitten in einer Flut von deviceorientation-Event, die selbst völlig überflüssig ist), und weil man sich ganz generell nicht darauf verlassen kann, das innerWidth/Height irgendeine Beziehung zur Orientierung des Geräts haben, wenn irgendwelche iframes oder andere Schweinereien am Werk sind. Und damit bleibt nur noch ein Weg, nämlich daß die Browser, die selbst den Bildschirm drehen, darauf verzichten, der Anwendung irgendwelche halbvollständigen Informationen zu geben - wie auch immer, ob sie auf den deviceorientation-Kram ganz verzichten, oder das einstellbar machen, oder vielleicht auch mal vollständige Informationen liefern (damit meine ich Apple). Das alles fand ich schon vor über einem Jahr unbefriedigend, und hab' mich dann im Laufe der Zeit mit ein paar der Hersteller in Verbindung gesetzt. Das ist im Allgemeinen vergebene Liebesmüh, außer wenn man Floskeln steht (a la 'Thank you for bringing this to our attention.' gefolgt von der üblichen Lüge, daß man sich bei mir melden würde - ich meine damit insbesondere die Firma, die die große Suchmaschine betreibt). Zitat: case of didn't think, didn't care, didn't ask, didn't even stop to test. maybe it was a flashy new feature for ios 4.something. but i think it wasn't just as important as the color of icons, and, for all it's worth, in our house testing never was as important as implementing anything new and shiny. new, you see, as in 'something absolutely untested we implement mostly to inflict pain in our userbase'. well, that's not really and totally true, but sometimes it feels that way. right now some people start to think, no, sorry, start to begin to think, and just last week someone even noticed that the situation is all fucked up wrt deviceorientation (that maps use case). hey, somebody even noticed that we should have swapped screen.width and screen.height as soon as we changed the browsers orientation, but i wouldn't bet on that being implemented, because changing that now might open another can of compatibility worms, and possibly a really big one - nobody knows how big until we try it, and really, i wouldn't. in the not so far future i expect to see a lot of border case problems or problems falling right between two specs in the bright new world of html5. html5, a thousand independent extensions on top of something one might describe as a big company battlefield (and that was a very friendly wording, reality is far worse). what could go wrong? it already worked once before in the beautiful world of tcp/ip, and everything there is just perfect, well, with the possible exceptions of network routing protocols and their implementations, the tls shit, the dns shit and that oh so fast migration to v6. don't get me started on multicast or 'security'. you should also take note of the addresses of the editors of that spec. they contain that bad word, that tastes like android, pure shit. it's google i mean. we'd need to cooperate with them, and for me it looks like that decision might be far above the paygrade of the few people who care, though i'm not an insider on that, you see? i suppose you could try to get the spec changed, though i don't think somebody will listen to you in that case, this smells so much like politics, and it will not help you anyway, as specs don't directly change ios. guess you'll have to wait just a few years. besides, there is another little problem wrt this: you shouldn't trust window.orientation or the window and screen sizes to be updated before the event. that might change, iiuc. let me put another way, it makes sense to first send the event, and 0.5 seconds later change browser window, for to avoid useless redraws. but also makes sense to do it the other way - hard to say what is the best thing here. and in any case, it's hard to say when the resize event is to be sent. the resize event is an animal like a bug - nobody knows what it's good for, i mean, and it should be killed very fast. but it looks like a number of pages and apps are really using it, although this thing is even worse specified than most other javascript shit. every fucking idiot who ever touched that whole stuff (media queries, onresize, ondeviceorientation, and window.orientation) did his best to create a mess, and judging from the current state of things they were really damned good at that. Let's hope they rot in hell - or guantanamo, if there is a difference at all. that's screwed up beyond repair now, i think. can't think of any good way to fix this. can't even think of a good way to work around the worst bugs. Der Mann wußte offenbar noch nichts von der Screen Orientation API, die nun der Zahl der verschiedenen Werte, die "orientation" im Umfeld von Javascript und CSS einnehmen kann (0, 90, 180, -90, landscape, portait) noch vier Weitere zufügte, deren Sinn ich zumindest nicht auf Anhieb erkennen kann (portrait-primary, portrait-secondary, landscape-primary, landscape-secondary). Ich hab's heute aufgegeben, und automatische Bilddrehen ausschaltbar gemacht (Kontextmenü, gilt für alle Bilder, wenn der Browser mich das Flag speichern läßt). Wer es auch immer gewesen ist, der mir dafür 25€ schicken wollte, darf das jetzt tun. Falls er es nicht vergessen hat - ich hab' seinen Namen auch vergessen, ich kann's ihm also nicht mal übel nehmen Gruß, Uwe |
Hier war ein gelöschtes oder deaktiviertes, oder für Sie unlesbares Objekt.
Hi Uwe
Cool!
Android (Samsungtablett) mag das nun auch lieber .
Ich sage 'Danke' für deine Arbeit!
vg - Markus
Hier war ein gelöschtes oder deaktiviertes, oder für Sie unlesbares Objekt.
Hallo Uwe, auch wenn ich nur selten zum ipad greife, war dieses komische Drehen ein echtes Ärgernis! Klasse, dass Du eine Lösung gefunden hast! Vielen Dank dafür und Grüße, Jörg
Hier war ein gelöschtes oder deaktiviertes, oder für Sie unlesbares Objekt.
Hallo Uwe,
Bei den dich nervenden Leuten war ich dabei, das mit den 25 Euro war ich nicht und von dem was du geschrieben hast versteh ich irgendwie nicht mal die Hälfte. Aber was immer du gemacht hast, am iPad und am iPhone funktioniert es jetzt ohne die Bilddrehung sobald man das Teil in leichte Schräglage bringt.
Ich sag mal Danke, ich hoffe das ist auch ohne 25 Euro ok.
Vg
Ines