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

do góry

Użytkownik "Peter May" <p...@p...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?

do góry

Użytkownik "Peter May" <p...@p...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.

do góry

W dniu 2010-02-22 14:29, Ghost pisze:
>
> Użytkownik "Peter May" <p...@p...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

do góry

W dniu 2010-02-22 14:28, Ghost pisze:
>
> Użytkownik "Peter May" <p...@p...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/Mozilla_Web_Develop
er_FAQ#How_is_the_treatment_of_application.2fxhtml.2
bxml_documents_different_from_the_treatment_of_text.
2fhtml_documents.3f

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

--
Peter

do góry

Użytkownik "Peter May" <p...@p...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" <p...@p...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/Mozilla_Web_Develop
er_FAQ#How_is_the_treatment_of_application.2fxhtml.2
bxml_documents_different_from_the_treatment_of_text.
2fhtml_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.

do góry

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

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");

do góry

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

do góry

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.

do góry

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/2009/04/27/loading-
scripts-without-blocking/

--
Peter

do góry