Parsowanie i renderowanie - ile razy

Parsowanie i renderowanie - ile razy

---

Peter May - 23-02-2010 19:28
Parsowanie i renderowanie - ile razy
  Gdzieś kiedyś czytałem, że zawartość wysłana z serwera jako text/html
jest przeglądarkę obrabiana dwukrotnie: parsowanie, potem renderowanie.

Natomiast w trybie xml-owym (np. application/xhtml+xml) tylko raz, czyli
od razu renderowanie, ponieważ to wynika z tego, że w trybie xml-owym
zakłada się, iż zawartość jest zawsze poprawna składniowo.

Niech ktoś podrzuci jakiś artykuł lub potwierdzi / zaprzeczy, że tak jest.

--
Peter

---

Ghost - 23-02-2010 19:28

 
Użytkownik "Peter May" <peter.may@poczta.fm> napisał w wiadomości
news:hlu0cs$igc$1@atlantis.news.neostrada.pl...
> Gdzieś kiedyś czytałem, że zawartość wysłana z serwera jako text/html jest
> przeglądarkę obrabiana dwukrotnie: parsowanie, potem renderowanie.
>
> Natomiast w trybie xml-owym (np. application/xhtml+xml) tylko raz, czyli
> od razu renderowanie, ponieważ to wynika z tego, że w trybie xml-owym
> zakłada się, iż zawartość jest zawsze poprawna składniowo.

I dzieki temu zalozeniu automagicznie przegladarka interpretuja zawartosc
xml?

---

Ghost - 23-02-2010 19:28

 
Użytkownik "Peter May" <peter.may@poczta.fm> napisał w wiadomości
news:hlu0cs$igc$1@atlantis.news.neostrada.pl...
> 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.

---

Peter May - 23-02-2010 19:28

  W dniu 2010-02-22 14:28, Ghost pisze:
>
> Użytkownik "Peter May" <peter.may@poczta.fm> napisał w wiadomości
> news:hlu0cs$igc$1@atlantis.news.neostrada.pl...
>> Gdzieś kiedyś czytałem, że zawartość wysłana z serwera jako text/html
>> jest przeglądarkę obrabiana dwukrotnie: parsowanie, potem renderowanie.
>>
>> Natomiast w trybie xml-owym (np. application/xhtml+xml) tylko raz,
>> czyli od razu renderowanie, ponieważ to wynika z tego, że w trybie
>> xml-owym zakłada się, iż zawartość jest zawsze poprawna składniowo.
>
> I dzieki temu zalozeniu automagicznie przegladarka interpretuja
> zawartosc xml?

Tu są szczegóły:

https://developer.mozilla.org/en/Moz...l_documents.3f

bo nie wiem, czy dobrze się rozumiemy. Mi tylko chodziło o sposób
renderowania zawartości.

--
Peter

---

Peter May - 23-02-2010 19:28

  W dniu 2010-02-22 14:29, Ghost pisze:
>
> Użytkownik "Peter May" <peter.may@poczta.fm> napisał w wiadomości
> news:hlu0cs$igc$1@atlantis.news.neostrada.pl...
>> 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.

--
Peter

---

Ghost - 23-02-2010 19:28

 
Użytkownik "Peter May" <peter.may@poczta.fm> napisał w wiadomości
news:hlu1ib$l6v$1@atlantis.news.neostrada.pl...
>W dniu 2010-02-22 14:28, Ghost pisze:
>>
>> Użytkownik "Peter May" <peter.may@poczta.fm> napisał w wiadomości
>> news:hlu0cs$igc$1@atlantis.news.neostrada.pl...
>>> Gdzieś kiedyś czytałem, że zawartość wysłana z serwera jako text/html
>>> jest przeglądarkę obrabiana dwukrotnie: parsowanie, potem renderowanie.
>>>
>>> Natomiast w trybie xml-owym (np. application/xhtml+xml) tylko raz,
>>> czyli od razu renderowanie, ponieważ to wynika z tego, że w trybie
>>> xml-owym zakłada się, iż zawartość jest zawsze poprawna składniowo.
>>
>> I dzieki temu zalozeniu automagicznie przegladarka interpretuja
>> zawartosc xml?
>
> Tu są szczegóły:
>
> https://developer.mozilla.org/en/Moz...l_documents.3f
>
> bo nie wiem, czy dobrze się rozumiemy. Mi tylko chodziło o sposób
> renderowania zawartości.

No ja tez nie wiem jaki jest zwiazek podanego linka z Twoim pierwotnym
pytaniem.

---

porneL - 23-02-2010 19:28

  On Mon, 22 Feb 2010 13:33:03 -0000, Peter May <peter.may@poczta.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ć).

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.

--
http://pornel.net
this.author = new Geek("porneL");

---

Peter May - 23-02-2010 19:28

  W dniu 2010-02-22 22:33, porneL pisze:
> On Mon, 22 Feb 2010 13:33:03 -0000, Peter May <peter.may@poczta.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

---

=?UTF-8?B?UGF3ZcWCIFBpc2tvcno=?= - 23-02-2010 19:28

  On 2010-02-23 12:38, Peter May wrote:
> Co znaczy "W trybie XML skrypty nie blokują parsera"?

To znaczy że parser nie musi czekać na załadowanie i wykonanie skryptu,
bo wie że w nim nie może być document.write które by mu coś zepsuło.

> Jeśli ładowane są
> skrypty po kolei, to każdy wykonuje się zaraz po załadowaniu?

Oj nie wiem, przypuszczam że tak, skoro psuć nic nie mogą ;]

> 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.

Podglądnij sobie na zakładce "Sieć" w Firebugu jak to wygląda.

---

Peter May - 23-02-2010 19:28

  W dniu 2010-02-23 14:05, Paweł Piskorz pisze:
> On 2010-02-23 12:38, Peter May wrote:
>> Co znaczy "W trybie XML skrypty nie blokują parsera"?
>
> To znaczy że parser nie musi czekać na załadowanie i wykonanie skryptu,
> bo wie że w nim nie może być document.write które by mu coś zepsuło.

No ale mogę to wziąć tylko na tzw. wiarę. Jakiś link do dokumentacji
albo specyfikacji? :P

>> Jeśli ładowane są
>> skrypty po kolei, to każdy wykonuje się zaraz po załadowaniu?
>
> Oj nie wiem, przypuszczam że tak, skoro psuć nic nie mogą ;]

Możliwe, że tak jest. ;-)

>> 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.
>
> Podglądnij sobie na zakładce "Sieć" w Firebugu jak to wygląda.

E, to wiem, jak to wygląda. Dość szeroko o tym pisał Steve Souders na
swoim blogu:

http://www.stevesouders.com/blog/200...hout-blocking/

--
Peter

---

=?UTF-8?B?UGF3ZcWCIFBpc2tvcno=?= - 23-02-2010 19:28

  On 2010-02-23 14:05, Paweł Piskorz wrote:
> On 2010-02-23 12:38, Peter May wrote:
>> Co znaczy "W trybie XML skrypty nie blokują parsera"?
>
> To znaczy że parser nie musi czekać na załadowanie i wykonanie skryptu,
> bo wie że w nim nie może być document.write które by mu coś zepsuło.

Czekaj, źle. Parser XMLa ma "przelecieć" dokument i zwrócić jego
strukturę i treść:
http://www.w3.org/TR/REC-xml/#sec-intro
[Definition: A software module called an XML processor is used to read
XML documents and provide access to their content and structure.]
[Definition: It is assumed that an XML processor is doing its work on
behalf of another module, called the application.]
Więc teoretycznie mu to <>< czy jest <script/> czy <transbulbulator/>,
bo to i tak nie jego działka (tak jak pisał porneL).

Ale z krótkiego testu jaki sobie zrobiłem wychodzi że parser Ff, Opery i
GChrome dla stron słanych jako application/xhtml+xml zachowuje się tak
samo jak dla text/html, tj. przerywa pracę gdy napotka na <script/> do
czasu załadowania skryptu, potem leci dalej z ładowaniem strony.

---

Peter May - 23-02-2010 19:28

  W dniu 2010-02-23 16:44, Paweł Piskorz pisze:
> On 2010-02-23 14:05, Paweł Piskorz wrote:
>> On 2010-02-23 12:38, Peter May wrote:
>>> Co znaczy "W trybie XML skrypty nie blokują parsera"?
>>
>> To znaczy że parser nie musi czekać na załadowanie i wykonanie skryptu,
>> bo wie że w nim nie może być document.write które by mu coś zepsuło.
>
> Czekaj, źle. Parser XMLa ma "przelecieć" dokument i zwrócić jego
> strukturę i treść:
> http://www.w3.org/TR/REC-xml/#sec-intro
> [Definition: A software module called an XML processor is used to read
> XML documents and provide access to their content and structure.]
> [Definition: It is assumed that an XML processor is doing its work on
> behalf of another module, called the application.]
> Więc teoretycznie mu to <>< czy jest <script/> czy <transbulbulator/>,
> bo to i tak nie jego działka (tak jak pisał porneL).
>
> Ale z krótkiego testu jaki sobie zrobiłem wychodzi że parser Ff, Opery i
> GChrome dla stron słanych jako application/xhtml+xml zachowuje się tak
> samo jak dla text/html, tj. przerywa pracę gdy napotka na <script/> do
> czasu załadowania skryptu, potem leci dalej z ładowaniem strony.

Tak właśnie zachowują się znane mi przeglądarki m.in. Opera, Firefox,
IE, Chrome, Safari, choć da się to ominąć. W innym poście dałem linka do
artykułu o tym jak ładować skrypty bez blokowania. Chociaż wszystkie
metody mają swoje wady a zwykłe <script> działa zawsze :-)

--
Peter

---

=?UTF-8?B?xYF1a2FzeiBMZWNo?= - 28-02-2010 15:58

  Peter May pisze:
> Natomiast w trybie xml-owym (np. application/xhtml+xml) tylko raz, czyli
> od razu renderowanie, ponieważ to wynika z tego, że w trybie xml-owym
> zakłada się, iż zawartość jest zawsze poprawna składniowo.
>
To była jakaś demagogia. A jak można założyć, że masz tryb xml-owy? I
tak wszystko trzeba sparsować. Niezależnie od tego, jakim słowem
określimy to sparsowanie.

--
Łukasz Lech
http://lechlukasz.wordpress.com - o górach, informatyce i nie tylko

zanotowane.pl

doc.pisz.pl

pdf.pisz.pl

anavar.pev.pl