W dniu 2010-02-22 22:33, porneL pisze:
> On Mon, 22 Feb 2010 13:33:03 -0000, Peter May <p...@p...fm> wrote:
>
>>>> Gdzieś kiedyś czytałem, że zawartość wysłana z serwera jako text/html
>>>> jest przeglądarkę obrabiana dwukrotnie: parsowanie, potem renderowanie.
>>>
>>> Ale renderowanie na podstawie sparsowanego.
>>
>> Parsowanie zawartości wysłanej jako text/html właśnie mogę sobie
>> wyobrażać tak. Choćby w celu możliwie jak najlepszego poprawienia
>> błędnego kodu. Przeglądarka próbuje coś tam naprawić i potem to
>> wyświetlić.
>>
>> Natomiast w trybie xml-owym nawet najmniejszy błąd w składni daje po
>> prostu błąd i przerwę w renderowaniu dokumentu.
>>
>> No i szukam jakieś potwierdzenia lub zaprzeczenia tej tezy.
>
> W obu przypadkach kod jest pobierany raz, parsowany do DOM, a potem na
> podstawie DOM (kiedy to już nie ma śladu po źródle i różnicach
> składniowych) renderowany tyle razy ile trzeba.
>
> W starych Gecko była niedoróbka, która uniemożliwiała wyświetlanie
> progresywne, więc było mniej renderowania, kosztem opóźnienia w
> wyświetlaniu strony. We współczesnych Geckonach text/html i XML są
> traktowane prawie tak samo.
>
> Duże różnice w text/html vs XML to poplątanie parsera z silnikiem
> JavaScript. W trybie XML skrypty nie blokują parsera. W text/html
> działanie document.write jest zależne od aktualnego stanu parsera, przez
> co parser jest zależny od skryptów i musi wstrzymywać parsowanie strony
> przy każdym napotkanym skrypcie (jeśli skrypt jest zewnętrzny, to
> wszystko staje dęba póki skrypt się nie ściągnie i nie skończy wykonywać).

Co znaczy "W trybie XML skrypty nie blokują parsera"? Jeśli ładowane są
skrypty po kolei, to każdy wykonuje się zaraz po załadowaniu? A co z
tzw. blokowaniem ładowania się skryptów? Chodzi mi o sytuację, kiedy
przeglądarka ładuje skrypt->wykonuje go i tak do następnego.

Blokowanie skryptów, a w zasadzie ich ładowania, można pominąć m.in.
przez dynamiczne ich dodawanie. Jest, z resztą, wiele sposobów.

> Niektóre przeglądarki (Safari 4, IE8, Fx 3.6) podczas czekania na skrypt
> z sieci parsują stronę drugi raz (bez skryptów), żeby odkryć i zacząć
> ładować wszystkie skrypty i obrazki dalej w dokumencie.
>
> Text/html może być parsowany prawie-dwukrotnie w bardzo szczególnym
> przypadku - gdy zapomnisz zamknąć <script>, <textarea> lub komentarz.
> Wtedy przeglądarka dojdzie do końca dokumentu, kapnie się, że
> niedomknięty tag "pożarł" cały dokument, poprawi go i zacznie jeszcze raz.

> Natomiast w walidującym się text/html nie dochodzi do poprawiania
> błędów, więc nie ponosi się tego kosztów.

Dziękuję. To wiele wyjaśnia.

--
Peter