Browser diverso comportamento di rendering con diversa posizione di script e tag di collegamento

Question

Sto cercando di capire quando esattamente l'HTML viene visualizzato sullo schermo nel browser.

ho letto this S.O. risposta e provato alcuni casi d'uso e ho osservato qualcosa che non rientra nel modello condiviso nel link,
anche io non può sembrare trovare una mente modello coerente per l'osservazione.

Qual è l'ordine di rendering del browser che si adatta ai casi discussi?

---

Caso A:Immagine-A

1. Quando parser HTML raggiunge M1, viene visualizzato M1.
2. Quindi il parser raggiunge il tag di script attende il file js da scaricare e analizzato.
3. Quindi il parser raggiunge M3, viene visualizzato M3.

Caso A è in-coerenza con l'ordine descritto sulla maggior parte delle risposte. Huray !!! Andiamo avanti.

Caso B:Immagine-B

1. parser HTML raggiunge M1, M1 non viene visualizzato come nel caso un
2. parser HTML raggiunge collegamento tag, attendere per i CSS da scaricare e parser.
3. M1 e M2 sono visualizzati, quindi ha aspettato il download del foglio di stile prima di visualizzare M1.
4. Quindi il parser raggiunge il tag di script attende il file js da scaricare e analizzato.
5. Quindi il parser raggiunge M3, viene visualizzato M3.

Quindi Case-B mostra che non ha eseguito il rendering della M1, ha aspettato il download del CSS prima di renderlo. Quindi forse il renderer deve conoscere il CSS prima del rendering.

Caso: CImmagine C

Così da Case B, si presume che possa essere il rendering-er ha bisogno di sapere CSS. sguardo
Let a causa C:

1. parser HTML raggiunge M1, viene visualizzato M1. Non dovrebbe essere stato visualizzato poiché, come abbiamo visto nel caso B, dovrebbe aspettare che css carichi.
2. Ora il parser raggiunge lo script, attende il download e il parser di js.
3. vengono visualizzati M2, M3

---

Edit: Proposto mente modello che spiega il comportamento sopra .. (ma richiedono una revisione/affinamento)

1. Script non è un tag di blocco del rendering
2. link è un tag di blocco del rendering
3. Considerando che il renderizzatore e parser HTML sono due thread.
4. Il parser HTML può inviare informazioni al renderer per il rendering.
5. Il parser HTML può inviare un segnale di blocco al renderer ... per bloccare il renderer per rendere qualsiasi html che non è stato reso almeno una volta.
6. Il parser HTML può inviare un segnale di sblocco al renderer per sbloccare il renderer dal rendering di qualsiasi html che non è stato visualizzato una sola volta.

Con il modello di cui sopra può spiegare CASO B e C:
CASO B Spiegazione:

1. parser HTML raggiunge M1, M1 è inviare al renderer.
2. Il parser HTML raggiunge il tag di collegamento, il parser invia un segnale di blocco al programma di rendering.
3. Renderer prima che possa eseguire il rendering di M1, ha ricevuto un segnale di blocco e quindi M1 non viene visualizzato.
4. Il parser HTML completa l'analisi del tag di collegamento (download) e invia un segnale di sblocco al renderer, dopo aver ricevuto un segnale di sblocco rende la M1.
5. Il parser HTML raggiunge M2, M2 viene inviato al renderer.
6. Il parser HTML raggiunge il tag Script, poiché il tag di script non è un tag di blocco del renderer, il renderer è libero di eseguire il rendering di html.
7. Il parser HTML completa l'analisi del tag script (download).
8. Il parser HTML raggiunge M3, M3 viene inviato al renderer.

Analogamente, è possibile eseguire il funzionamento a secco CASE C e si adatta perfettamente al modello precedente.

Il mio modello è corretto o qualcosa di sbagliato?

Answer 1

Hai quasi ragione. Tranne che è più semplice - il renderer è passivo e non riceve "segnale di blocco". Non esegue il rendering (aggiorna la visualizzazione per riflettere dom tree) fino a quando qualcuno non glielo chiede.

1. tuo HTML non è valida - Non puoi mettere <link rel=...> nel corpo.(Living HTML 4.2.4)

2. come si imparano, foglio di stile è una risorsa render-blocking - si impedisce contenuto possa essere reso, in contrasto con lo script che sarà in pausa e il rendering del contenuto analizzata.

Ecco come io lo spiego subito:

Caso B: M1 - stylesheet - M2 - script - M3

1. browser ottiene il codice HTML. M1 entra nella struttura DOM. M1 non è ancora stato visualizzato, al renderer non è stato chiesto di lavorare.
2. fogli di stile. (in effetti impedisce M1 di rendering)
3. foglio di stile fatto. M1 è ancora non visualizzato. (altri due passaggi)
4. M2 entra nella struttura DOM. M1 e ​​M2 non sono ancora visualizzati.
5. lo script attiva un rendering, visualizzando quindi M1 e M2, quindi carica.
6. script fatto. Nulla cambia (per quanto riguarda questo caso).
7. M3 entra nell'albero DOM, non ancora visualizzato.
8. Il documento è terminato, la pagina è visualizzata, quindi M3 viene visualizzato.

Questi comportamenti sono intenzionali. C'era una volta, js era lento e gli script impiegavano molto tempo per essere eseguiti, mentre i fogli di stile erano (ed è ancora) importanti per nascondere gli elementi per impostazione predefinita. Il tempo può essere cambiato, ma è improbabile che questi comportamenti cambino.

causa C: M1 - script - M2 - link - M3

1. browser ottiene il codice HTML. M1 entra nella struttura DOM. M1 non è ancora visualizzato.
2. lo script attiva un rendering, quindi visualizza M1 e quindi carica.
3. script fatto. Non cambia nulla.
4. M2 immette l'albero DOM. Non è ancora visualizzato.
5. carichi di fogli di stile, bloccando in effetti M2.
6. foglio di stile fatto. M2 non è ancora visualizzato.
7. M3 entra nell'albero DOM, non ancora visualizzato.
8. Il documento è terminato, la pagina è visualizzata, M2 e M3 sono visualizzati.

Il processo di visualizzazione attuale, in termini di fili, è verycomplicated, e in un certo senso notevolmente varies dal browser. Ad esempio, DOM è notthreadsafe. Pensa a cosa significa.

Per semplificare, è possibile immaginare l'elaborazione del browser come i dati e gli eventi che scorrono tra i vari moduli. Ecco alcuni Firefox sottosistemi di rendering: