Cât de importantă este validarea W3C XHTML/CSS la finalizarea lucrului?

Cred că validarea este un test bun la testul dacă ați făcut lucrurile în mod corespunzător, deci dacă există doar câteva probleme minore, de ce să nu le remediați și să vă asigurați că site-ul dvs. va fi cel puțin înțeles corect de browsere în viitor face lucrurile diferit din alte motive)?

OTOH, pentru majoritatea proiectelor, validarea pare a fi o durere de cap uriașă și dacă puteți obține lucruri care funcționează în cadrul browserelor, nu merită să cheltuiți o zi suplimentară/săptămână + doar pentru validare.

Știu că nu răspunde la întreaga întrebare, dar merită să considerăm că prin utilizarea html complet validată puteți fi sigur că site-ul dvs. Web ar trebui să funcționeze corect în browserele web viitoare care nu au fost încă lansate .

Abordarea mea tinde să fie să mă asigur că pot valida complet pe toate paginile, cu toate acestea trimite încă pagina ca text/html în loc de aplicație/xhtml + xml, astfel încât nu există erori xml urâte în cazul în care am pierdut ceva.

Cred că acesta este un domeniu în care trebuie să încerci să folosești principiul robusteței , așa cum este practic (care este un sfat bun pentru orice zonă de codificare). Doar pentru că lucrurile funcționează astăzi nu înseamnă că va funcționa mâine: dacă vă bazați pe un anumit hack HTML/CSS sau chiar dacă tocmai ați fost puțin mai puțin elastic în emiterea unui cod strict valabil, următoarea iterație a browserelor ar putea fi bine pauză. Făcând-o odată corect, acest lucru minimizează această problemă (deși nu o diminuează complet).

Există totuși un anumit element de pragmatism care trebuie luat aici. Cu siguranță aș face tot ce am putut pentru ca site-ul unui client să fie valabil, dar aș fi dispus să iau mai multe riscuri în propriul spațiu.

Cred că doar tipii "tech" se ocupă de "respectarea standardelor de 100%". Consumatorii obișnuiți de pagină (= utilizatori) nu le pasă dacă nu există alt atribut pentru un "element de imagine de frontieră al meniului".

De obicei mă asigur că nu văd erori evidente (toate etichetele închise, toate literele mici, atributele în citate, ...), dar dacă arată bine pe IE și FF, asta e tot ce-mi pasă. Nu-mi pasă dacă folosesc un atribut non-standard în orice etichetă HTML, astfel încât pagina să nu fie validată împotriva unui DTD - atâta timp cât obțin rezultatele vizuale pe care intenționez să le obțin.

Pentru mine, simt că am făcut o treabă bună dacă codul meu este validat. Văzând caseta de validare verde de pe paginile w3c, mă face să fiu puțin giddy. În ceea ce privește grupul b, de obicei aceștia au grijă doar că arată și funcționează la fel în browsere. Doar locul pe care l-am descoperit că nu este adevărat este sectorul guvernamental. Acestea necesită o validare completă nu numai cu testele W3C, ci și cu trecerea ADA (în esență, cum se aude cu un cititor de ecran).

P.S. când spun sectorul guvernamental, mă refer în mod specific la statul California și la câteva județe din interiorul acestuia. Nu am mai avut nici o experiență cu alte grupuri guvernamentale pe lângă acestea.

a) Trebuie sa arate la fel

b) Ca standarde compatibile, dar nu atât de anal, încât blochează munca de finisare

Într-o situație în care aveți acces perpetuu la cod, nu cred că respectarea standardelor este atât de importantă, deoarece puteți face întotdeauna schimbări în cod dacă se rupe ceva. Dacă nu aveți acces perpetuu (adică semnați codul și devine responsabilitatea altcuiva), este probabil cel mai bine să fiți cât mai compatibil cu standardele pentru a minimiza durerile de întreținere mai târziu ... chiar dacă nu trebuie să se ocupă de codul din nou, reputația persistă și poate fi transmisă altor potențiali clienți, iar multe echipe le dau vina pe dezvoltatorii anteriori pentru problemele care apar.

Pentru a înțelege validarea de ce , este necesar să înțelegeți cum o browserul funcționează la diferitele sale straturi și, de asemenea, un pic despre istoria webului din perspectiva browserelor web.

HTML-ul pe care îl oferiți unui browser este interpretat de browser-ul urmărit de DOM, o interfață de programare a aplicației care cartografiază întreaga pagină ca o ierarhie a nodurilor. Fiecare parte a acestui arbore este un tip de nod care conține diferite tipuri de date. DOM (Document Object Model) a fost necesar din cauza diversității paginilor HTML pe care browserele web devreme (Netscape, IE ...) au implementat pentru a permite modificarea aspectului și conținutului unei pagini web fără a le reîncărca. Pentru păstrarea naturii trans-platforme a web-ului, W3C a dorit să repare implementarea diferită a acestor browsere, propunând DOM.

Suportul DOM a devenit o prioritate imensă pentru majoritatea furnizorilor de browsere web, iar eforturile depuse pentru îmbunătățirea suportului pentru fiecare lansare. Deci, a funcționat.

DOM este pasul foarte simplu cu care începe un browser web. Principalul său flux este:

1. parsarea HTML pentru a construi arborele DOM
2. construi structura arborelui
3. aspectul arborelui de randare
4. vopsirea arborelui de randare

Pasul 1 oferă arborele de conținut , cu etichetele întoarse la nodurile DOM. Pasul 2 oferă arborele de redare , care conține informații despre stil.

Deci, validarea why contează: deoarece arborele de conținut și render tree reprezintă baza de la care browserul web își începe activitatea. Cele mai multe sunt bine definite, cu atât mai bine pentru browserul web.

În cele din urmă, DOM este și baza pentru evenimentele dvs. JavaScript. Validarea acesteia ajută și la nivelul de interacțiune.

Cu excepția faptului că validatorii înșiși sunt atât de pozitivi analiali,  când semnalează o eroare sau un avertisment ori de câte ori se utilizează un termen -moz- sau -webkit sau -o- adică un termen de calificare specific pentru browser. de asemenea, doresc să specificați 0px, nu 0 sau alte unități Zero este Zero indiferent de unitățile pe care validatorul vrea să le verifice împotriva!

doar încercați să validați WordPress twentyeleven style.css aruncă 140 de erori ciudate, care sunt toate de natura de mai sus sau validator se recuperează de la erorile parse

Validatorii sunt inutili dacă nu puteți sorta grâul din pleavă!

Avem nevoie de validatori care să recunoască termenii de calificare specificați browserului!