Perché i tag di script auto-chiudenti non funzionano?

Qual è la ragione per cui i browser non riconoscono correttamente:

  

Solo questo è riconosciuto:

  

Questo rompe il concetto di supporto XHTML?

Nota: questa affermazione è corretta almeno per tutto IE (6-8 beta 2).

Solutions Collecting From Web of "Perché i tag di script auto-chiudenti non funzionano?"

Le specifiche XHTML 1 dicono:

С.3. Minimizzazione degli elementi e contenuto degli elementi vuoto

Data un’istanza vuota di un elemento il cui modello di contenuto non è EMPTY (ad esempio, un titolo o paragrafo vuoto) non usa il formato ridotto (ad esempio, usa

e non

).

La DTD XHTML specifica i tag di script come:

  < !ELEMENT script (#PCDATA)> 

Per aggiungere a ciò che Brad e Squadette hanno detto, la syntax XML autochiudente realtà è XML corretto, ma per farlo funzionare in pratica, il tuo server web ha anche bisogno di inviare i tuoi documenti come XML correttamente formato con un mimetype XML come application/xhtml+xml nell'intestazione Content-Type HTTP (e non come text/html ).

Tuttavia, l'invio di un mimetype XML farà sì che le pagine non vengano analizzate da IE7, a cui piace solo text/html .

Da w3 :

In sintesi, 'applicazione / xhtml + xml' DOVREBBE essere usato per i documenti della famiglia XHTML, e l'uso di 'text / html' DOVREBBE essere limitato ai documenti XHTML 1.0 compatibili con HTML. È ansible utilizzare anche 'application / xml' e 'text / xml', ma ogniqualvolta sia appropriato, 'application / xhtml + xml' DOVREBBE essere usato piuttosto che quei tipi di media XML generici.

Mi sono interrogato su questo problema alcuni mesi fa e l'unica soluzione praticabile (compatibile con FF3 + e IE7) consisteva nell'usare la vecchia syntax con text/html (syntax HTML + mimetype HTML).

Se il tuo server invia il tipo text/html nelle intestazioni HTTP, anche con documenti XHTML altrimenti correttamente formati, FF3 + utilizzerà la sua modalità di rendering HTML, il che significa che non funzionerà (questa è una modifica, in precedenza Firefox era meno rigido ).

Ciò avverrà indipendentemente da qualsiasi manipolazione con meta tag http-equiv , il prologo XML o doctype all'interno del documento - rami di Firefox una volta che ottiene l'intestazione text/html , che determina se il parser HTML o XML appare all'interno del documento e Il parser HTML non capisce .

Nel caso in cui qualcuno fosse curioso, la ragione ultima è che HTML era originariamente un dialetto di SGML, che è il fratello più strano di XML. In SGML-land, i tag possono essere specificati nella DTD come self-closing (es. BR, HR, INPUT), implicitamente richiudibili (ad es. P, LI, TD) o esplicitamente richiudibili (ad es. TABLE, DIV, SCRIPT). XML ovviamente non ha alcun concetto di questo.

I parser tag-zuppa utilizzati dai browser moderni si sono evoluti fuori da questa eredità, sebbene il loro modello di analisi non sia più SGML puro. E naturalmente il tuo XHTML accuratamente elaborato viene trattato come una zuppa di tag ispirata a SGML scritta male a meno che non la invii con un tipo di mime XML. Questo è anche il motivo per cui …

 

hello

… viene interpretato dal browser come:

 

hello

… che è la ricetta per un bizzarro bug oscuro che può farti mettere in crisi mentre provi a codificare contro il DOM.

Altri hanno risposto “come” e citato spec. Ecco la vera storia di “why no “, dopo molte ore di ricerca di bug report e mailing list.


HTML 4

HTML 4 è ​​basato su SGML .

SGML ha alcuni sottotitoli , come
text , , o

    item

. XML prende la prima forma, ridefinisce il finale come ">" (SGML è flessibile), in modo che diventi
.

Tuttavia, HTML non ha ridefinito il valore, quindi dovrebbe significare .
(Sì, il '>' dovrebbe essere parte del contenuto e il tag non è ancora chiuso).

Ovviamente, questo è incompatibile con XHTML e interromperà molti siti (nel momento in cui i browser sono stati abbastanza maturi da preoccuparsene ), quindi nessuno ha implementato i tag e le specifiche sconsigliano loro .

In effetti, tutti i tag "funzionanti" auto-terminati sono tag con tag di fine opzionale su parser tecnicamente non conformi e di fatto non sono validi. È stato W3C a creare questo hack per aiutare a passare a XHTML rendendolo compatibile con HTML .

E il tag di chiusura di non è opzionale .

Il tag "self-ending" è un hack in HTML 4 e non ha senso.


HTML 5

HTML5 ha cinque tipi di tag e solo i tag "void" e "foreign" possono essere chiusi automaticamente .

Poiché non è vuoto ( potrebbe avere contenuto) e non è estraneo (come MathML o SVG), non può essere auto-chiuso, indipendentemente da come lo si utilizza.

Ma perché? Non possono considerarlo estraneo, creare casi speciali o qualcosa del genere?

HTML 5 mira ad essere compatibile con le versioni precedenti di HTML 4 e XHTML 1. Non è basato su SGML o XML; la sua syntax riguarda principalmente la documentazione e l'unione delle implementazioni. (Questo è il motivo per cui


ecc. Sono HTML 5 valido nonostante sia un HTML4 non valido.)

Lo si chiude automaticamente è uno dei tag in cui le implementazioni utilizzate differiscono. Funzionava in Chrome, Safari e Opera ; a mia conoscenza non ha mai funzionato in Internet Explorer o Firefox.

Questo è stato discusso quando HTML 5 era in fase di elaborazione e è stato rifiutato perché interrompe la compatibilità del browser . Pagine Web che tag di script auto-chiudibili potrebbero non essere visualizzati correttamente (se non del tutto) nei vecchi browser. C'erano altre proposte , ma non possono nemmeno risolvere il problema di compatibilità.

Dopo che la bozza è stata rilasciata, WebKit ha aggiornato il parser per essere in conformità.

Lo che si chiude automaticamente non si verifica in HTML 5 a causa della retrocompatibilità con HTML 4 e XHTML 1.


XHTML 1 / XHTML 5

Quando è realmente servito come XHTML, è veramente chiuso, come hanno affermato altre risposte .

Tranne che la specifica dice che avrebbe dovuto funzionare quando è servito come HTML:

Documenti XHTML ... possono essere etichettati con il tipo di supporto Internet "text / html" [RFC2854], in quanto sono compatibili con la maggior parte dei browser HTML.

Allora, cos'è successo?

Le persone hanno chiesto a Mozilla di consentire a Firefox di analizzare documenti conformi come XHTML indipendentemente dall'intestazione del contenuto specificata (nota come sniffing del contenuto ). Ciò avrebbe consentito la scrittura di script autochiudenti e lo sniffing del contenuto era comunque necessario perché gli host web non erano abbastanza maturi per servire l'intestazione corretta; IE era bravo a farlo .

Se la prima guerra del browser non si è conclusa con IE 6, anche XHTML potrebbe essere stato nella lista. Ma è finita. E IE 6 ha un problema con XHTML. In effetti, IE non supportava affatto il tipo MIME corretto, costringendo tutti a utilizzare text/html per XHTML perché IE aveva una quota di mercato maggiore per un intero decennio.

E anche il contenuto sniffing può essere davvero pessimo e la gente dice che dovrebbe essere fermato .

Infine, si scopre che il W3C non significa che XHTML sia sniffabile : il documento è sia HTML che XHTML e regole di Content-Type . Si può dire che erano fermi su "basta seguire le nostre specifiche" e ignorare ciò che era pratico . Un errore che è continuato nelle versioni successive di XHTML.

Comunque, questa decisione risolse la questione per Firefox. Erano passati 7 anni dalla nascita di Chrome; non c'era nessun altro browser significativo. Così è stato deciso.

La specifica del doctype da solo non triggers l'analisi XML a causa delle seguenti specifiche.

Internet Explorer 8 e versioni precedenti non supportano l’analisi XHTML. Anche se si utilizza una dichiarazione XML e / o un doctype XHTML, il vecchio IE analizza ancora il documento come semplice HTML. E in semplice HTML, la syntax che si chiude automaticamente non è supportata. La barra finale viene semplicemente ignorata, devi usare un tag di chiusura esplicito.

Persino i browser con supporto per l’analisi XHTML, come IE 9 e versioni successive , analizzeranno il documento come HTML, a meno che non si serva il documento con un tipo di contenuto XML. Ma in quel caso il vecchio IE non mostrerà affatto il documento!

Le persone sopra hanno già spiegato il problema, ma una cosa che potrebbe chiarire le cose è che, sebbene la gente usi '<br/>' e tale tutto il tempo nei documenti HTML , qualsiasi '/' in tale posizione sia fondamentalmente ignorato, e usato solo quando si cerca di rendere qualcosa sia analizzabile come XML e HTML . Prova '<p/>foo</p>' , per esempio, e ottieni un paragrafo regolare.

Il tag script autochiudente non funzionerà, perché il tag script può contenere codice inline e HTML non è abbastanza intelligente da triggersre o distriggersre tale funzionalità in base alla presenza di un attributo.

D’altra parte, HTML ha un tag eccellente per includere riferimenti a risorse esterne: il tag e può essere chiuso automaticamente. È già utilizzato per includere fogli di stile, feed RSS e Atom, URI canonici e tutti i tipi di altri gadget. Perché non JavaScript?

Se vuoi che il tag script sia auto-allegato non puoi farlo come ho detto, ma c’è un’alternativa, sebbene non intelligente. Puoi utilizzare il tag di collegamento autochiudente e collegarlo al tuo JavaScript dandogli un tipo di testo / javascript e rel come script, qualcosa di simile di seguito:

  

A differenza di XML e XHTML, HTML non ha alcuna conoscenza della syntax che si chiude automaticamente. I browser che interpretano XHTML come HTML non sanno che il carattere / indica che il tag dovrebbe essere a chiusura automatica; invece lo interpretano come un attributo vuoto e il parser pensa ancora che il tag sia ‘aperto’.

Proprio come viene trattato come , viene trattato come .

Internet Explorer 8 e versioni precedenti non supportano il tipo MIME corretto per XHTML, application/xhtml+xml . Se stai servendo XHTML come text/html , che devi fare per queste vecchie versioni di Internet Explorer per fare qualcosa, sarà interpretato come HTML 4.01. Puoi utilizzare solo la syntax breve con qualsiasi elemento che permetta di omettere il tag di chiusura. Vedi la specifica HTML 4.01 .

Il “modulo breve” XML è interpretato come un attributo denominato /, che (poiché non esiste un segno di uguale) viene interpretato come avente un valore implicito di “/”. Questo è assolutamente sbagliato in HTML 4.01 – gli attributi non dichiarati non sono consentiti – ma i browser lo ignoreranno.

IE9 e versioni successive supportano XHTML 5 servito con application/xhtml+xml .

La differenza tra “vero XHTML”, “faux XHTML” e HTML così come l’importanza del tipo MIME inviato dal server era già stata descritta bene . Se vuoi provarlo subito, ecco un semplice frammento modificabile con anteprima dal vivo che include tag script auto-chiusi per browser abilitati:

 div { display: flex; } div + div {flex-direction: column; } 
 
Mime type:

Questo perché SCRIPT TAG non è un ELEMENTO VUOTO.

In un documento HTML – ELEMENTI VUOTI non hanno bisogno di un “tag di chiusura”!

In xhtml , tutto è generico, quindi tutti hanno bisogno di una terminazione, ad esempio un “tag di chiusura”; Includendo br, una semplice interruzione di riga, come in
o la sua stenografia
.

Tuttavia, uno Script Element non è mai un vuoto o un Elemento parametrico, perché il tag di script prima di ogni altra cosa, è una Istruzione del Browser, non una dichiarazione di Descrizione dei Dati.

Principalmente, un’istruzione di terminazione semantica, ad esempio, un “tag di chiusura” è necessario solo per le istruzioni di elaborazione che la semantica non può essere terminata da un tag successivo. Per esempio:

semantica

non può essere terminata da un seguente

perché non trasporta abbastanza della propria semantica da sovrascrivere e quindi termina il precedente set di istruzioni H1. Sebbene sia in grado di suddividere lo stream in una nuova riga di paragrafo, non è “abbastanza forte” da sovrascrivere la dimensione del carattere corrente e l’ altezza della linea di stile che scorre lungo lo stream , ovvero che perde da H1 (perché P non ce l’ha ).

Ecco come e perché è stata inventata la segnalazione “/” (terminazione).

Un termine generico senza descrizione Tag come < /> , sarebbe stato sufficiente per ogni singola caduta dalla cascata incontrata, ad esempio:

Title< />

ma non è sempre il caso, perché vogliamo anche essere in grado di “annidare” “, tagging multiplo multiplo del stream: diviso in torrent prima del wrapping / caduta su un’altra cascata. Di conseguenza un terminatore generico come < /> non sarebbe in grado di determinare il target di una proprietà da terminare. Ad esempio: grassetto grassetto-corsivo < /> corsivo normale. Indubbiamente non riuscirebbe a ottenere la nostra intenzione giusta e molto probabilmente la interpreteremmo come grassetto grassetto-itallico grassetto normale.

È così che è nata la nozione di un involucro, ad esempio. (Queste nozioni sono così simili che è imansible discernere e talvolta lo stesso elemento può avere entrambi.

è sia wrapper che contenitore allo stesso tempo. solo un wrapper semantico). Avremo bisogno di un contenitore semplice, senza semantica. E naturalmente è arrivata l’invenzione di un elemento DIV.

L’elemento DIV è in realtà un contenitore 2BR. Naturalmente l’avvento dei CSS ha reso l’intera situazione più strana di quanto sarebbe stata altrimenti e ha causato una grande confusione con molte grandi conseguenze – indirettamente!

Poiché con i CSS è ansible sovrascrivere facilmente il comportamento nativo pre e post BR di un DIV appena inventato, viene spesso definito come “non fare nulla contenitore”. Che è, naturalmente, sbagliato! I DIV sono elementi di blocco e interromperanno nativamente la linea del stream sia prima che dopo la segnalazione di fine. Presto il WEB cominciò a soffrire dalla pagina DIV-itis. Molti di loro lo sono ancora.

L’avvento dei CSS con la sua capacità di sovrascrivere completamente e ridefinire completamente il comportamento nativo di qualsiasi tag HTML, in qualche modo è riuscito a confondere e sfocare l’intero significato dell’esistenza HTML …

All’improvviso tutte le etichette HTML sono apparse come se fossero obsolete, erano state deturpate, spogliate di tutto il loro significato originale, id quadro e scopo. In qualche modo avresti l’impressione che non sono più necessari. Dicendo: un singolo tag contenitore-wrapper sarebbe sufficiente per tutta la presentazione dei dati. Basta aggiungere gli attributi richiesti. Perché non hanno invece tag significativi? Inventa i nomi dei tag mentre vai e lascia che i CSS si preoccupino del resto.

È così che è nato xhtml e, naturalmente, il grande schietto, pagato così caro dai nuovi arrivati ​​e una visione distorta di ciò che è, e qual è il dannato scopo di tutto questo. W3C è andato dal World Wide Web a What Went Wrong, compagni? !!

Lo scopo dell’HTML è di trasmettere dati significativi al destinatario umano.

Per fornire informazioni.

La parte formale è lì solo per aiutare la chiarezza della consegna delle informazioni. xhtml non dà la minima considerazione alle informazioni. – Ad esso, l’informazione è assolutamente irrilevante.

La cosa più importante è sapere ed essere in grado di capire che xhtml non è solo una versione di alcuni HTML estesi , xhtml è una bestia completamente diversa; motivi su; e quindi è saggio tenerli separati.