nicht angemeldet
Also lediglich kleine Komfort-Features, die bedenklos auch entfallen können.
Njein - sie sollten laufen...
Aber gerade diese "Frickellösungen" für zig Browser möchte ich vermeiden.
Dann frickle nicht, sondern nutze AJAX in den Browsern, in denen es geht - und lebe damit, dass ein paar Features von gegen Null gehender Wichtigkeit in anderen Browsern eben nichts zur Verfügung stehen.
... in allen Browsern mit _einer_ Lösung und nicht mit diesem "wenn das eine Objekt nicht da ist, dann nimm das andere oder mach sonst was und wenn du der xyz-Browser bist, mach dies und jenes". Gefällt mir einfach nicht :-(
Ich möchte eine Seite machen mit der möglichst viele Browser (zumindest alle aktuellen Versionen) umgehen können.
Mit AJAX umgehen können so gut wie alle aktuellen.
In in Firefox/Mozilla, Opera und Safari kann ich AJAX ebenso "abschalten", wie es im IE auch möglich ist. In diese Richtung weiter zu argumentieren, verschwendet also m.E. nur deine und unsere Zeit.
Mir ist gerade was klar geworden, als ich mir noch mal den Wikipedia-Artikel zu AJAX durchgelesen habe (http://de.wikipedia.org/wiki/Ajax_%28Programmierung%29#Der_Aufbau_einer_Ajax-Anwendung). Zur asyncronen Datenübertragung gibt es zwei Wege:
- per HTTPRequest
- per DOM
Da nur die DOM-Methode in allen Browsern problemlos läuft, brauche ich nach "Alternativen" gar nicht suchen, weil's gar keine anderen Möglichkeiten gibt - außer IFrame.
Die Kompabilität dürfte für die beschriebenen Einsatzszenarien vollkommen ausreichend sein.
Leider nein, denn...
Sinnloses Gebastel, um reichlich unelegant "Probleme" zu umschiffen, die bei objektiver Betrachtung eigentlich gar keine sind.
... das "sinnlose" Gebastel ist nötig, da auf unseren System Safari und der IE zu 100% unterstützt werden müssen und da kann ich als Entwickler nicht einfach sagen "wartet bis die Bugs behoben sind oder benutzt einen anderen Browser". Ich verstehe auch nicht ganz, was daran sinnlos sein soll. Wenn ich bedenke, dass ein HTTPRequest locker 20 Zeilen Code braucht und die DOM-Methode gerade mal 5 und auch im debuggen um einiges einfacher ist - zumindest jetzt beim Testen. Ich glaube unsere Diskussion ist etwas in die falsche Richtung gelaufen. Vielleicht sollte es besser "pro/contra HTTPRequest/DOM" heißen anstatt Alternativen...
Gruß
Daniel