È accettabile per XHTML non valido?

Question

Ho notato che molti siti, incluso SO, utilizzano XHTML come linguaggio di markup e quindi non rispettano le specifiche.Basta sfogliare il codice sorgente per SO e mancano tag di chiusura per paragrafi, elementi non validi, ecc.

Quindi gli strumenti (e gli sviluppatori) dovrebbero utilizzare il doctype XHTML se producono markup non valido?E i browser dovrebbero essere più fermi nell’accettare un markup scadente?

E prima che qualcuno gridi ipocrita, il mio blog ha un pezzo di markup non valido che coinvolge captha (o lo ha fatto l'ultima volta che ho controllato) che coinvolge lo styling del tag noscript.

Answer 1

Ci sono molte ragioni per utilizzare markup valido.Il mio preferito è che ti consente di utilizzare la convalida come una forma di test di regressione, impedendo che l'equivalente markup di "delta rot" porti a problemi di rendering reali una volta che gli errori raggiungono una massa critica.E in realtà, è semplicemente sciatto consentire l'accumulo di errori "pigri" come errori di battitura e tag annidati/non chiusi.Il markup valido è un modo per identificare programmatori appassionati.

C'è anche il problema del debug:il markup valido fornisce inoltre una base stabile da cui lavorare sugli inevitabili problemi di compatibilità tra browser.Nessuno sviluppatore web che valorizzi il suo tempo dovrebbe iniziare a eseguire il debug dei problemi di compatibilità del browser senza prima assicurarsi che il markup sia almeno sintatticamente valido e qualsiasi altro markup non valido dovrebbe avere una buona ragione per essere presente.

(Per inciso, stackoverflow.com fallisce sia questi test che i suggerimenti per risolvere i problemi erano rifiutato.)

Detto questo, per rispondere alla tua domanda specifica, probabilmente non vale la pena utilizzare uno dei doctype XHTML a meno che tu non intenda produrre documenti validi (o almeno meno markup ben formato).I principali vantaggi di XHTML derivano dal fatto che XHTML è XML, consentendone l'elaborazione e la trasformazione mediante strumenti e tecnologie che funzionano con XML.Se non hai intenzione di creare il tuo XML XHTML ben formato, allora non ha molto senso scegliere quel doctype.L'ultima specifica HTML 4 probabilmente farà tutto ciò di cui hai bisogno ed è molto più indulgente.

Answer 2

Dovremmo sempre cercare di farlo convalidare secondo gli standard.Saremo sicuri che il sito web verrà visualizzato e funzionerà correttamente sui browser attuali E sui browser futuri.

Answer 3

Non penso che, se specifichi un doctype, ci sia qualche motivo per non aderire a quel doctype.

L'utilizzo di XHTML semplifica il rilevamento automatizzato degli errori, ogni modifica può essere controllata automaticamente per rilevare eventuali markup non validi.Ciò impedisce errori, soprattutto quando si utilizzano contenuti generati automaticamente.È davvero facile per uno sviluppatore web che utilizza un motore di template (JSP, ASP.NET StringTemplate, eccetera) copiare/incollare un tag di chiusura troppo piccolo o eccessivo.Quando questo è l'unico errore, può essere rilevato e corretto immediatamente.Una volta ho lavorato per un sito che presentava 165 errori di convalida per pagina, di cui 2 o 3 erano veri e propri bug.Questi erano difficili da trovare nella confusione di altri errori.La convalida automatica avrebbe impedito questi errori alla fonte.

Inutile dire che scegliere uno standard e attenersi ad esso non può mai favorire l'interoperabilità con altri sistemi (screen scraper, screen reader, motori di ricerca) e non mi sono mai imbattuto in una situazione in cui una valida soluzione XHTML semantica con CSS non fosse possibile per tutti principali browser.

Ovviamente, quando si lavora con sistemi complessi, non è sempre possibile attenersi al proprio doctype, ma ciò è principalmente il risultato di una comunicazione impropria tra i diversi team che sviluppano parti diverse di questi sistemi o, molto probabilmente, sistemi legacy.Nell'ultimo caso è probabilmente meglio isolare questi casi e modificare di conseguenza il proprio doctype.

È bene essere pragmatici e non aderire a XHTML solo perché qualcuno lo ha detto, indipendentemente dai costi, ma con le attuali conoscenze su CSS e browser, strumenti di test e validazione, il più delle volte i benefici sono molto maggiori dei costi.

Answer 4

Puoi dire che ho un disturbo ossessivo compulsivo sulla validità XHTML.Trovo che la maggior parte dei problemi legati alla non validità del codice provengano da programmatori che non conoscono la differenza tra HTML e XHTML.Sto scrivendo XHTML e CSS validi al 100% ormai da un po' e non ho mai avuto grossi problemi di rendering con altri browser.Se mantieni tutto valido e non provi nulla di troppo esotico dal punto di vista dei CSS, risparmierai un sacco di tempo nelle correzioni.

Answer 5

Non userei affatto XHTML solo per risparmiarmi lo stress filosofico.In ogni caso non è che nessun browser lo tratti come XHTML.

I browser rifiuteranno un markup scadente se la pagina viene inviata come application/xhtml+xml, ma raramente lo fanno.Questo va bene.

Sarei più preoccupato per cose come l'uso in linea di CSS e JavaScript con Stack Overflow, solo perché rendono più difficile la manutenzione.

Answer 6

Sebbene io creda nella ricerca di XHTML e CSS validi, spesso è difficile da realizzare per una serie di ragioni.

• Innanzitutto, parte del contenuto potrebbe essere caricato tramite AJAX.A volte, i frammenti non vengono inseriti correttamente nel DOM esistente.
• L'HTML che stai visualizzando potrebbe non essere stato prodotto tutto nello stesso documento.Ad esempio, la pagina potrebbe essere composta da più componenti, o modelli, e quindi messi insieme subito prima che il browser ne esegua il rendering.Questa non è una scusa, ma non puoi dare per scontato che l'HTML che vedi sia stato codificato manualmente tutto in una volta.
• Cosa succede se parte del codice generato da Markdown non è valido?Non puoi incolpare Stack Overflow per non aver prodotto codice valido.
• Infine, lo scopo di DOCTYPE non è semplicemente dire "Ehi, sto usando un codice valido", ma è anche quello di dare al browser un avvertimento su cosa stai cercando di fare in modo che possa almeno avvicinarsi all'analisi corretta quell'informazione.

Non penso che la maggior parte degli sviluppatori specifichi un DOCTYPE e poi non riesca esplicitamente a rispettarlo.

Answer 7

anche se sono d'accordo con l'affermazione "se viene visualizzato correttamente, non preoccuparti", tuttavia è positivo seguire uno standard, anche se potrebbe non essere completamente supportato in questo momento.puoi comunque utilizzare Table per il layout, ma non va bene per un motivo.

Answer 8

No, non dovresti usare XHTML se non puoi garantire la correttezza del formato, e in pratica non puoi garantirlo se non usi il serializzatore XML per generare markup.Leggere sulla produzione di XML.

La buona forma lo è IL cosa che differenzia XHTML da HTML.XHTML con "solo uno" errore di markup cessa di essere XHTML. Deve essere perfetto ogni volta.

Se il sito "XHTML" sembra funzionare con alcuni errori, è perché i browser ignorano il DOCTYPE e interpretare la pagina come HTML.

Vedere Proxy XHTML che forza l'interpretazione delle pagine come XHTML.La maggior parte delle volte falliscono miseramente.Questo è uno dei motivi per cui il futuro di XHTML è incerto e incerto perché lo sviluppo dell'HTML è stato ripreso.

Answer 9

Dipende.L'ho avuto problema con il mio blog dove un video di YouTube causava XHTML non valido, ma veniva visualizzato correttamente.D'altra parte, ho un collegamento "XHTML valido" e una combinazione di un reclamo "XHTML valido" e XHTML non valido non è professionale.

Dato che SO non pretende di essere valido, penso che sia accettabile, ma personalmente se fossi Jeff mi preoccuperei e proverei a risolverlo anche se sembra buono nei browser moderni, ma alcune persone preferiscono semplicemente andare avanti e portare a termine le cose invece di correggere bug inesistenti.

Answer 10

Finché funziona in IE, FF, Safari, (inserisci qui un altro browser) dovresti stare bene.La convalida non è importante quanto il rendering corretto in più browser.Solo perché è valido, non significa che funzionerà correttamente in IE, ad esempio.

Esegui Google Analytics o simili sul tuo sito e scopri che tipo di browser utilizzano i tuoi utenti, quindi valuta quali browser devi supportare maggiormente e preoccupati di quelli meno importanti quando hai tempo libero per farlo.

Answer 11

Io dico che se il rendering è OK, non importa se è perfetto al pixel.

Ci vuole un po' di tempo per far funzionare un sito nel modo desiderato, tornare indietro e apportare modifiche cambierà leggermente il modo in cui la pagina viene visualizzata, quindi devi risolvere quelli i problemi.

Ora, non sto dicendo che dovresti creare pagine web sciatte, ma non vedo alcun motivo per riparare ciò che non è rotto.I browser non interromperanno il supporto per la correzione degli errori nel prossimo futuro.

Answer 12

Non capisco perché tutti si impegnino a cercare di adattare i propri siti Web allo standard quando alcuni browser hanno ancora problemi a riprodurre correttamente il codice standard.Mi occupo di web design da qualcosa come 10 anni e ho smesso di fare doppia codifica (leggi:hacking CSS) e cambiando cose stupide solo per poter mettere un pulsante sul mio sito.

Credo che l'utilizzo di un <div> ti renderà non valido a prescindere, e diventerà un po' più difficile eseguire qualsiasi JavaScript/AJAX principale senza di esso.

Answer 13

Ci sono così tanti standard e sono così mal "applicati" o supportati che non penso che abbiano importanza.Non fraintendetemi, penso che dovrebbero esserci degli standard ma poiché non vengono applicati, nessuno li segue e si crea un'enorme spirale discendente.

Answer 14

Per il 99,999% dei siti disponibili, non avrà alcuna importanza.L'unica volta che ho avuto problemi, ho eseguito l'input HTML tramite HTMLTidy per renderlo XHTML, quindi ho eseguito l'elaborazione su di esso.

Praticamente è l'assioma del vecchio programmatore:non fidarti di alcun input.