Scrivere tag a chiusura automatica per gli elementi non è tradizionalmente una cattiva pratica vuota?

StackOverflow https://stackoverflow.com/questions/348736

  •  20-08-2019
  •  | 
  •  

Domanda

Ho notato che jQuery (o è Firefox) trasformerà alcuni dei miei file <span class="presentational"></span> into <span class="presentational" />

Ora la mia domanda è: va bene scrivere il mio markup in questo modo?Qualche browser si bloccherà?

Personalmente, penso che sia più pulito da fare <span class="presentational" /> se sarà vuoto.

È stato utile?

Soluzione

Suppongo che la tua domanda abbia a che fare con la barra rossa finale sugli elementi a chiusura automatica quando visualizzi la fonte in Firefox. Se è così, ti sei imbattuto in uno dei dibattiti aggressivi più veemente, ma allo stesso tempo passivi nella creazione del browser rispetto alle guerre degli sviluppatori web. XHTML NON riguarda solo il markup di un documento. Si tratta anche di come i documenti devono essere offerti sul Web.

Prima di iniziare; Sto cercando di non schierarmi qui.

La specifica XHTML 1.1 dice che un server web dovrebbe servire XHTML con un Content-Type di application / xhtml + xml. Firefox sta individuando quelle barre finali come non valide perché il tuo documento viene servito come text / html anziché application / xhtml + xml. Prendi questi due esempi; markup identico, uno servito come application / xhtml + xml, l'altro come text / html.

http://alanstorm.com/testbed/xhtml-as-html.php

http://alanstorm.com/testbed/xhtml-as-xhtml.php

Firefox contrassegna la barra finale nel meta tag come non valida per il documento pubblicato con text / html e valida per il documento pubblicato con application / xhtml + xml.

Perché questo è controverso

Per uno sviluppatore di browser, il punto di XHTML è che puoi trattare il tuo documento come XML, il che significa che se qualcuno ti invia qualcosa che non è valido, la specifica dice che non devi analizzarlo. Quindi, se un documento viene servito come application / xhtml + xml e ha contenuti non ben formati, lo sviluppatore può dire & Quot; non il mio problema & Quot ;. Puoi vederlo in azione qui

http://alanstorm.com/testbed/xhtml-not-valid.php

Quando un documento viene servito come text / html, Firefox lo tratta come un semplice vecchio documento HTML e usa il perdono, correggilo per te, analizzando le routine

http://alanstorm.com/testbed/xhtml-not -Valido-as-html.php

Quindi, per un produttore di browser, XHTML ha funzionato come text / html è ridicolo, perché non è mai trattato come XML dal motore di rendering del browser.

Un gruppo di anni fa, gli sviluppatori web che cercavano di essere più che tag scimmie (Disclaimer: includo me stesso come uno di loro) hanno iniziato a cercare modi per sviluppare le migliori pratiche che non coinvolgessero tre tabelle nidificate, ma consentivano comunque esperienza di design avvincente. Hanno attaccato XHTML / CSS, perché il W3C ha detto che questo era il futuro e l'unica altra scelta era un mondo in cui un singolo fornitore (Microsoft) controllava le specifiche di markup defacto. Il vero male è il fornitore unico e non tanto Microsoft. Lo giuro.

Allora dov'è la controversia? Esistono due problemi con application / xhtml + xml. Il primo è Internet Explorer. Esiste un bug / funzionalità legacy in IE in cui il contenuto servito come application / xhtml + xml richiederà all'utente di scaricare il documento. Se hai provato a visitare il file xhtml-as-xhtml.php elencato sopra con IE, è probabile che sia successo. Ciò significa che se vuoi usare application / xhtml + xml, devi annusare il browser per IE , controllare l'intestazione Accepts e servire application / xhtml + xml solo per quei browser che lo accettano. Questo è non così banale come sembra avere ragione, e anche andato contro il " scrivi una volta " principio per cui gli sviluppatori Web si stavano battendo.

Il secondo problema è la durezza dell'XML. Questo è, ancora una volta, uno di quei problemi inclini alla fiamma, ma ci sono alcune persone che pensano che un singolo tag errato o un singolo carattere codificato in modo errato non dovrebbe comportare un utente nondel documento che vogliono. In altre parole, sì, la specifica dice che dovresti interrompere l'elaborazione XML se non è ben formata, ma l'utente non si preoccupa delle specifiche, a loro importa che il sito web del loro gatto sia rotto.

Aggiungendo ancora più benzina al problema è la specifica XHTML 1.0 (non 1.1) che afferma che i documenti XHTML possono essere serviti come testo / html, supponendo che linee guida sulla compatibilità sono seguite. Cose come il tag img che si chiude automaticamente e simili. La parola chiave qui è può . In RFC speak , può significare facoltativo. Firefox ha scelto di NON trattare i documenti forniti con un doctype XHTML ma un tipo di contenuto di testo / html come XHTML. Tuttavia, il validatore del W3C riporterà felicemente questi documenti come validi.

Lascerò il lettore a meditare sullo stupore / orrore simultaneo di una cultura che scrive un documento per definire cosa intendono con la parola può .

Avanzamento

Infine, ecco di cosa tratta HTML 5 . L'XHTML è diventato una patata bollente così politica che un gruppo di persone che volevano spostare la lingua in avanti hanno deciso di andare in un'altra direzione. Hanno prodotto una specifica per HTML 5. Questo è attualmente in fase di hash nel W3C e dovrebbe concludersi nel prossimo decennio. Nel frattempo, i fornitori di browser selezionano e scelgono funzionalità dalle specifiche in corso e le implementano.

Aggiornamenti dai commenti

Nei commenti, Alex sottolinea che se hai intenzione di annusare qualcosa, dovresti controllare Accetta intestazione per vedere se application / xhtml + xml è accettato dall'agente utente.

Questo è assolutamente corretto. In generale, se stai per annusare, annusa la funzione, non il browser.

Altri suggerimenti

Un'aggiunta alle altre risposte: in IE, avere elementi come <span /> nel tuo markup causerà tutti i tipi di problemi con i metodi di attraversamento DOM in JavaScript . Dai un'occhiata al seguente documento XHTML: 

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
     "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
    <title>Test</title>
    <script type="text/javascript">
        function show() {
            var span = document.getElementById("span");
            alert(span.innerHTML);
        }
    </script>
</head>
<body onload="show();">
<p id="p1">Paragraph containing some text followed by
           an empty span<span id="span"/></p>
<p id="p2">Second paragraph just containing text</p>
</body>
</html>

L'idea è che quando la pagina viene caricata, JavaScript otterrà un riferimento all'intervallo vuoto e visualizzerà i suoi contenuti HTML. Sarà una stringa vuota, giusto? Non in IE non lo farà. In IE, ottieni tutto il contenuto dopo l'intervallo nell'intero documento: 

</P>
<P id=p2>Second paragraph just containing text</P>

Inoltre, il secondo <p> viene visualizzato nella raccolta childNodes dell'intervallo. Lo stesso <=> è anche nella raccolta <=> del corpo, il che significa che un nodo può effettivamente avere più genitori . Questa non è una buona notizia per gli script che si basano sulla traversata del DOM.

Ho anche blog su questo .

Sì. È. In alcuni casi causerà problemi ai vecchi browser. 

<script type='text/javascript' src='script.js' />

In questo caso, il vecchio browser potrebbe non capire che il tag <script> è terminato.

Servito come application / xhtml + xml, < span / > significa creare un elemento span senza contenuto.

Servito come text / html, < span / > significa creare un elemento span in cui il contenuto dell'elemento segue questo tag fino a quando < / span > viene rilevato un tag o viene rilevato un altro tag (o EOF) che chiude implicitamente l'elemento. cioè in questo caso < span / > significa lo stesso di < span > ;.

A parte: HTML 5 definisce sia le serializzazioni HTML che XHTML, quindi non influenza questo problema in un modo o nell'altro. Richiede, come XHTML 1.1, che XHTML sia servito come application / xhtml + xml, a differenza di XHTML 1.0. In effetti, tuttavia, questo non cambia nulla in quanto tutti i browser trattano qualsiasi versione di XHTML servita come text / html come tag soup.

Vale anche la pena notare che una <?xml ...?> dichiarazione prima del doctype porta IE in modalità stranezze

Vedi la nota sull'argomento del gruppo di lavoro XHMTL: http: // www.w3.org/TR/xhtml-media-types/

In breve & # 8212; va bene se il tuo XHTML verrà trattato come XHTML. Se hai intenzione di far finta che sia HTML (cosa che devi fare se vuoi che sia caricato da Internet Explorer (compresa la versione 8, più recente al momento della scrittura), allora devi saltare attraverso i cerchi).

I cerchi sono sufficientemente fastidiosi che consiglierei alla maggior parte delle persone di attenersi a HTML 4.01.

Generalmente non è un problema usare la scorciatoia per gli elementi vuoti, ma ci sono alcune eccezioni in cui può causare problemi.

<script> è importante che deve essere chiuso con </script> per evitare problemi.

Un altro è <meta> che funziona molto meglio con i ragni scritti come <meta></meta> anziché <meta />

Non esattamente la domanda, ma correlate, in termini di formattazione, le versioni di IE hanno problemi con solo elementi vuoti come <div></div> o <div />. In questo caso, per mantenere la formattazione è necessario <div>&nbsp;</div>.

Va detto esplicitamente che non ci sono tag autochiusi in HTML, quindi ogni volta che un browser decide di trattare il tuo XHTML come HTML, non riconoscerà che il tag è chiuso.Non è un problema per i tag che non devono essere chiusi in HTML, come <img>, ma ovviamente pessimo con i tag like <span>.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top