Du bist nicht angemeldet (anmelden)
Seite 1
Safari und HTML5 & CSS3 & JS
Hat sonst schon jemand die «Erfahrung» gemacht, dass Safari bei extensivem Gebrauch von HTML5 & CSS3 und JS ins Stocken gerät und öfters mal abkackt? Ist da was bekannt, oder habe ich ein anderes Problem von dem ich nichts weiss?
Kann leider die Seite nicht zeigen, da sie noch «geheim» ist. Aber ich verwende zum Beispiel für die Navigation ein Rollover geräusch welches per <audio> eingebunden ist und per js ausgelöst wird und gleichzeiige Transition die den Background animieren. Habe jetzt den Doctype auf HTML gewechselt war vorher xhtml1-transitional und bis jetzt noch keine abstürze, aber das ist erst einige Minuten her.
Ah ja: Mootools 1.2
Edit: ok, hat nix gebracht, gerade hat er sich wieder aufgehängt.
Kann leider die Seite nicht zeigen, da sie noch «geheim» ist. Aber ich verwende zum Beispiel für die Navigation ein Rollover geräusch welches per <audio> eingebunden ist und per js ausgelöst wird und gleichzeiige Transition die den Background animieren. Habe jetzt den Doctype auf HTML gewechselt war vorher xhtml1-transitional und bis jetzt noch keine abstürze, aber das ist erst einige Minuten her.
Ah ja: Mootools 1.2
Edit: ok, hat nix gebracht, gerade hat er sich wieder aufgehängt.
ja. ist mir vor allem auch mit dem mobile safari aufgefallen. wobei der safari unter snow leopard stabiler ist als unter lion. das hängt wohl mit der internen speicherverwaltung zusammen.
dort muss man wirklich sauber entwickeln und zeugs was man hinzufügt, gerne mal wieder wegnehmen, bzw immer wiederkehrende sachen zwischencachen (und z.b. ins dom auslagern). eventuell dort auch mit webworkern bei intensiven berechnungsgeschichten arbeiten und z.b. in visibility:hidden containern injizieren um die danach z.b. an die entsprechend richtigen stellen zu clonen
dort muss man wirklich sauber entwickeln und zeugs was man hinzufügt, gerne mal wieder wegnehmen, bzw immer wiederkehrende sachen zwischencachen (und z.b. ins dom auslagern). eventuell dort auch mit webworkern bei intensiven berechnungsgeschichten arbeiten und z.b. in visibility:hidden containern injizieren um die danach z.b. an die entsprechend richtigen stellen zu clonen
Danke erstmal. Ich versteh zwar nur die Hälfte von dem was du schreibst. Aber so weiss ich schon mal in welche Richtung ich suchen kann/muss. Ist mein erstes Projekt mit HTML5 (wobei es mehr aus semantischen Überlegungen eingesetzt wird) und CSS3 (mal abgesehen von Schlagschatten und runden Ecken).
jau das hat weniger was mit html5 als mit javascript zu tun - safari hat einige speicherprobleme was a) animierte gifs b) bedingt durchs flash plugin flash c) exzessive javascript manipulation (und ajaxarbeiten die nicht sichtbar, aber im speicher stattfinden - z.b. du willst viele große bilder holen und vorladen lassen, ohne dass man sie sieht und sie auch nicht im dom hängen (also du z.b. nicht mit doc.getElementById zugreifen kannst)) - wenn das bei dir nicht der fall ist, kann es eine extension sein - gerade die machen den safari oftmals zu ner wackelkiste ... wenn du eigene extensions/plugins im safari hast, versuche die mal zu entfernen und damit zu testen - gerade unter lion arbeiten die meisten unter aller sau.
Yo, habe heute früh mal sämtliche Extensions deaktiviert. Evtl. muss ich sie auch löschen. Was ich grad eben bemerkt habe:
CSS3 Transitions fangen an zu «holpern» wenn man grosse Bilder (wir haben ein FullscreenBild im Hintergrund) hat, und beim schreiben faul war und der einfachheit halber
-webkit-transition: all 0.3s ease-out;
schreibt. Da ich in desem Fall nur background-position und color «animiert» habe, habe ich es jetzt für Safari ausgeschrieben, also:
-webkit-transition: background-position 0.3s ease-out, color 0.3s ease-out;
und siehe da, es läuft schon wieder fast so flüssig wie ohne das Fullscreenbild weil er wohl gezielt drauf zugreifen kann und nicht erst zu «vergleichen» braucht, was sich jetzt wohl geändert hätte.
CSS3 Transitions fangen an zu «holpern» wenn man grosse Bilder (wir haben ein FullscreenBild im Hintergrund) hat, und beim schreiben faul war und der einfachheit halber
-webkit-transition: all 0.3s ease-out;
schreibt. Da ich in desem Fall nur background-position und color «animiert» habe, habe ich es jetzt für Safari ausgeschrieben, also:
-webkit-transition: background-position 0.3s ease-out, color 0.3s ease-out;
und siehe da, es läuft schon wieder fast so flüssig wie ohne das Fullscreenbild weil er wohl gezielt drauf zugreifen kann und nicht erst zu «vergleichen» braucht, was sich jetzt wohl geändert hätte.
