it-swarm.it

Perché non si comportano automaticamente?

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

<script src="foobar.js" /> <!-- self-closing script element -->

Solo questo è riconosciuto:

<script src="foobar.js"></script>

Questo rompe il concetto di supporto XHTML?

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

1247
dimarzionist

La specifica XHTML 1 dice:

С.3. Riduzione degli elementi e contenuto dell'elemento 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 modulo ridotto a icona (ad esempio usa <p> </p> e non <p />).

XHTML DTD specifica gli elementi di script come:

<!-- script statements, which may include CDATA sections -->
<!ELEMENT script (#PCDATA)>
456
squadette

Per aggiungere a ciò che Brad e Squadette hanno detto, la sintassi XML auto-closing <script /> in realtà è corretta XML, ma per farlo funzionare nella pratica, il tuo server web deve anche inviare il tuo documenti come XML formato correttamente con un mimetype XML come application/xhtml+xml nell'intestazione Content-Type HTTP (e not 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. È possibile utilizzare anche 'application/xml' e 'text/xml', ma se 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 sintassi <script></script> con text/html (sintassi 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 <script /> non funzionerà (questa è una modifica, in precedenza Firefox era meno rigido).

Questo accadrà a prescindere da qualsiasi giochetto con meta elementi 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 guarda all'interno del documento, e il parser HTML non lo fa capire <script />.

225
joelhardi

Nel caso qualcuno sia curioso, la ragione ultima è che HTML era originariamente un dialetto di SGML, che è il fratello maggiore strano di XML. Nella terra SGML, gli elementi possono essere specificati nella DTD come a chiusura automatica (ad esempio BR, HR, INPUT), implicitamente richiudibili (ad esempio P, LI, TD) o esplicitamente richiudibili (ad esempio TABLE, DIV, SCRIPT). XML, naturalmente, non ha alcun concetto di questo.

I parser di tag-soup usati 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 ...

<p><div>hello</div></p>

... viene interpretato dal browser come:

<p></p><div>hello</div><p></p>

... che è la ricetta per un bizzarro bug oscuro che ti può buttare in attacchi mentre provi a codificare contro il DOM.

150
greim

Altri hanno risposto "come" e citato spec. Ecco la vera storia del "perché no <script/>", dopo molte ore di ricerca di bug report e mailing list.


HTML 4

HTML 4 è ​​basato su SGML .

SGML ha alcuni shorttag , come <BR//, <B>text</>, <B/text/ o <OL<LI>item</LI</OL>. XML prende il primo modulo, ridefinisce il finale come ">" (SGML è flessibile), in modo che diventi <BR/>.

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

Ovviamente, questo è incompatibile con XHTML e will interromperà molti siti (quando i browser sono abbastanza maturi per preoccuparsisu questo ), quindi nessuno ha implementato le shorttags e le specifiche consiglia contro di 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 che ha inventato questo hack per aiutare la transizione verso XHTML rendendolo compatibile con HTML .

E il tag di chiusura <script> è non opzionale .

Il tag "auto-finale" è un hack in HTML 4 e non ha significato.


HTML 5

HTML5 ha cinque tipi di tag e solo i tag 'void' e 'foreign' sono autorizzati ad essere auto-closing .

Poiché <script> non è vuoto (esso potrebbe avere contenuto e non è estraneo (come MathML o SVG), <script> non può essere chiuso automaticamente, indipendentemente da come lo si utilizza.

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

HTML 5 mira ad essere retro-compatibile con implementazioni di HTML 4 e XHTML 1. Non si basa su SGML o XML; la sua sintassi riguarda principalmente la documentazione e l'unione delle implementazioni. (Questo è il motivo per cui <br/><hr/> ecc. Sono HTML 5 valido nonostante sia un HTML4 non valido.)

<script> a chiusura automatica è uno dei tag in cui le implementazioni utilizzate differiscono. Esso utilizzato per funzionare 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 stesura e rifiutato perché interruzionibrowsercompatibilità . Le pagine Web con tag di chiusura automatica potrebbero non essere visualizzate correttamente (se non lo sono) 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à.

<script> a chiusura automatica 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, <script/> è veramente chiuso, come hanno risposto altre risposte .

Tranne che la specifica dice it dovrebbe avere funzionato quando è servito come HTML:

I documenti XHTML ... possono essere etichettati con l'Internet Media Type "text/html" [RFC2854], in quanto sono compatibili con la maggior parte dei browser HTML.

Allora, cos'è successo?

People ha chiesto a Mozilla a di lasciare analizzare i documenti conformi di Firefox come XHTML indipendentemente dall'intestazione del contenuto specificato (noto come content sniffing ). Ciò avrebbe consentito script autochiudenti e lo sniffing del contenuto era necessario in ogni caso 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 terminò con IE 6, XHTML potrebbe essere stato nella lista anche. Ma è finita. E IE 6 ha un problema con XHTML. Infatti IE non supportava il tipo MIME corretto affatto , forzando tutti a usare text/html per XHTML perché IE aveva una quota di mercato maggiore per un intero decennio.

E anche lo sniffing dei contenuti può esseredavvero pessimo e le persone dicono dovrebbe essere fermato .

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

Ad ogni modo, questa decisione risolve il problema per Firefox. Erano passati 7 anni prima che nascesse Chrome ; non c'era nessun altro browser significativo. Così è stato deciso.

Specificando solo il doctype non si attiva l'analisi XML a causa delle seguenti specifiche.

139
Sheepy

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 sintassi a chiusura automatica 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 visualizzerà affatto il documento!

44
JacquesB

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 viene sostanzialmente ignorato e usato solo quando si prova per rendere qualcosa sia analizzabile come XML e HTML. Prova <p/>foo</p>, ad esempio, e ottieni un paragrafo regolare.

26
Marijn

Il tag script autochiudente non funzionerà, perché il tag script può contenere codice inline e HTML non è abbastanza intelligente da attivare o disattivare 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 <link> 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 si desidera che il tag dello script sia autonomo, non è possibile farlo come ho detto, ma esiste un'alternativa, sebbene non intelligente. Puoi utilizzare il tag di collegamento autochiudente e il link al tuo JavaScript dandogli un tipo di testo/javascript e rel come script, qualcosa di simile di seguito:

<link type="text/javascript" rel ="script" href="/path/tp/javascript" />
22
defau1t

A differenza di XML e XHTML, HTML non ha alcuna conoscenza della sintassi 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 <script defer> è trattato come <script defer="defer">, <script /> è trattato come <script /="/">.

20
rpetrich

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 la sintassi 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 chiamato /, 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 fornito con application/xhtml+xml.

18
Mike Dimmick

Questo perché SCRIPT TAG non è un ELEMENTO VUOTO.

In un documento HTML - VOID ELEMENTS do not ha bisogno di un "tag di chiusura"!

In xhtml , tutto è generico, quindi tutti hanno bisogno terminazione ad es. un "tag di chiusura"; Includendo br, una semplice interruzione di riga, come <br></br> o la sua stenografia <br />.

Tuttavia, uno Script Element non è mai un vuoto o un Elemento parametrico, perché tag script prima di qualsiasi altra cosa, è un'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:

la semantica <H1> non può essere terminata da un <P> seguente perché non trasporta abbastanza della propria semantica da sovrascrivere e quindi termina il precedente set di istruzioni H1. Sebbene sia in grado di interrompere il flusso in una nuova riga di paragrafo, non è "abbastanza forte" da sovrascrivere la dimensione del carattere e la linea di stile attuali height che scorre verso il basso del flusso , cioè che perde da H1 (perché P non ce l'ha).

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

Una terminazione generica senza descrizione Tag come < />, sarebbe stata sufficiente per ogni singola caduta dalla cascata incontrata, ad esempio: <H1>Title< /> ma non è sempre il caso, perché vogliamo anche essere capace di "annidare", più tagging intermedio del flusso: diviso in torrenti prima di avvolgere/cadere su un'altra cascata. Di conseguenza un terminatore generico come < /> non sarebbe in grado di determinare la destinazione di una proprietà da terminare. Ad esempio: <b> bold <i> bold-italic < /> italic </>normal. Indubbiamente non riuscirebbe a ottenere le nostre intenzioni e probabilmente lo interpreterebbe come grassetto bold-itallic bold normale.

Ecco come è nata la nozione di un wrapper., È nato container. (Queste nozioni sono così simili che è impossibile discernere e talvolta lo stesso elemento può avere entrambi. <H1> è sia wrapper che container allo stesso tempo, mentre <B> è 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. Ovviamente 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 è possibile sovrascrivere facilmente il comportamento nativo pre e post BR di un DIV appena inventato, a cui viene spesso fatto riferimento come "non fare nulla contenitore". Che è, naturalmente, sbagliato! I DIV sono elementi di blocco e interromperanno nativamente la linea del flusso 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 apparivano come obsolete, venivano deturpate, private di tutto il loro significato originale, identità 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 avere tag significativi invece; 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. Il W3C è passato 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 e essere in grado di capire che xhtml non è solo una versione di qualche esteso HTML , xhtml è completamente diverso bestia; motivi su; e quindi è saggio tenerli separati.

5
Bekim Bacaj

La differenza tra 'vero XHTML', 'faux XHTML' e HTML così come l'importanza del tipo MIME inviato dal server era stata già descritta qui 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; }
<div>Mime type: <label><input type="radio" onchange="t.onkeyup()" id="x" checked  name="mime"> application/xhtml+xml</label>
<label><input type="radio" onchange="t.onkeyup()" name="mime"> text/html</label></div>
<div><textarea id="t" rows="4" 
onkeyup="i.src='data:'+(x.checked?'application/xhtml+xml':'text/html')+','+encodeURIComponent(t.value)"
><?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"
[<!ENTITY x "true XHTML">]>
<html xmlns="http://www.w3.org/1999/xhtml">
<body>
  <p>
    <span id="greet" swapto="Hello">Hell, NO :(</span> &x;.
    <script src="data:text/javascript,(g=document.getElementById('greet')).innerText=g.getAttribute('swapto')" />
    Nice to meet you!
    <!-- 
      Previous text node and all further content falls into SCRIPT element content in text/html mode, so is not rendered. Because no end script tag is found, no script runs in text/html
    -->
  </p>
</body>
</html></textarea>

<iframe id="i" height="80"></iframe>

<script>t.onkeyup()</script>
</div>

Dovresti vedere Hello, true XHTML. Nice to meet you! sotto textarea.

Per i browser non abilitati è possibile copiare il contenuto della textarea e salvarlo come file con estensione .xhtml (o .xht) ( grazie Alek per questo suggerimento ).

2
myf