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 schlägt das Forumsfeature zu, das Bilder drehen kann (mit der richtigen Hardware, dem richtigen Betriebssystem und entsprechendem Support durch den Browser… all das hat zum Beispiel das MacBook, auf dem ich gerade schreibe). Das Feature hat den Vorteil, daß man die Hochformatbilder darauf relativ bequem sehen kann...
Es hat den Nachteil, daß auf den iDingern eben doppelt gedreht wird, was etwas weniger als optimal ist.

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.
Man könnte auch argumentieren, daß es dafür einen ganz anderen Event geben müßte, der der Anwendung mitteilt, daß der Browser gedreht wurde.
Man könnte auch argumentieren, daß es einen Weg geben müßte, mit dem eine Anwendung feststellen könnte, daß der Browser dieses Verhalten überhaupt zeigen kann (dann könnte man in der Anwendung entsprechend reagieren).
Aber nichts davon gibt es.

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).
Darauf habe ich gewartet - oder zumindest darauf, daß mir mal jemand erklärt, wie sich die Browserhersteller das eigentlich vorstellen.


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).
Rein zufällig habe ich mittlerweile jemanden kennengelernt, der bei Apple in der Softwareentwicklung arbeitet (der möchte bestimmt nicht, daß das, was ich gleich zitiere, zu ihm zurück zu verfolgen ist, deshalb bleibe ich da sehr vage), und der hat in seiner Antwort die Situation wenigstens schön zusammengefaßt.

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.
may be soon other people on an upper level will discuss it, though i think they will decide to wait a long, long time until nobody has to decide anything anymore. well, that may even work, you know? happen's a lot these days, here and anywhere else, as long as some problem only hurts a few people.
otoh the current state of things might hurt a lot of people in the long run, but right now there is no pressure the fix things. especially as this seems to involve a lot of layer 8.

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'.
chaos never ever won against complex systems, right? guess you know that one big difference between tcp/ip and html5 is the amount money on the battlefield. money per definition only has short term goals, but long term consequences. what could go wrong?

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.
mozilla says resize event is to be sent after the window is resized, but what does that mean? obviously it should not mean that event is fired in case the orientation changes, if one takes the word size seriously, but that's what happens (at least on that machines i've heard about - there may be a few programmers left who might take a word by meaning).
then there is the not so funny fact that the resize event on ios is fired before the orientation change event, but the window.orientation flag is updated after the resize event, so that you can't use it on ios (and you shouldn't use it anyway, because window.orientation is even in even worse shape than the resize event - browsers, especially the handheld ones, of course, don't even agree what 0 and 90 means. i wouldn't really be surprised if some browsers started to count to pi.
and then the assholes who created the media queries made orientation a string value in css... no, they didn't try to fix the mess, but added to it.

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