Progresywne wyświetlanie kodu generowanego javascript'em

[yoyo]

Silnik Gecko wyświetla zawartość strony strumieniowo, jednak wyjątek stanowi kod generowany javascript'em przez document.write(), jeśli to on dawkuje zawartość strony.

Spójrzcie na przykład: http://3stat.pl/document-write_progress_test.html

Porówniajcie z IE i Opera, które wyświetlają ten kod stopniowo.

Czemu jest to aż tak istotne dla mnie - tworzę serwis, w którym kluczową rolę odgrywa wyświetlanie kodu przez document.write() i kiedy w IE i Operze, wyniki są widoczne natychmiast (bo są wyświetlane stopniowo) to w Mozilli muszę czekać do całkowitego wygenerowania kodu - co w moim przypadku oznacza nawet 20 sekund.

Jak rozwiązać ten problem, zależy mi żeby moziila rónież wyświetlała ten kod stopniowo.

PS: kod opóźniający jest wstawiony przykładowo, na mojej stronie mam czasem kilkaset takich wierszy i opóźnienie powodują dość spore obliczenia tego kodu. Ale powyższy przykład doskonale to emuluje.

PS2: uwaga: ta strona bardzo obciąża przeglądarkę.

[Domel]

Nie chcem tu sie ostatecznie wypowiadac bo nie jestem guru z js ale z ponktu widzenia (X)HTML-a to zeby byl efekt taki o jakim piszesz nalezy dodac atrybut defer a u Ciebie go nie ma. Dlatego w takim momencie Mozilla zachowuje sie prawidlowo.

[quiris]

Nie chcem tu sie ostatecznie wypowiadac bo nie jestem guru z js ale z ponktu widzenia (X)HTML-a to zeby byl efekt taki o jakim piszesz nalezy dodac atrybut defer a u Ciebie go nie ma. Dlatego w takim momencie Mozilla zachowuje sie prawidlowo.

Nie można użyć atrybutu defer, ponieważ skrypt ingeruje w zawartość strony: http://www.w3.org/TR/REC-html40/interac ... adef-defer

[Domel]

Nie można użyć atrybutu defer, ponieważ skrypt ingeruje w zawartość strony

No wlasnie o to chodzi dlatego IMHO nie mozna wyswietlac tego strumieniowo a co za tym idzie IE i Opera robia to niepoprawnie.

[quiris]

Nie można użyć atrybutu defer, ponieważ skrypt ingeruje w zawartość strony

No wlasnie o to chodzi dlatego IMHO nie mozna wyswietlac tego strumieniowo a co za tym idzie IE i Opera robia to niepoprawnie.

Hmm... nie przekonuje mnie Twoja argumentacja. Przecież atrybut defer nie może być tu rozważany, bo skrypt nie kwalifikuje się do użycia atrybutu defer. A to czy strona powinna się wyświetlać tak jak proponuje MSIE i Opera, czy tak jak Mozilla to jest zupełnie inna para kaloszy. Skrypty do których używa się atrybutu defer to są zwykle skrypty, które wysyłają zapytania do serwerów, ustawiają ciastka i inne rzeczy. Jest tylko jeden warunek, te skrypty nie mogą ingerować w wygląd strony. Dlatego nie możesz proponować użycie defer, bo defer nie ma nic do sposobu wizualnego ładowania strony.

[Domel]

Dlatego nie możesz proponować użycie defer, bo defer nie ma nic do sposobu wizualnego ładowania strony.

Oczywiscie, ze tak nawet mi to do glowy nie przeszlo. Chodzi o to, ze IMHO progresywne wyswietlanie powinno dotyczyc tylko atrybutu defer (wartosc true) a nie wartosci false.

[yoyo]

w takim razie co robić aby uzyskać progresywne ładowanie w mozilli?

[Użytkownik]

Nie znam się, ale czy to a tak wielka różnica?
1. Większość stron i tak tego nie ma
2. Dużo stron ładuje się tak szybko, że nie wiadomo, czy to Windołs się nad czymś zastanawia, czy co.

[yoyo]

Nie znam się, ale czy to a tak wielka różnica?
1. Większość stron i tak tego nie ma

Moja ma

2. Dużo stron ładuje się tak szybko, że nie wiadomo, czy to Windołs się nad czymś zastanawia, czy co.

ale to chyba nie jest rozwiązanie problemu. Czy to, że w Operze i IE zaczynam widzieć stronę po pół sekundy a w Mozilli po 20 jest dla ciebie argumentem, że to jest DUŻY problem?

[Użytkownik]

Dla mnie nie ma, ale 20 sekund to rzeczywiście dużo.

[Domel]

ale to chyba nie jest rozwiązanie problemu. Czy to, że w Operze i IE zaczynam widzieć stronę po pół sekundy a w Mozilli po 20 jest dla ciebie argumentem, że to jest DUŻY problem?

Ja tam nie chcem sie wtracac ale u mnie podana przez Ciebie strona wyswietlala sie jakies 0.5 sekundy na Mozilli i absolutnie niedluzej niz w Opere lub IE, nie wiem od czego to w takim wypadku to zalezy, moze od wielkosci RAM czy procka (chociaz nie mam mocnego sprzetu).

[Użytkownik]

ale to chyba nie jest rozwiązanie problemu. Czy to, że w Operze i IE zaczynam widzieć stronę po pół sekundy a w Mozilli po 20 jest dla ciebie argumentem, że to jest DUŻY problem?

Ja tam nie chcem sie wtracac ale u mnie podana przez Ciebie strona wyswietlala sie jakies 0.5 sekundy na Mozilli i absolutnie niedluzej niz w Opere lub IE, nie wiem od czego to w takim wypadku to zalezy, moze od wielkosci RAM czy procka (chociaz nie mam mocnego sprzetu).

Ja rozumiem, że ta strona to przykład, a on ma (ukrytą przed nami) stronę z troche większą ilością tego.

[Domel]

Ja rozumiem, że ta strona to przykład, a on ma (ukrytą przed nami) stronę z troche większą ilością tego.

To ja tez rozumiem ale nie rozumiem po co uzywac document.write skoro identyczny a nawet lepszy i wydajniejszy sposob to tradycyjny (X)HTML. Dla mnie to absurd, to tak jakby tekst zapisywac w obrazku i dziwic sie ze strona dluzej sie wczytuje .
A tak zupelnie na marginesie w XHTML 2 ktos zaproponowal "niedopuszczenie" document.write do XHTML 2 i coraz bardziej sie do tego przekonuje

[Gandalf]

No coz. Nie chce wywolywac kolejnej wojny, ale dla mnie, z punktu widzenia programisty zachowanie Mozilli jest jak najbardziej fair, a kazde inne zachowanie jest bledne.
Powod?
Przyklad Yoya mowi tak:
Droga przegladarko, wyswietl strone do ktorej wstawiam kod dynamiczny.
Naturalnym zachowaniem browsera powinno byc wyswietlanie gotowej strony, aby np. nie tracic czasu na przerysowywanie strony w trakcie budowania drzewa.
I browser tak robi, a to, ze w srodku sa jakies procesorozerne petle? No coz... autor tak chcial.
Z tego co rozumiem Opera i IE zatrzymujac sie na petli wyswietlaja to co maja dotychczas... Sadze, ze to nienajlepszy pomysl, ale w sumie winno to byc bez roznicy, bo problemem jest tak naprawde katorzniczy sposob jakim chce do celu dojsc autor.
Jezeli chcesz wstawiac kod po kolej to walnij cos w tym stylu:

<html>
<head>
var I=0;
var a=['ala','ma','kota']
var i=0;
function insertNode () {
document.write(a[i++]);
if (i==a.length) I=clearInterval(I);
}
function main () {
I=setInterval(insertNode,1000);
}
</head>
<body onload="main()">
</body>
</html>

- wowczas faktycznie chcesz, zeby skrypt co sekunde dostawial kolejne slowo - a nie zeby zarzynal procesor

[yoyo]

pokażę Wam o co chodzi dokładnie:

http://www.3stat.pl/moz_perf_test/index.html

porównajcie w IE Operze i Mozilli

A dlaczego wybrałem taką metodę? bo gdyby kod nie był generowany client-side to urósł by dokładnie do 1,2 Mb, a tak wysyłam tylko 130 kb do klienta, javascript po jego stronie odwala całą robotę (nie obciążając serwera) generując kod 10 razy większy, przy czym faktycznie jest to o wiele szybsze niż ściąganie 1,2 Mb przez większość modemów. Jedyny problem pojawia się w Mozilli, która nie wyświetla kodu stopniowo.

[Domel]

Nie przyjrzalem sie zbyt dokladnie bo troche tego kodu jest a i spac mi sie chce. Ale czy nie lepszym (bardziej odpowiednim) rozwiazaniembylo by PHP (lub jakies inny server-side) + male dodatki JS?

[Użytkownik]

Lepiej tego nie rób w 1.6a powoduje błąd programu. Zresztą wogle skrypty client-side są (moje własne zdanie) mało przydatne. Nadają się do np. dynamicznych przekierowań i sprawdzania poprawności danych w formularzu.

[quiris]

A tak zupelnie na marginesie w XHTML 2 ktos zaproponowal "niedopuszczenie" document.write do XHTML 2 i coraz bardziej sie do tego przekonuje

Może dlatego, to zrobił, że (o czym osobiście nie wiedziałem) część funkcji JavaScriptu nie jest zgodna z XML (w tym również document.write): http://groups.google.com/groups?selm=op ... .opera.com
Skoro XHTML dąży w w kierunku XML, to jest to zrozumiałe.
Niestety, nie udało mi się znaleźć szerszych informacji na ten temat.

[quiris]

Nie chce wywolywac kolejnej wojny, ale dla mnie, z punktu widzenia programisty zachowanie Mozilli jest jak najbardziej fair, a kazde inne zachowanie jest bledne.

Panowie, nie rozpatrujmy tego w abstrakcyjnych kategoriach fair or not fair. Dla Ciebie jest to działanie fair, ale dla yoyo raczej nie. Przecież on chciał uzyskać określony efekt, przy użyciu *dopuszczalnych* metod. To, czy przeglądarka będzie zarzynać procesor nie wydaje mi się istotnym zagadnieniem w kontekście podstawowego pytania:

Czy sposób działania Mozilli jest zachowaniem błędnym czy nie opierając, się tylko i wyłącznie na specyfikacji, w tym wypadku, ECMAScript?

Nie możemy rozpatrywać działania przeglądarek jako fair, czy nie fair, bo równie dobrze mógłbym dojść do wniosku, że poprawianie błędów webmasterskich przez przeglądarki jest działaniem fair, bo tego oczekiwał webmaster, że strona wyświetli mu się poprawnie.

Nie po to tworzy się niespotykane na co dzień testy typu http://www.hixie.ch/tests/evil/, żeby po obejrzeniu ich wyników zawyrokować, że no faktycznie coś nie bardzo wyszło, ale rozumiemy, przeglądarka chciała być fair!

Co oczywiście nie zmienia faktu, że Twoja propozycja skryptu jest bardziej optymalna

[Gandalf]

Yoyo: fajnie, taka wlasnie metody prezentacji danych tabelowych forsujemy od dwoch lat na pl.comp.lang.javascript, wiec jak najbardziej popieram Twoja metode, tylko nie w ten sposob.

Wstaw puste bloki. Dodaj skrypt zaczynajacy dzialac online i niech on dodaje kod. Wowczas przegladarki beda normalnie dzialac.