La validazione HTML 5 varrà la candela?

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

  •  10-07-2019
  •  | 
  •  

Domanda

È ampiamente considerato che il miglior motivo per convalidare il proprio HTML sia garantire che tutti i browser lo tratteranno in modo coerente e prevedibile.

La bozza HTML 5, tuttavia, contiene due specifiche in una. Prima una specifica dell'autore, che descrive gli elementi e gli attributi che gli autori HTML dovrebbero usare e le loro interrelazioni. La convalida di una pagina HTML 5 si basa su questa specifica. Gli elementi e gli attributi inclusi non sono ricavati direttamente da HTML 4, ma devono essere giustificati dai primi principi, il che significa che alcune funzionalità HTML 4, come l'attributo di riepilogo su & Lt; table & Gt ;, longdesc su < img > e l'attributo del profilo su < head > ;, non appare attualmente in questa bozza. Tali funzionalità non sono considerate obsolete, semplicemente non sono incluse. (La loro assenza dal progetto rimane una questione controversa, sebbene la loro inclusione in qualsiasi momento presto non sembra probabile.)

In secondo luogo, la bozza definisce una specifica di elaborazione del browser che cerca di definire esattamente come il parser di un browser tratterà qualsiasi flusso di byte che viene fornito, indipendentemente da quanto ben formato e valido l'HTML. Ciò significa che quando i browser supportano completamente HTML 5, sarà possibile prevedere in che modo qualsiasi browser tratterà HTML per una gamma molto più ampia di input rispetto a quelli che superano semplicemente la validazione.

In particolare, poiché l'HTML 5 è definito come compatibile al 100% con il Web di oggi, tutto l'HTML 4 valido e tutti i markup non validi ma comunemente usati continueranno ad essere elaborati esattamente come è oggi, indipendentemente da se è HTML 5 valido o meno.

Pertanto, come minimo, chiunque utilizzi qualsiasi funzionalità di HTML 5, HTML 4 o qualsiasi versione precedente di HTML, oltre a molte estensioni proprietarie, può essere sicuro che il loro HTML otterrà un trattamento coerente e prevedibile su tutti i browser.

Detto questo, ha senso limitare i propri HTML 5 a ciò che verrà convalidato e quali benefici pratici trarremo dal farlo?

È stato utile?

Soluzione

  • Prima c'è & # 8217; s il livello di validità corrispondente a & # 8220; errori di analisi & # 8221; nell ' algoritmo di analisi HTML5 . Questo livello è simile alla ben formata XML. Il motivo principale per evitare di avere errori nei tuoi documenti su questo livello è che potresti ottenere un albero di analisi sorprendente. Se il tuo documento è privo di errori su questo livello, ricevi meno sorprese per il debug quando scrivi JS o CSS che funziona con il DOM.
  • Come caso speciale del livello sopra citato, <<>> 8217; s è il tipo di documento HTML5: <!DOCTYPE html>. Il motivo per cui si vorrebbe rispettare qui è ottenere la modalità standard nel modo più semplice possibile. È qualcosa che puoi memorizzare a differenza dei documenti HTML 4.01 o XHTML 1.0 che devi cercare e copiare e incollare ogni volta. Ovviamente, il motivo per cui & # 8217; vuoi la modalità standard sono meno sorprese sul livello CSS.
  • Il motivo principale per preoccuparsi della convalida sul livello superiore all'algoritmo di analisi è catturare i tuoi errori di battitura in modo da dedicare meno tempo al debug del motivo per cui la tua pagina non è & # 8217; t funziona come ti aspetti.
  • Il punto precedente non spiega perché dovresti preoccuparti della convalida quando un dato elemento o attributo che non hai scritto male è supportato dai browser come una questione di eredità, ma le specifiche HTML5 lo evitano ancora. Qui & # 8217; s perché HTML5 ha una sintassi obsoleta come questa:
    • HTML5 usa obsoletion per segnalare agli autori che alcune funzionalità sono una perdita di tempo. Questi includono longdesc, summary e profile. (Tieni presente che le persone non sono d'accordo sul fatto che queste siano, in effetti, una perdita di tempo, ma come attualmente redatto, HTML5 le rende obsolete.) Cioè, se hai risorse limitate per migliorare l'accessibilità, le tue risorse limitate sono meglio spese per qualcosa di diverso da < => e <font>. Se disponi di risorse limitate per la purezza semantica, le tue risorse vengono impiegate meglio in qualcosa di diverso dall'assicurarti di avere il giusto incantesimo in <applet>.
    • HTML5 oscura alcune funzionalità di presentazione che possono essere duplicate nei CSS per guidare gli autori a usare i CSS per il loro bene. In questo modo, gli autori che non considerano la manutenibilità da soli dovrebbero comunque essere guidati verso un codice più gestibile. Personalmente, preferisco rendere più conforme il materiale di presentazione legacy e lasciarlo agli autori stessi per decidere quale modo di fare le cose funziona per loro.
    • Alcune cose sono obsolete per motivi politici. L'elemento classid è obsoleto, perché renderlo conforme farebbe in modo che gli standardisti anti - <object> pensino che le persone HTML5 siano impazzite, il che potrebbe portare a cattive PR. name è obsoleto principalmente per principio di non assegnare markup speciali a un plug-in particolare. L'attributo <a> su language è obsoleto, perché & # 8217; è in pratica specifico di ActiveX.
    • Alcune cose sono obsolete sulla base dell'estetica del design del linguaggio. Ciò include l'attributo <script> su <=> e l'attributo <=> su <=>.

(sviluppo il validatore HTML5 Validator.nu che è anche il motore di validazione HTML5 usato dal validatore W3C.)

Altri suggerimenti

  

Detto questo, ha senso limitare i propri HTML 5 a ciò che verrà convalidato e quali benefici pratici trarremo dal farlo?

Sì, certo. Dimentichi che il futuro non è fisso. In particolare, supponi implicitamente che le specifiche HTML 5 non cambieranno mai e non deprecheranno mai alcuna funzionalità. Questo, ovviamente, consolida solo lo status quo. È sicuramente auspicabile rimuovere il supporto per alcune funzionalità a lungo termine, per facilitare la realizzazione di nuovi sviluppi (in particolare se questi potrebbero essere in conflitto tra loro).

Potrebbe non esserci alcun vantaggio immediato nella produzione di HTML 5 valido (tranne per il fatto che continua rende la convalida e quindi lo sviluppo più semplice). Ma potrebbe esserci un vantaggio a lungo termine se la maggior parte dei siti Web migliora in termini di qualità perché rende molto più semplice andare oltre le attuali tecnologie e standard.

La convalida non è mai stata realmente finalizzata a ottenere risultati coerenti tra i browser, anche prima dell'inizio di HTML5. Questo è un mito diffuso da coloro che non capiscono di cosa stanno parlando, anche se pensano di farlo.

Il vero motivo della convalida è ed è sempre stato un problema di garanzia della qualità. È solo un modo per rilevare errori, che. Anche se i risultati di un determinato errore possono essere o potrebbero diventare presto coerenti tra i browser, è comunque possibile che il risultato stesso non sia come previsto.

È importante che gli autori siano in grado di rilevare errori nel loro codice perché un markup più pulito e privo di errori è più facile da gestire e gestire, specialmente quando si lavora in un ambiente di squadra. Mentre la maggior parte degli errori individuali può finire per essere benigna e non causare problemi importanti, ci sono alcuni che possono dare risultati inaspettati. per esempio. In alcuni casi, gli elementi sovrapposti o non chiusi possono causare inaspettati problemi di layout e lasciare che un validatore ti dica dove si trova l'errore, aiuta a correggere il problema. Ma se i risultati sono pieni di dozzine di errori altrimenti benigni, può rendere il rilevamento e il processo più difficili del necessario.

Questo è, in effetti, uno dei miei cavilli con HTML5. Non ha senso definire un sottoinsieme di stream come 'valido', se un browser deve comunque gestire tutti i flussi allo stesso modo. Gli eoni spesi nella lista WHATWG discutendo dei meccanismi di fallback sono una perdita enorme del tempo di tutti, specialmente quando XML dovrebbe già aver risolto tutti i problemi di analisi.

Sarebbe stata utile produrre un documento di best practice sull'analisi di documenti non validi legacy, ma questo non fa parte di uno standard web, è solo un altro ingrediente per confondere ulteriormente le acque intorno a HTML5, che non può decidere se vuole codificare il comportamento esistente (come ha fatto HTML 3.2), ridefinire una piattaforma più pulita (come provato da HTML 3.0) o aggiungere nuove estensioni frammentarie.

Ad ogni modo, la domanda potrebbe essere fuori posto perché non ci sarà mai un browser che " supporta pienamente HTML5 " ;. C'è davvero troppo, troppo: i produttori di browser non sono in grado di implementare assolutamente tutto, anche se lo volessero, almeno esplicitamente. Invece, le funzioni ovviamente utili verranno selezionate dal venditore e incontreranno una più ampia accettazione.

HTML5 non è una specifica HTML coerente, è la ricetta tentacolare, illeggibile e incompiuta di Hixie per ogni cosa casuale che pensa dovrebbe fare un browser web. Fallirà. E l'approccio alternativo di W3, XHTML2, è già fallito. Non esiste una direzione futura coerente per gli standard web. Abbiamo lasciato cadere la palla.

È una buona domanda.

Lo scopo principale della convalida (almeno per me) è di aiutarmi a rilevare gli errori nel mio markup e di fornirmi una buona base su cui costruire quando collaudo pagine in diversi browser; se il markup è valido e la pagina è borked in IE6, si tratta di un problema di IE6.

Il fatto che i browser debbano comunque comportarsi in modo prevedibile anche se il markup include HTML5 tecnicamente non valido come un riepilogo della tabella o una chiave di accesso all'ancoraggio, confonde in qualche modo le acque.

Come regola generale, desidero sempre convalidare le mie pagine, per il motivo sopra menzionato. Tuttavia, se (ad esempio) un attributo fosse eliminato dalle specifiche HTML5 senza che fosse aggiunta una sostituzione apparentemente adatta, potrei essere incline a continuare a utilizzare l'attributo obsoleto o obsoleto e accettare gli errori di convalida.

Come sempre, penso che sia un caso di conoscere il tuo mestiere.

Se sai cosa stai facendo e hai preso una decisione consapevole di costruire una pagina che non convalida per validi motivi, non è un problema. Se stai solo scrivendo un codice che non convalida perché non conosci meglio, questa è un'altra faccenda.

Stephen

Gestore validatore HTML5 W3C qui. Di recente ho scritto un breve & # 8220; Perché convalidare? & # 8221; sezione per & # 8220; Informazioni su & # 8221; sezione del validatore HTML5:

http://validator.w3.org/nu/about.html# perché-validate

La fonte per il testo di quella sezione è qui:

https://github.com/validator/ validator / blob / master / site / nu-about.html # L160

E le richieste pull con perfezionamenti / aggiunte suggerite sono benvenute.

Quello che ho attualmente è questo:

  

Il motivo principale per eseguire i tuoi documenti HTML attraverso una conformità   checker è semplice: per rilevare errori involontari & # 8212; errori che potresti   altrimenti hai perso & # 8212, in modo da poterli riparare.

     

Oltre a ciò, alcuni requisiti di conformità dei documenti (regole di validità)   nelle specifiche HTML ci sono per aiutare te e gli utenti dei tuoi documenti   evitare alcuni tipi di potenziali problemi. Per spiegare la logica   dietro questi requisiti, le specifiche HTML contengono queste due sezioni:

           

Per riassumere ciò che & # 8217; s dichiarato in queste due sezioni:

     
      
  • Esistono alcuni casi di markup definiti come errori perché lo sono   potenziali problemi di accessibilità, usabilità, interoperabilità,   sicurezza o manutenibilità & # 8212 o perché possono causare scarsi risultati   prestazioni, o che potrebbero causare errori negli script   difficile da risolvere.
    •   
  • Insieme a quelli, vengono definiti alcuni casi di markup   come errori perché possono causare problemi potenziali in   Analisi HTML e comportamento di gestione degli errori & # 8212; in modo che, diciamo, & # 8217; d finisca   con qualche risultato non intuitivo e inaspettato nel DOM.
    •   
     

La convalida dei documenti avvisa di tali potenziali problemi.

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