dicevo io: sai che non ho capito?

Accidenti, hai ragione. e’ una cosa di anni fa e si vede che nel frattempo il provider ha cambiato associazioni.
Non sto a rifarlo, è una cosa che si sa fin dal 2004 e IE funziona anche con application/xhtml+xml, senza sniffing.
(http://dean.edwards.name/my/application_xml.html, guarda i response header)
E’ da usare? no, non lo è, ovviamente.
Tutto il resto francamente non mi interessa, son cavilli poco significativi e piuttosto aleatori, senza alcuna influenza sulla resa della pagina. Stiamo parlando di xhtml 1.0, non 1.1. E’ questo che si dimentica sempre.
Per me, come già detto, il discorso è: non c’è niente di male a creare pagine xhtml 1.0 e a inviarle ai browser come text/html, è del tutto lecito e non fa alcun male a nessuno.
Per altre informazioni, leggi anche http://h3h.net/2005/12/xhtml-harmful-to-feelings/, se non l’hai già fatto perché ho visto che hai fatto un ottimo lavoro sul tuo sito.
Inoltre, se chi crea la pagina è esperto e si cura di validarla, per me la può fare anche in HTML 3.2.
Per i motivi per cui è preferibile usare xhtml invece di html, farò un’aggiunta al post, che così in effetti sembra un’affermazione perentoria e campata in aria.

> Non è vero nemmeno questo, se stiamo parlando di xhtml 1.0.
Se apri una pagina in XHTML inviata come text/html e fai View Page Source da Firefox vedrai tutti i / in tag come BR segnati in rosso, perché il parser HTML non li riconosce, se la stessa pagina invece è inviata come application/xml+xhtml sono in nero, perché per quello XHTML sono validi. Puoi vederlo su 2.php?type=html (dove il / nei tag svg:circle è rosso) e su 2.php?type=xhtml (dove è nero, inoltre qua svg e mathml funzionano perché la pagina è stata servita con il content type corretto e parsata con il parser adatto).
Per quanto riguarda xml:lang non ho nessun esempio pronto, ma come per ogni altro attributo che non fa parte delle specifiche HTML (perché con text/html viene parsato come HTML) dovrebbe essere semplicemente ignorato.
Ci sarebbe anche da dire che il / in HTML è usato per i NET (Null End Tags) quindi <br/> è una sintassi abbreviata valida in HTML che corrisponde a <br>> e se il browser non mostra il > di troppo è solo perché questa sintassi non è supportata volutamente dai principali browser.

> Che gli elementi di html e xhtml 1.0 siano gli stessi, non ci piove. I vantaggi sono per lo sviluppatore, che può senza dubbio scrivere del codice più pulito e maneggevole.
È ben perché i tag son gli stessi se non c’è alcuna differenza (tranne alcuni casi come i BR – vedi fine del commento): quello che puoi scrivere in XHTML lo puoi scrivere anche in HTML. Come ho già fatto notare in HTML puoi anche aprire un LI o un P senza chiuderlo e la pagina rimane valida, ma non è il fatto di *poterli* lasciare aperti che ti permette di scrivere codice migliore in XHTML. Io chiudo tutti i LI e tutti i P anche in HTML e il mio codice è ordinato come un qualsiasi altro codice scritto in XHTML ordinato. Quindi XHTML non aggiunge cose “nuove” che permettono un ordine maggiore, ma semplicemente vieta cose che porterebbero a un disordine maggiore. Chi si preoccupa di validare e di scrivere codice ordinato non ha bisogno di questi “divieti”, al contrario chi non si preoccupa scrive la stessa tag soup anche in XHTML.

>Occorre distinguere bene: XHTML 1.0 è DIVERSO da XHTML 1.1 in sù.
In XHTML 1.0 il text/html è tollerato perché deve essere un “passaggio intermedio” per migrare da HTML a XHTML 1.1 e quindi mantiene una certa retro-compatibilità, ma i motivi di questa scelta non sono certo tecnici, se invii una pagina XHTML 1.1 come text/html il browser riesce a parsarla senza problemi (ovviamente senza mostrare tutte le “estensioni” tipo SVG, ma lo stesso accade anche con XHTML 1.0). Se da XHTML 1.1 non è più possibile (così come non è più possibile usare doctype transitional e frameset) è perché chi doveva “convertirsi” ha avuto il tempo di farlo con XHTML 1.0 e quindi tutte queste cose “scorrette” che prima erano tollerate ora non lo sono più.

> La differenza è che in xhtml almeno chiudi gli elementi…
Questo non deve essere per forza una cosa buona. Sono completamente d’accordo che chiudere gli elementi che hanno un contenuto (P, LI, DIV, ecc) sia cosa buona e giusta, ma IMHO non ha senso farlo con elementi come BR, HR, IMG ecc. Scrivere <br /> equivale a <br></br> che sarebbe come dire “qui inizia un line break” “qui finisce il line break”, quando il line break è semplicemente un singolo carattere, che non può avere né un inizio né una fine (né tanto meno un contenuto). Questi tag fanno solo da “segnaposto” senza marcare nessun contenuto. A tal proposito ti segnalo anche l’articolo di Jukka Korpela “Empty elements in SGML, HTML, XML, and XHTML” (http://www.cs.tut.fi/~jkorpela/html/empty.html), che addirittura sostiene che in un linguaggio di markup come (X)HTML questi tag non dovrebbero esistere, appunto perché non marcano niente.

(Spero che i vari tag che ho usato negli esempi e i link si vedano correttamente, perché nel post precedente sono stati cancellati.)

No, non è così. Prova a caricare con IE la pagina a http://www.tiuvizeta.it/default.xml.
E’ una pagina xml con content type application/xhtml+xml. IE ci metterà un po’ ma la carica correttamente.
Per Firefox ovviamente nessun problema.
Se il provider non cofigura i mime, o si rifiuta di farlo, certo ci sono ulteriori problemi, ma esulano da questa discussione.

>che non sarà quindi in grado di riconoscere il / nei tag >come o alcuni attributi come xml:lang. Se il parser

Non è vero nemmeno questo, se stiamo parlando di xhtml 1.0.

>parlato di “massimo vantaggio a costi minimi” e di >“un’azione solida e pragmatica, che garantisce vantaggi >riguarda i vantaggi di cui parli non ne vedo nemmeno >uno. Il principale vantaggio di XHTML è l’estensibilità

Che gli elementi di html e xhtml 1.0 siano gli stessi, non ci piove. I vantaggi sono per lo sviluppatore, che può senza dubbio scrivere del codice più pulito e maneggevole.
Trovo un po’ ridicolo dichiarare il doctype html e scrivere il codice in xhtml come fa Meyer, per esempio.
Ma saran ben affari suoi . Per me, è fighettismo, niente di più.

>supportano ancora bene XHTML, quindi chi sceglie di >usarlo è costretto a inviare un documento XHTML dicendo

Occorre distinguere bene: XHTML 1.0 è DIVERSO da XHTML 1.1 in sù. Quello che dici vale senza dubbio per XHTML 1.1, ma non per XHTML 1.0 (non lo dico io, lo dicono le specifiche e anche Hixie, benché l’abbia aggiunto in stile codicillo dei contratti di assicurazione nelle note del suo advocacy.

>C’è anche da dire che HTML permette di scrivere codice >“peggiore”, ma questo non vuol dire assolutamente che

No, certamente. La differenza è che in xhtml almeno chiudi gli elementi…

Analogamente, servire il documento in text/html non significa che questo non sia più un documento XHTML. Sarà né più né meno quello che avete deciso che sia dichiarando un doctype.

Il media type in alcune circostanze può essere una utile indicazione per chi fruisce della pagina, *ma non controlla questa scelta in alcun modo*.”
Invece succede esattamente il contrario: i browser decidono come parsare la pagina non in base al doctype (come in teoria dovrebbero fare) ma in base al content-type quindi, anche se il documento è effettivamente una pagina XHTML, se servita con content-type text/html verrà parsata con un parser HTML che non sarà quindi in grado di riconoscere il / nei tag come o alcuni attributi come xml:lang. Se il parser scelto dipendesse effettivamente dal doctype non ci sarebbe nessuna differenza tra un documento servito come text/html e uno servito come application/xhtml+xml (e credo che il browser proverebbe ad aprirlo come immagine se fosse servito come image/jpeg).

Analogamente Firefox apre tranquillamente un sorgente python (*.py) servito come text/html ma ti chiede di salvarlo se servito come application/python, anche se è un semplice file di testo.

Detto questo è bene precisare che io non sono contrario a XHTML in sé, ma all’uso scorretto che se ne fa. Hai parlato di “massimo vantaggio a costi minimi” e di “un’azione solida e pragmatica, che garantisce vantaggi reali agli autori e non impone alcuna spesa agli utenti, a cui giustamente non può fregare di meno del mime type”. Sul fatto che agli utenti non gliene frega niente sono d’accordo, d’altronde visitano quotidianamente siti fatti con Word senza neanche rendersene conto. Per quanto riguarda i vantaggi di cui parli non ne vedo nemmeno uno. Il principale vantaggio di XHTML è l’estensibilità (da qui la “X” nel nome) che funziona *solo* se il documento è servito come application/xhtml+xml. Quindi ora puoi scegliere di usare XHTML, estenderlo, servirlo come application e subirti tutte le conseguenze che ne conseguono (IE non lo apre, problemi minori con altri browser) oppure non estenderlo, usare *le stesse identiche cose* che hai in HTML4 (che è pure supportato meglio dai vari browser e quindi crea meno problemi e costi per risolverli) e servirlo come text/html.

Per riassumere: i broswer (non tutti almeno) non supportano ancora bene XHTML, quindi chi sceglie di usarlo è costretto a inviare un documento XHTML dicendo al browser che è HTML e consapevole del fatto che verrà parsato con un parser HTML e che tutte le cose che XHTML introduce non potranno essere usate (oppure metterle sapendo che il parser le ignorerà). Oppure uno può scegliere di usare HTML4 che *è* HTML, viene parsato con un parser HTML e non ha “intrusi” (come o xml:lang).
C’è anche da dire che HTML permette di scrivere codice “peggiore”, ma questo non vuol dire assolutamente che non sia possibile scrivere codice valido e ordinato, come d’altronde è possibilissimo scrivere tag soup in XHTML (tanto finché viene servito come text/html non ci sono conseguenze).