Vale la pena il tempo di sviluppo per produrre HTML valido?

Question

Lo sviluppo di siti Web richiede tempo. Per migliorare la produttività, vorrei codificare un prototipo da mostrare ai nostri clienti. Non mi preoccupo di rendere il prototipo conforme allo standard. Il più delle volte, i nostri clienti approvavano il prototipo e davano una scadenza irragionevole. Di solito finisco per usare il prototipo in produzione (ehi, il prototipo funziona. Non c'è bisogno di rendere il mio lavoro più difficile.)

Potrei refactificare il codice per generare HTML valido. Ma vale la pena di produrre HTML valido?

Answer 1

Vale la pena solo se ti dà un vantaggio pratico. Attenersi agli standard potrebbe semplificare la creazione di un sito Web che funziona sulla maggior parte dei browser. Inoltre, se sei soddisfatto di come un sito Web viene visualizzato sui browser che ti interessano (forse uno, forse tutti), passare attraverso i cerchi per far passare la convalida è una perdita di tempo.

Inoltre, la differenza nel SEO tra un sito Web HTML completamente valido e un sito Web HTML per lo più valido è trascurabile.

Quindi cerca sempre il vantaggio pratico, ce ne sono alcuni in alcune situazioni, ma non farlo solo per il gusto di farlo.

Answer 2

Sì. È abbastanza difficile provare a gestire il modo in cui diversi browser renderanno HTML valido, non importa cercare di prevedere cosa faranno con codice non valido. Lo stesso vale per i motori di ricerca: un numero sufficiente di problemi nell'HTML può comportare che il sito non venga indicizzato correttamente o affatto.

Suppongo che la vera risposta sia " dipende da cosa non è valido per l'HTML " ;. Se le parti non valide si riferiscono a problemi di accessibilità, potresti persino riscontrare problemi legali se il cliente utilizza il sito su base commerciale.

Answer 3

Probabilmente no se hai un sito non conforme all'inizio e hai poco tempo.

Tuttavia, e non mi crederai perché non credevo che gli altri iniziassero, ma è più facile rendere un sito conforme fin dall'inizio: ti fa risparmiare il mal di testa in termini di compatibilità del browser, comportamento CSS e persino Comportamento JavaScript ed è generalmente meno markup da mantenere.

La conformità del sito (almeno a Transizionale) è piuttosto semplice.

Answer 4

Produrre HTML conforme è simile a garantire che non ci siano avvisi durante una compilation: gli avvisi sono lì per un motivo, potresti non rendertene conto, ma ignorare gli avvisi e, prima di sapere dove ti trovi, lì come tanti, non puoi individuare quello che è rilevante per il problema che stai cercando di risolvere.

Se usi Firefox per visualizzare le tue pagine web, otterrai un utile segno di spunta verde o una croce rossa nell'angolo in basso a destra, che ti mostrerà rapidamente se hai rispettato o meno. Fare clic su una croce rossa ti mostrerà tutti i luoghi in cui sei andato a letto. Alcuni degli avvisi / errori possono sembrare un po 'pedanti, ma correggili e ne trarrai beneficio in molti modi.

1. È molto più probabile che la tua pagina funzioni con una gamma più ampia di browser.
2. La conformità all'accessibilità sarà più semplice (ad esempio, avrai attributi "alt" sulle tue immagini)
3. Se si sceglie XHTML come standard, è più probabile che il markup sia utile in un ambiente AJAX.

La mancata esecuzione di questo comporta imprevedibilità.

Uno dei maggiori problemi con i browser Web è che hanno perpetuato cattive abitudini (e lo fanno ancora, in alcuni casi) correggendo silenziosamente alcuni problemi di markup, come l'incapacità di chiudere celle e / o righe della tabella. Questo singolo fatto ha portato a migliaia di pagine Web che non sono conformi ma "funzionano", cullando i loro sviluppatori in un falso senso di sicurezza.

Se consideri quante cose possono andare storte in un sito Web, essere pigri quando si tratta di conformità significa semplicemente aggiungere più problemi al carico di lavoro.

EDIT: dopo aver letto di nuovo il tuo post originale, noto che dici di non preoccuparti della conformità quando lavori su un prototipo, quindi prosegui dicendo che di solito usi il prototipo in produzione - questo significa che non lo è rigorosamente un prototipo, ma un candidato. La situazione normale in tali circostanze è che una volta che il cliente accetta un candidato, non viene assegnato alcun tempo per la correzione o la correzione degli errori, rafforzando così l'argomento per rendere il markup conforme in primo luogo.

Se non ti verrà dato il tempo dopo, fallo ora.

Se ti viene dato del tempo dopo, allora hai avuto il tempo di farlo comunque.

Answer 5

Se vuoi che la tua vista sia accessibile a persone con e senza disabilità, così come a sistemi esterni, allora sì, dovresti sicuramente assicurarti di produrre HTML valido.

È facile testare il tuo HTML con validatori automatici .

Aggiungerò ciò che Mike Edwards ha detto riguardo alle ramificazioni legali e ti ricordo che anche tu hai un obbligo morale :)

Answer 6

Perché non scrivere il prototipo in HTML (X) valido in primo luogo? Non ho mai mai trovato più sforzo che usare HTML non valido. Produrre XHTML valido dovrebbe essere un'attività banale. (D'altra parte, produrre XHTML semanticamente significativo potrebbe essere più faticoso.)

In breve, vedo nessun vantaggio nell'uso di HTML non valido per i prototipi.

Answer 7

Onestamente non so perché sia ??uno sforzo extra fare HTML basato su standard. Non è come se fosse difficile e dovresti farlo per una questione di professionalità.

Se pagassi qualcuno per costruirti una casa e lui tagliasse gli angoli per pigrizia, che in quel momento non notavi, ma tra 10 anni apparvero delle crepe nelle tue pareti, saresti felice?

Answer 8

HTML valido solo per poter avere un badge sul tuo sito - no.

Avere " HTML valido " nel senso di " HTML che funziona su tutti i principali browser o motori di browser " - sì.

Answer 9

Assolutamente. Un codice non valido può causare comportamenti di ogni genere e errori che non nascondono quelli che si verificano quando si riceve un rapporto di convalida.

Caso in questione:

Uno sfondo giallo si stava riversando da un elenco di messaggi e sopra l'intestazione per il prossimo elenco di messaggi, ma solo in Internet Explorer.

Perché? Lo sfondo è stato applicato a un elemento dell'elenco, ma la persona che ha scritto la pagina l'aveva scritto come un unico elenco con un'intestazione nel mezzo. Non è consentito intestare tra elementi dell'elenco e diversi browser hanno tentato di recuperarlo in diversi modi. Internet Explorer ha terminato l'elemento dell'elenco (con il colore di sfondo) quando ha visto l'inizio dell'elemento seguente (dopo l'intestazione), mentre altri browser lo hanno terminato quando hanno visto il tag di fine per il primo elemento dell'elenco.

Era l'unico errore di validità sulla pagina, quindi ci sono voluti solo un paio di minuti per rintracciare il problema e risolverlo.

Answer 10

Perché, se segui gli standard, il tuo lavoro sarà compatibile in futuro. Gli User Agent cercheranno la conformità standard e le loro modalità di non conformità delle stranezze saranno sempre soggette a modifiche. Questo è il modo in cui dovrebbe essere.
A meno che non ti piaccia tutta quella cosa perpetuazione degli standard IE8 rotti che vogliono abilitare di default. - è un altro argomento.
Webkit, Gecko, Presto? (è il motore di quell'opera?), e gli altri diventeranno sempre più conformi ad ogni uscita.
A meno che il tuo lavoro html sia in un controllo browser incorporato IE, allora non c'è davvero alcun motivo per produrre html valido fino a quando viene eseguito il rendering.

Answer 11

Secondo me il criterio chiave è "adatto allo scopo" - Se i tuoi clienti vogliono qualcosa per un mercato piccolo / interno (e non importa se questo allontana i potenziali clienti che hanno disabilità o usano browser meno comuni), allora è la loro scelta.

Allo stesso tempo, penso che sia nostra responsabilità (in qualità di sviluppatori) assicurarsi che siano a conoscenza delle implicazioni delle loro decisioni. Alcune organizzazioni saranno vincolate dai requisiti legislativi che i siti Web possano essere utilizzati dagli screen reader, che in genere significa HTML conforme agli standard .

Answer 12

Credo che produrre output html validi non danneggierà tanto il tuo tempo di sviluppo se ti sei allenato a codificare html valido dall'inizio.

per uno, non è così difficile sapere quali tag non sono consentiti all'interno di un elemento
e gli attributi richiesti in un tag sono a volte quelli di cui avresti davvero bisogno - credo che questi siano i principali errori che rendono il tuo html non valido, quindi perché non impararli già adesso se hai intenzione di rimanere sul Web a lungo?

Answer 13

Esistono due regole per la scrittura di siti Web:

1. Il sito deve funzionare per i tuoi utenti.
2. Il sito deve funzionare per i tuoi utenti.

Per soddisfare la prima regola, devi codificare in modo tale che il tuo sito venga visualizzato correttamente quando usi Internet Explorer. A meno che tu non abbia la libertà di modificare il design del tuo sito per utilizzare solo quelle funzionalità che IE visualizza correttamente, questo significa scrivere HTML non valido.

Per soddisfare la seconda regola, devi codificare in modo tale che il tuo sito venga visualizzato correttamente quando usi gli screen reader e gli schermi braille. Sebbene alcuni screen reader più recenti possano lavorare con siti con targeting IE, in generale questo significa scrivere HTML valido.

Se stai lavorando su un piccolo progetto o fai parte di un team di grandi dimensioni, puoi codificare un sito che genera HTML con targeting IE per IE e HTML valido in caso contrario. Ma se stai intraprendendo un progetto medio-grande da solo, devi decidere quale regola seguirai e quale ignorerai.

UPDATE:

Questo viene votato dagli utenti che pensano di poter sempre cavarsela con HTML valido in IE. Questo può essere vero se hai la flessibilità di cambiare il tuo design per ovviare alle carenze di IE, ma se un cliente ti ha dato un design e devi farlo funzionare, potresti dover ricorrere a HTML non valido. È triste, ma è vero, qualunque cosa possano pensare.