Vă mulțumim pentru susținere

Este acceptabil pentru XHTML nevalid?

Am observat o mulțime de site-uri, inclusiv SO, folosesc XHTML ca limbă de marcare și apoi nu reușesc să adere la spec. Vizionând doar sursa pentru SO, lipsesc etichetele de închidere pentru paragrafe, elementele nevalide etc.

Deci, instrumentele (și dezvoltatorii) ar trebui să utilizeze doctype-ul XHTML dacă vor produce o marcare nevalidă? Și ar trebui browserele să fie mai ferme în acceptarea slabei marje?

Și înainte ca cineva să strige ipocrit, blogul meu are o singură bucată de marcare nevalidă care implică captha (sau a făcut-o ultima dată când am verificat) care implică styling tag-ul noscript.

0
adăugat editat
Este acceptabil ca IE să ignore standardele Web?
adăugat autor GateKiller

13 răspunsuri

Spun, dacă se face OK, atunci nu contează dacă pixelul este perfect.

Este nevoie de un timp pentru a obține un site în funcțiune și pentru a funcționa așa cum doriți, revenind și efectuând modificări va schimba modul în care pagina se redă ușor, atunci trebuie să remediați problemele acestor .

Acum, nu spun că ar trebui să construiți pagini web nedorite, dar nu văd niciun motiv pentru a repara ceea ce nu este rupt. Navigatorii nu vor renunța la corecția erorilor oricând în viitorul apropiat.

0
adăugat

Depinde. Am avut problema cu blogul meu în cazul în care un videoclip YouTube a cauzat XHTML nevalid, dar a fost redat bine. Pe de altă parte, am un link "Valid XHTML" și o combinație a unei revendicări "Valid XHTML" și a XHTML nevalid nu este profesională.

Deoarece SO nu pretinde că este valabil, cred că este acceptabil, dar personal, dacă eram Jeff, m-aș fi deranjat și aș încerca să-l reparăm chiar dacă arată bine în browserele moderne, dar unii oameni mai degrabă merg mai departe și chiar fac lucruri în loc de a repara bug-uri inexistente.

0
adăugat

Nu înțeleg de ce toată lumea este prinsă să încerce să-și facă site-urile să se potrivească standardului atunci când unii browsere au probleme în ceea ce privește redarea corectă a codului standard. Am fost în web design pentru ceva de genul 10 ani și am oprit dublu codding (citesc: hacking css), și schimbarea lucruri stupide doar pentru ca am putea pune un buton pe site-ul meu.

I believe that using a < div> will cause you to be invalid regardless, and it get a bit harder to do any major JavaScript/AJAX without it.

0
adăugat
Ce?
este XHTML perfect.
adăugat autor Kirk Strauser

Există atât de multe standarde și sunt atât de grav "impuse" sau susținute, încât nu cred că este important. Nu mă înțelegeți greșit, cred că ar trebui să existe standarde, ci pentru că nu sunt aplicate, nimeni nu le urmează și este o spirală masivă descendentă.

0
adăugat

Atâta timp cât funcționează în IE, FF, Safari (inserați alt browser aici), ar trebui să fiți bine. Validarea nu este la fel de importantă ca și când o faceți în mod corect în mai multe browsere. Doar pentru că este valabilă, nu înseamnă că va funcționa corect în IE, de exemplu.

Rulați Google Analytics sau altele asemănătoare pe site-ul dvs. și vedeți ce browsere utilizează utilizatorii dvs. și apoi judeca ce browsere trebuie să vă suportați cel mai mult și vă faceți griji cu privire la cele mai puțin importante atunci când aveți timpul liber să faceți acest lucru.

0
adăugat
Dar ce bun este "valabil" dacă browserele nu îl suportă chiar corect? Pot scrie "valabil" XHTML toată ziua, dar asta nu înseamnă că va face același browser încrucișat.
adăugat autor Bryan Denny
Dacă nu este validă, "redarea corectă" este o valoare nedefinită, deoarece este imposibil să se determine exact ce înseamnă "corect".
adăugat autor Kirk Strauser

Pentru 99,999% dintre site-uri acolo, nu va conta niciodată. Singura dată când am avut o problemă, am rulat intrarea HTML prin HTMLTidy în XHTML-o, și apoi mi-am executat procesarea.

Destul de mult, este axioma vechiului programator: nu ai încredere în nici o intrare.

0
adăugat

Există multe motive pentru a utiliza marcaj valid. Preferatul meu este că vă permite să utilizați validarea ca formă de teste de regresie, împiedicând echivalentul de markup al "putregaiului delta" să conducă la probleme reale de redare odată ce erorile ating o anumită masă critică. Și într-adevăr, este pur și simplu neglijent să permită să se "acumuleze" erori "leneși" cum ar fi greșelile și etichetele nesecate / neînchise. Marcarea validă este o modalitate de a identifica programatori pasionați .

There's also the issue of debugging: valid markup also gives you a stable baseline from which to work on the inevitable cross-browser compatibility woes. No web developer who values his time should begin debugging browser compatibility problems without first ensuring that the markup is at least syntactically valid—and any other invalid markup should have a good reason for being there.

(De altfel, stackoverflow.com nu reușește aceste două teste și sugestii pentru remedierea problemelor au fost refuzat .)

Cu toate acestea, pentru a răspunde la întrebarea dvs. specifică, probabil că nu merită să utilizați unul dintre doctypes XHTML dacă nu intenționați să produceți marcaj valid (sau cel puțin bine format). Avantajele principale ale XHTML sunt derivate din faptul că XHTML este XML, permițându-i să fie procesate și transformate prin instrumente și tehnologii care funcționează cu XML. Dacă nu intenționați să creați XML XHTML bine format, atunci este puțin important să alegeți doctype. Cea mai recentă specificație HTML 4 va face probabil tot ce aveți nevoie și este mult mai iertător.

0
adăugat
De asemenea, HTML4 (heck, chiar HTML5) vă permite să omiteți anumite elemente și să produceți încă o marcare validă (ceea ce este uneori imposibil în XHTML prin definiție). Este rareori necesar să utilizați marcarea nevalidă (poate pentru includerea de aplicații Flash sau Java în browsere vechi) oricum. Cel mai adesea este lipsa de curățenie sau lipsa de curățare după generarea HTML.
adăugat autor Alan Plum

Nu, nu ar trebui să utilizați XHTML dacă nu puteți garanta formarea bine dezvoltată și, în practică, nu o puteți garanta dacă nu utilizați serializatorul XML pentru a genera marcare. Citește despre producerea de XML .

Bineînțelesul este lucrul care diferențiază XHTML de HTML. XHTML cu eroare de markup "doar unul" încetează să mai fie XHTML. Trebuie să fie perfect de fiecare dată .

Dacă site-ul "XHTML" pare să funcționeze cu unele erori, este pentru că browserele ignoră pagina DOCTYPE și interpretează pagina ca HTML.

See XHTML proxy that forces interpretation of pages as XHTML. Most of the time they fail miserably. This is one of the reason why future of XHTML is uncertain and why development of HTML has been resumed.

0
adăugat

Deși cred în lupta pentru XHTML și CSS valabile, este adesea greu de făcut din mai multe motive.

  • În primul rând, o parte din conținut ar putea fi încărcat prin AJAX. Uneori, fragmentele nu sunt introduse corect în DOM existent.
  • Este posibil ca HTML-ul pe care îl vizualizați să nu fi fost produs în același document. De exemplu, pagina poate fi făcută din componente sau șabloane și apoi aruncată chiar înainte ca browser-ul să le facă. Aceasta nu este o scuză, dar nu puteți presupune că codul HTML pe care îl vedeți a fost codat manual în același timp.
  • Ce se întâmplă dacă o parte din codul generat de Markdown este nevalid? Nu puteți da vina pe suprapunerile de stive pentru a nu produce cod valid.
  • În cele din urmă, scopul DOCTYPE nu este să spui pur și simplu "Hei, eu folosesc cod valid", dar este de asemenea să dau browser-ului un cap în sus ceea ce încerci să faci astfel încât să se poată apropia cel puțin pentru a parsa corect aceste informații.

Nu cred că majoritatea dezvoltatorilor specifică un DOCTYPE și apoi nu reușesc să adere în mod explicit la acesta.

0
adăugat

Nu cred că, dacă specificați o doctype, există vreun motiv să nu aderați la acest doctype.

Utilizarea XHTML face detectarea automată a erorilor ușor, fiecare schimbare poate fi verificată automat pentru marcarea nevalidă. Acest lucru previne erorile, mai ales când utilizați conținut generat automat. Este foarte ușor pentru un dezvoltator web care utilizează un motor de template-uri (JSP, ASP.NET StringTemplate, etcetera) să copieze sau să lipsească o etichetă de închidere prea puțin sau prea multe. Atunci când aceasta este singura dvs. eroare, aceasta poate fi detectată și rezolvată imediat. Am lucrat o dată pentru un site care a avut 165 de erori de validare pe pagină, dintre care 2 sau 3 au fost bug-uri reale. Acestea erau greu de găsit în dezordinea altor erori. Validarea automată ar fi împiedicat aceste erori la sursă.

Inutil să spun că alegerea unui standard și lipirea acestuia nu pot beneficia niciodată de interoperabilitate cu alte sisteme (screpere, cititoare de ecran, motoare de căutare) și nu am întâlnit niciodată o situație în care o soluție XHTML semantică validă cu soluție CSS nu a fost posibilă pentru toți browserele majore.

Evident, atunci când lucrați cu sisteme complexe, nu este întotdeauna posibil să rămâneți la doctype dvs., dar acest lucru este în mare parte rezultatul unei comunicări necorespunzătoare între diferitele echipe care dezvoltă diferite părți ale acestor sisteme sau, cel mai probabil, sisteme vechi. În ultimul caz, probabil este mai bine să izolați aceste cazuri și să schimbați doctype-ul în consecință.

Este bine sa fii pragmatic si sa nu respecti XHTML doar pentru ca cineva a spus asta, indiferent de costuri, dar cu cunostintele actuale despre CSS si browsere, instrumente de testare si validare, cele mai multe ori beneficiile sunt mult mai mari decat costurile.

0
adăugat

Nu aș folosi XHTML deloc pentru a-mi salva stresul filosofic. Nu este ca orice browser care le tratează cum ar fi XHTML oricum.

Navigatorii vor respinge marja slabă dacă pagina este trimisă ca aplicație / xhtml + xml, dar acestea sunt rar. Este în regulă.

Aș fi mai preocupat de lucruri cum ar fi folosirea în linie a CSS și JavaScript cu Overflow de stivă, doar pentru că fac mai dificilă întreținerea.

0
adăugat

Ar trebui întotdeauna să încercăm să o facem validată conform standardelor. Vom fi siguri că site-ul Web va afișa și va funcționa bine pe browserele actuale și în browserele viitoare.

0
adăugat

Poți să spui că am o OCD pe valabilitate XHTML. Consider că majoritatea problemelor legate de codul care nu este valid provin de la programatori care nu cunosc diferența dintre HTML și XHTML. Am scris 100% valid XHTML și CSS acum sau nu și nu am avut niciodată probleme majore de redare cu alte browsere. Dacă păstrați totul valabil și nu încercați nimic exagerat css înțelept, vă veți salva o tona de timp în reparații.

0
adăugat