De ce este necesar un cod valid și cum să eliminați erorile de validare. Erori și validarea formularelor aplicației mobile Validarea câmpurilor dependente
Oamenii au tendința de a face greșeli. Erorile apar atunci când oamenii interacționează cu interfețe cu utilizatorul. Uneori, acest lucru se întâmplă deoarece utilizatorii greșesc. Uneori apar erori în aplicația în sine. Indiferent de cauză, erorile și gestionarea lor au un impact imens asupra UX. Gestionarea incorectă a erorilor împreună cu mesajele de eroare inutile poate provoca o reacție negativă în utilizator, ceea ce poate duce ulterior la refuzul utilizatorului de a utiliza aplicația dvs.
În acest articol, ne vom da seama cum să optimizăm designul aplicației pentru a preveni erori ale utilizatoruluiși cum să creați mesaje de eroare eficiente atunci când apar erori, indiferent de ceea ce introduce utilizatorul. De asemenea, ne vom uita la modul în care o greșeală bine gestionată poate transforma eșecul în încântare. Adobe a introdus o nouă aplicație de design și design, Experience Design (Adobe XD), care vă permite să proiectați designuri interactive și stări de eroare. Puteți descărca și încerca Adobe XD gratuit.
Ce este o condiție de eroare?O stare de eroare este un ecran care este afișat utilizatorului atunci când ceva nu a mers prost. Acesta este un exemplu de situație în care utilizatorul face ceva diferit de starea dorită. Deoarece erorile pot apărea în combinații neașteptate, aceste condiții pot include probleme de la operațiuni incompatibile ale utilizatorului (cum ar fi introducerea incorectă a datelor) până la incapacitatea unei aplicații de a se conecta la server sau chiar incapacitatea de a procesa o solicitare a utilizatorului.
Ecrane de eroare
Fiecare greșeală, indiferent de cauza ei, devine o piatră de poticnire pentru utilizator pe calea către progresul UX. Din fericire, o greșeală bine formatată poate reduce efectul neplăcut.
Prevenirea este mai bună decât vindecareaDacă construiți o aplicație, trebuie să înțelegeți ce interacțiuni de bază ale utilizatorului cu aplicația pot provoca o eroare. De exemplu, este de obicei foarte dificil să completați corect un formular la prima încercare sau este imposibil să sincronizați corect datele dacă dispozitivul are un nivel slab conexiune retea. Ar trebui să țineți cont de astfel de puncte pentru a minimiza posibilitatea apariției erorilor. Cu alte cuvinte, este mai bine să preveniți posibilitatea de a face greșeli dând sfaturi, folosind limite și fiind flexibil.
De exemplu, dacă oferiți oamenilor posibilitatea de a căuta și rezerva hoteluri, de ce să lăsați disponibile date din trecut și să aruncați o eroare dacă utilizatorul selectează data respectivă?
După cum se arată în exemplul Booking.com, puteți utiliza pur și simplu un selector de date care permite utilizatorilor să selecteze numai data de astăzi și datele viitoare. Acest lucru va încuraja utilizatorii să selecteze numai date valabile.
Selectarea datei în aplicația Booking.com. Este afișată luna completă, dar datele din trecut nu sunt disponibile. Ecran de eroare pentru validarea formularului Forma este comunicare. Ca orice comunicare, ea ar trebui să fie reprezentată de o comunicare consistentă între două părți - utilizatorul și aplicația dvs. Validarea joacă un rol major în acest proces de comunicare. Validarea formularelor este concepută pentru a ghida utilizatorii prin complicații, erori și neînțelegeri. Cu o validare adecvată, o astfel de comunicare devine clară și de înțeles. În general, validarea unei forme bune constă din patru elemente importante:
- Timpul corect pentru raportarea erorilor (sau finalizarea cu succes)
- Locul corect pentru mesajul de validare
- Culoarea corectă a mesajului
- Limba mesajului clar
Validarea erorilor de formular este inevitabilă și este o parte logică a introducerii datelor utilizatorului (deoarece introducerea datelor utilizatorului poate fi însoțită de erori). Desigur, condițiile care pot provoca o eroare ar trebui reduse la minimum, dar validarea erorilor nu poate fi eliminată. Deci, cea mai importantă întrebare este: „Cum pot face procesul de recuperare a erorilor mai ușor pentru utilizator?”
Utilizatorilor nu le place procesul de completare a unui formular, mai ales când primesc un mesaj de eroare la sfârșit. Este deosebit de frustrant să primești mesaje de eroare în mai multe câmpuri după ce ai completat un formular lung. Și cel mai enervant lucru este lipsa de claritate cu privire la ce greșeli ai făcut și unde.
Validarea ar trebui să informeze imediat utilizatorul despre corectitudinea unui răspuns dat imediat după ce utilizatorul a introdus datele. Principiul principal al validării bune este: „Vorbește cu utilizatorii! Spune-le ce este în neregulă!” iar validarea în timp real a șirurilor informează utilizatorii despre corectitudinea datelor introduse. Această abordare permite utilizatorilor să corecteze rapid erorile și să nu aștepte ca erorile să fie afișate după ce fac clic pe butonul de confirmare.
Cu toate acestea, ar trebui să evitați validarea fiecărei apăsări de taste, deoarece, în majoritatea cazurilor, nu veți putea valida datele înainte ca utilizatorul să termine de tastat răspunsul. Formularele care validează valoarea imediat în timpul tastării încep să enerveze utilizatorul de îndată ce acesta începe să introducă date.
Formulare Google afișează o eroare de e-mail chiar și atunci când nu ați terminat încă de tastat. Pe de altă parte, formularele care se validează după introducerea datelor nu informează utilizatorul suficient de repede despre o eroare.
Validarea în Apple Store are loc după introducerea datelor. Mihail Konzhevich în articolul său „Validarea șirurilor în formulare - crearea experienței! a explorat diferite strategii de validare și a propus o strategie hibridă: recompensa timpurie, pedeapsa tardivă.
Hibrid - Recompensă timpurie, Pedeapsă târzie - Abordare la locul potrivit Concentrarea utilizatorului este un alt instrument important. Când vă întrebați unde să plasați mesajul de validare, urmați acest sfat: Plasați întotdeauna mesajul în contextul unei acțiuni. Dacă doriți să spuneți utilizatorului despre o eroare într-un anumit câmp, afișați-o lângă acesta. Validarea rapidă este cel mai bine plasată în dreapta câmpului de introducere sau sub acesta.
Erori în formular în timp real. Culoarea potrivită (design intuitiv) Culoarea este una dintre cele mai bune instrumente pentru utilizare la crearea validării. modul în care funcționează la nivel intuitiv, culorile roșu pentru a indica o eroare, galben pentru a indica avertizare și verde pentru a indica succesul sunt deosebit de puternice. Dar, asigurați-vă că culorile sunt bine percepute de utilizatori. Acesta este un aspect critic al unui design vizual bun.
Textul de eroare trebuie să fie clar și să iasă în evidență clar pe fundalul aplicației. Ștergeți mesajul Un mesaj de eroare tipic ar putea spune „e-mailul este incorect”, fără a explica utilizatorului de ce e-mailul este incorect. (Tipografie? E-mail preluat de un alt utilizator?) Instrucțiuni sau îndrumări simple pot face lucrurile diferite. Puteți vedea în exemplu cum formularul informează utilizatorul că e-mailul său este deja preluat. De asemenea, apar mai multe sugestii (login sau recuperare parole).
Deci, este timpul să afișați o pagină de eroare pentru a arăta că ceva a mers prost. De exemplu, să ne imaginăm o situație în care conexiunea este pierdută și utilizatorul se află pe un ecran care este singurul disponibil. Ar trebui să folosești această ocazie pentru a informa oamenii ce se întâmplă și pentru a oferi un model de ajutor rapid - mesajul dvs. ar trebui să fie o mână de ajutor pentru utilizatori. Prin urmare, nu ar trebui să arătați niciodată următoarele:
- Mesaj de eroare critic. Mesajele care indică o eroare internă în codul aplicației sau care conțin text precum „a apărut o eroare de tip 2” sunt criptice și intimidante.
Un mesaj de eroare scris de un dezvoltator pentru un dezvoltator. - Eroare de blocare. Pur și simplu pentru că astfel de mesaje nu oferă niciunul Informatii utile pentru utilizator.
Ecranul de eroare de pe Spotify spune „A apărut o eroare” și nu oferă opțiuni sau pași pentru a rezolva problema. - Mesaj de eroare nespecificat. Acest ecran (în exemplul de mai jos) oferă utilizatorului aceeași cantitate de informații ca și cel precedent. Utilizatorii nu au idee ce înseamnă asta sau ce să facă în privința asta.
Aplicația Buffer are un mesaj de eroare frumos, dar nu oferă nicio informație utilizatorului. Nu speria utilizatorul cu erori. De asemenea, nu încercați să ghidați utilizatorul în detaliile tehnice ale problemei. Vorbiți despre eroare într-un limbaj simplu și ușor de înțeles. Pentru a face acest lucru, încercați să nu folosiți jargonul tehnic și să vă exprimați gândurile în limba utilizatorului.
Faceți mesajele dvs. lizibile și utile - erorile ar trebui să fie politicoase, clare și instructive și să conțină informații precum:
- Ce a mers prost și de ce (eventual).
- Ce ar trebui să facă utilizatorul pentru a remedia eroarea.
Aplicația Remote explică de ce utilizatorii nu pot vedea nimic și oferă o soluție. Includeți umor și imagini în mesajele de eroare Mesajele de eroare sunt o oportunitate excelentă de a folosi pictograme și ilustrații, deoarece oamenii pot înțelege mai bine informatii vizuale decât un simplu text. Dar puteți face un pas mai departe și puteți adăuga imagini în aplicația dvs. care vor fi utile utilizatorilor. Acest lucru vă va personaliza aplicația și vă va atenua mesajul.
Azendoo folosește ilustrația și umorul pentru a inspira utilizatorul să rezolve o problemă. Umorul prelungește viața. Puțin umor nu strică niciodată și va ajuta la atenuarea confuziei de a greși. Puteți găsi o mulțime de exemple de mesaje amuzante la Littlebigdetails. Iată câteva dintre preferatele mele:
- Basecamp: Când există o eroare de validare a formularului, eroul din stânga își face o expresie surprinsă pe față.
- Un mesaj de eroare ușor obositor este afișat atunci când încercați să introduceți prea multe perioade atunci când creați un cont nou în Gmail.
Cu toate acestea, fiți atenți la umor, deoarece s-ar putea să nu fie întotdeauna adecvat în raportul dvs. de eroare; depinde de gravitatea erorii. De exemplu, umorul funcționează bine pentru o problemă simplă de validare, cum ar fi o „eroare 404” (pagina nu a fost găsită). Dar când un utilizator petrece o anumită perioadă de timp uitându-se la o pagină care spune „Oh!” - pare nepotrivit.
Paginile de eroare bune sunt o mână de ajutor pentru utilizatori și ar trebui să îndeplinească următoarele șase criterii:
Scopul principal al unei pagini de eroare 404 este de a redirecționa utilizatorul către pagina pe care o căutau cât mai repede posibil. Pagina dvs. 404 ar trebui să ofere mai multe link-uri cheie unde utilizatorul poate accesa. Cea mai sigură opțiune este să ai un link către „ pagina principala” site la pagina 404. De asemenea, puteți plasa un „raportați o problemă” pentru a permite utilizatorului să vă anunțe că pagina nu funcționează. Dar asigurați-vă că trecerea la pagina de pornire este o tranziție mai clară și iese mai în evidență vizual.
Ecranul formularului de autentificare pare adesea minimalist și conține un câmp pentru introducerea unui nume de utilizator și un câmp pentru o parolă. Dar minimalismul nu este egal cu simplitatea. Există multe motive pentru care un utilizator ar putea rămâne blocat la ecranul de conectare. Regula principală a paginii de autentificare este să nu faci utilizatorul să ghicească.
Să ne uităm la soluții pentru cel mai mult probleme comune folosind exemple de la MailChimp, care face buna treaba mesajele de eroare de mai sus.
- Utilizatorul și-a uitat numele pe site. Dacă găsiți o eroare ca aceasta, ar trebui să oferiți un link unde utilizatorul o poate remedia. Spuneți utilizatorului de unde îl poate obține (de exemplu: „verificați-vă e-mailul, v-am trimis un e-mail”) sau furnizați un link pentru a restabili numele pe site.
Utilizatorii fac multe încercări de a se conecta pe site folosind o parolă greșită. Pentru a preveni astfel de atacuri de server, conturile de utilizator sunt blocate după prea multe încercări nereușite. Aceasta este o practică obișnuită de securitate, dar utilizatorul trebuie să fie avertizat înainte ca contul său să fie suspendat.
Un card de credit poate fi refuzat din mai multe motive: o eroare de formatare a datelor (o greșeală de tipar sau date lipsă) sau cardul poate fi refuzat deoarece este expirat sau furat. Gabriel Tomescu, în articolul său „Anatomia unui formular de card de credit”, a sugerat următoarea strategie pentru ambele erori:
Pentru prima problemă, ar trebui să urmați validarea standard a șirurilor și indicarea erorii vizuale:
Cu toate acestea, atunci când cardul de credit este refuzat sistem de plata din anumite motive, de obicei arată ca o răpire. Aveți nevoie de date clare de la utilizator. Și chiar și după aceea, mai trebuie să anunțați utilizatorul despre ceea ce s-a întâmplat; Mesajul de eroare trebuie să fie foarte clar.
Conexiunea la internet nu este disponibilă peste tot și asistența offline ar trebui să fie un aspect cheie în viața oricui aplicație modernă. Când conexiunea scade, trebuie să vă gândiți cu atenție la UX offline. Utilizatorii ar trebui să poată interacționa cu cât mai mult posibil din aplicația dvs. Aceasta înseamnă că aplicația trebuie să memoreze în cache conținutul pentru bine offline UX.
Etichete: , , ,Validarea este procesul de verificare a valorilor specificate de utilizator și de afișare a eventualelor erori găsite.
PrincipiiSarcina designerului este să se asigure că utilizatorul nu greșește și nu este necesară validarea, pentru aceasta:
Validarea pe un formular gol nou deschis nu este permisă. Excepție fac schițele, când utilizatorul a completat deja acest formular, a revenit la el după ceva timp și a fost completat cu erori.
Tipuri de validareExistă trei tipuri de validări: instantanee, când focalizarea este pierdută și când formularul este trimis.
Cu cât interfața raportează mai devreme o eroare, cu atât mai bine - este mai ușor pentru utilizator să revină și să corecteze eroarea.
Cel mai cale rapidă raportați o eroare - validare instantanee. Dar este posibil numai în cazurile în care în timpul procesului de introducere este clar că valoarea este incorectă. De obicei, astfel de erori sunt asociate cu dispunerea incorectă a tastaturii (chirilic în loc de latină) sau introducerea de litere într-un câmp numeric (TIN, KPP etc.) Pentru aceste cazuri, folosim câmpuri cu măști: introducerea de caractere neadecvate în ele este blocată. Prin urmare, în interfețele noastre există doar două tipuri de validare:
- prin pierderea focalizării – principalul tip de validare
- prin depunerea formularului – pentru acele cazuri în care validarea din cauza pierderii focalizării este imposibilă.
Nu validați câmpurile pentru golire din cauza pierderii focalizării - nu afișați o eroare dacă câmpul nu este completat, poate că utilizatorul va reveni și va completa câmpul puțin mai târziu. În astfel de cazuri, puteți afișa eroarea numai după trimiterea formularului.
Validarea se declanșează imediat după pierderea focalizării dacă valoarea din câmp este completată. Dacă se găsește o eroare, câmpul este evidențiat cu roșu. Focalizarea nu revine automat la acest câmp:
Textul de eroare apare în sfatul explicativ atunci când câmpul primește hover sau focalizare:
Un câmp de eroare ar trebui să rămână evidențiat dacă a primit focalizare, valoarea sa nu a fost corectată și apoi a pierdut focalizarea.
Evidențierea roșie este eliminată din câmp de îndată ce utilizatorul începe să corecteze valoarea eronată.
Validare la trimiterea formularului Când se utilizeazăUtilizați acest tip de validare atunci când câmpurile nu pot fi validate din cauza pierderii focalizării. De exemplu, pentru a verifica dacă câmpurile obligatorii sunt completate.
Cum functioneazãVerificarea are loc după ce utilizatorul a apăsat butonul de trimitere: toate câmpurile cu erori din formular sunt evidențiate, pagina derulează la primul câmp cu o eroare, focusul se mută la acest câmp, cursorul se deplasează la sfârșitul rândului și lângă câmp apare un sfat cu un indiciu.
Când derulați la primul câmp de la marginea de sus a ferestrei la câmpul de eroare, există o marjă de 48px - șase unități.
Blocarea butonului de trimitere În formularele mici, în loc să verificați dacă câmpurile obligatorii sunt completate, puteți bloca butonul de trimitere a formularului. Utilizați acest comportament atunci când este evident de ce butonul de trimitere al formularului este inactiv. De exemplu, pe formularul de conectare:
Imediat ce toate câmpurile obligatorii sunt completate, butonul devine activ. Dacă după aceasta utilizatorul șterge valoarea dintr-unul dintre câmpuri, butonul ar trebui să devină din nou inactiv.
Mesaje de eroareErorile pot fi raportate în două moduri:
Sfaturi instrumente Cum funcționează Un balon explicativ cu un balon explicativ apare în două cazuri:
Dacă valoarea dintr-un câmp cu o eroare a fost modificată, a pierdut focalizarea și apoi a devenit din nou focalizată, balonul cu textul vechii erori nu mai apare. Această regulă funcționează la fel pentru toate tipurile de validări: atât atunci când focalizarea este pierdută, cât și când este trimis formularul.
Balonul instrument de trecere cu mouse-ul se suprapune balonul explicativ de focalizare.
Indicatorul poate apărea în partea de sus sau în dreapta comenzii cu o eroare, astfel încât să nu se suprapună cu informații utile:
Uniformitatea comportamentului şi aspect
Afișați sfaturi cu instrumente în partea dreaptă a câmpurilor. Dacă în acest caz se suprapun conținut important de pe pagină, afișați sfaturile cu instrumente în partea de sus. Rămâneți la consecvență, dar amintiți-vă că conținutul este mai important decât conținutul.
Texte roșii pe pagina Cum funcționeazăTextul roșu de eroare apare imediat după ce a avut loc validarea și câmpul eronat este evidențiat.
De îndată ce utilizatorul începe să corecteze valoarea, evidențierea roșie a câmpului dispare și culoarea textului de eroare se schimbă în - #333.
Textul de eroare dispare când focalizarea este pierdută și nu apare din nou dacă câmpul își recapătă focalizarea. Această regulă funcționează la fel pentru toate tipurile de validări: atât atunci când focalizarea este pierdută, cât și când este trimis formularul.
Afișați textul de eroare din dreapta dacă există spațiu pe formular și mesajul în sine este scurt. În acest fel, nu trebuie să extindeți formularul pentru a afișa eroarea.
Dacă nu există loc pentru text în partea dreaptă a câmpului, extindeți formularul și afișați mesajul sub câmp.
În formularele mai complexe, afișați un mesaj de eroare în balonul explicativ.
Validarea câmpurilor dependenteCâmpurile dependente sunt câmpuri a căror valoare depinde una de alta.
Afișăm erori care sunt legate de încălcările dependenței de câmp după trimiterea formularului. De exemplu, TIN și punct de control. Dacă utilizatorul a specificat un TIN din 10 cifre și a lăsat câmpul punct de control gol, după trimiterea formularului câmpul gol al punctului de control va fi evidențiat.
TIN poate fi de două tipuri:
- 10 cifre y entitati legale
- 12 cifre pentru antreprenorii individuali.
Dacă utilizatorul a indicat un TIN din 12 cifre, atunci organizația este un antreprenor individual și nu are un punct de control, ceea ce înseamnă că nu este nevoie să completați câmpul punct de control. Și invers, dacă punctul de control este completat, dar TIN-ul are 12 cifre, TIN-ul poate fi indicat incorect.
Evidențierea câmpurilor dependente dispare de îndată ce utilizatorul începe să corecteze valoarea într-unul dintre aceste câmpuri.
Dacă formatul valorii este incorect atunci când completați un câmp dependent, raportați eroarea când pierdeți focalizarea. De exemplu, utilizatorul a introdus 3 cifre în câmpul TIN și a eliminat focalizarea. Un astfel de câmp ar trebui evidențiat imediat.
ExempluExistă un formular cu 5 câmpuri:
- Numele organizației - text simplu, obligatoriu
- TIN - 10 sau 12 cifre, verificare suma de control pentru pierderea focalizării, obligatoriu
- Punct de control - 9 cifre cu verificarea sumei de control pentru pierderea focalizării, obligatoriu dacă TIN-ul este format din 10 cifre
- E-mail - adresă de e-mail, verificați pierderea focalizării folosind mască [email protected], optional
- Telefon - format internațional, verificați pierderea focalizării folosind mască +00000000000, obligatoriu
Nimic nu este mai obositor decât completarea unui formular de lead-uri prost conceput. pagina de destinație. Amintiți-vă de câte ori a trebuit să completați toate câmpurile pentru că parola cu care ați venit nu se potrivea cu sistemul după anumite criterii despre care nimeni nu a încercat să vă anunțe în prealabil.
Rețineți că optimizarea formularului de clienți potențiali este o componentă cheie a procesului de optimizare a conversiilor, iar accentul principal aici ar trebui să fie pe validarea pe teren.
Ce este validarea formularului de clienți potențiali?
Validarea formularului de lead-uri este un proces tehnic în timpul căruia sistemul verifică acuratețea datelor introduse de utilizator. Dacă o persoană a făcut o greșeală la completarea formularului (de exemplu, datele indicate într-un format greșit), sistemul îi va indica această eroare (sau pur și simplu prezența acesteia) și se va oferi să o corecteze. Dacă utilizatorul a introdus corect toate datele, atunci nu vor apărea mesaje suplimentare (sau va apărea o bifă lângă câmp) și va trece la următoarea etapă de înregistrare.
De exemplu, Twitter nu vă va permite să treceți la următoarea etapă de înregistrare dacă introduceți adresa E-mailîn format greșit:
Când introduceți adresa dvs. de e-mail în formatul cerut de sistem, lângă câmp va apărea o bifă care indică faptul că formatul datelor introduse este corect:
Esența validării este să se asigure că utilizatorii introduc date în formatul cerut de sistem (de exemplu, adresa de e-mail trebuie să respecte standardul [email protected], dar, de exemplu, parola trebuie să conțină cel puțin 7 caractere).
Există două tipuri principale de formulare de validare.
Analiza erorilor de validare a site-ului
În cele din urmă, am avut ceva timp liber între șirul nesfârșit de comenzi și am decis să-mi încep blogul. Să încercăm să o îmbunătățim din punct de vedere al validării. Mai jos în articol vă voi spune ce este validarea site-ului, cod htmlși CSS, de ce este necesar și cum să aduceți un site la standarde folosind un exemplu specific.
Ce este validarea site-ului?
Cu cuvinte simple, acesta este un test de conformitate cu standardele. Pentru ca orice browser să vă poată afișa corect site-ul. Valabilitatea site-ului nu are un impact mare asupra promovării, dar cu siguranță nu va înrăutăți lucrurile.
Un exemplu specific de trecere a validării pentru o pagină de site web
Să luăm prima pagină care apare pe site-ul meu web - codificarea și decodarea Base64 în Java 8. Să introducem adresa paginii în validator și să ne uităm la rezultat:
Erori găsite la verificarea acestui document ca HTML 4.01 Tranzițional! Rezultat: 105 erori, 67 avertisment(e) Da, imaginea care apare este neplăcută: mai mult de o sută de erori și 67 avertismente - cum îmi indexează motoarele de căutare blogul și oamenii îl vizitează? Dar să nu ne supărăm, ci să învățăm cum să trecem la validare și să corectăm greșelile. Deci, primul avertisment:
Nu se poate determina modul de analiză! Validatorul poate procesa documente fie ca XML (pentru tipuri de documente precum XHTML, SVG etc.) sau SGML (pentru HTML 4.01 și versiunile anterioare). Pentru acest document, informațiile disponibile nu au fost suficiente pentru a determina modul de analizare fără ambiguitate, deoarece: Tipul MIME Media (text/html) poate fi utilizat pentru tipurile de document XML sau SGML. Nici un tip de document cunoscut nu a putut fi detectat. poate fi găsit la începutul documentului. Nu a putut fi găsit niciun spațiu de nume XML (de ex.) la rădăcina documentului. În mod implicit, validatorul revine la modul SGML. Avertisment Nu a fost găsit niciun DOCTYPE! Verificarea cu HTML 4.01 Tranzitional Document Type. Nicio declarație DOCTYPE nu a putut fi găsită sau recunoscută în acest document. Acest lucru înseamnă, în general, că documentul nu își declară tipul de document în partea de sus. De asemenea, poate însemna că declarația DOCTYPE conține o eroare de ortografie sau că nu folosește sintaxa corectă. Documentul a fost verificat folosind o definiție implicită a tipului de document „de rezervă” care seamănă foarte mult cu „HTML 4.01 de tranziție”. Este la fel. Și remedierea este simplă: adăugați eticheta chiar la începutul paginii:
Să verificăm ce am făcut și să vedem că cu această etichetă am eliminat 105 de erori și 3 avertismente! Acum mai avem doar 64 de avertismente. Să începem să le desfacem unul câte unul.
Avertisment: Atributul type pentru elementul de stil nu este necesar și trebuie omis. De la rândul 5, coloana 1; la rândul 5, coloana 23 /x-icon">↩↩↩↩↩A Aceasta înseamnă că elementul de stil nu are nevoie de un atribut tip - este de prisos. Avem două astfel de comentarii pe pagină. Un avertisment similar se aplică JavaScript:
Avertisment: atributul type nu este necesar pentru resursele JavaScript. De la rândul 418, coloana 1; la rândul 418, coloana 31 ↩↩$(doc Avem 8 astfel de erori. Îndepărtăm aceste atribute și urează - încă 10 avertismente mai puțin!
Eroare: CSS: background: primul argument al funcției de gradient liniar ar trebui să fie în sus, nu în sus. La linia 39, coloana 61 0%,#E8E8E8 100%);↩ border-r Următoarea greșeală este că primul argument al liniar-gradient ar trebui să fie în sus, nu în sus. O vom repara. Următoarea eroare:
Eroare: CSS: Eroare de analiză. De la rândul 65, coloana 13; la linia 65, coloana 16 margine: 0 auto;↩padd Aici am comentat incorect css. Trebuie doar să eliminați această linie. Sau comentați /* și */ diferit. Am făcut-o așa cum făceam înainte.
Eroare: CSS: @import nu sunt permise după orice instrucțiune validă, alta decât @charset și @import.. La linia 88, coloana 74 0,600,700,300);↩@import url(// Acum avem o eroare de import. Să mutăm aceste linii la chiar la începutul fișierului și acesta va dispărea.
Eroare: Valoare greșită _blanck pentru atributul țintă pe elementul a: cuvânt cheie rezervat gol folosit. De la rândul 241, coloana 218; la linia 241, coloana 295 cookie..php?id=98" target="_blanck" style="display: inline;">Aici În continuare, nu ne place valoarea atributului target, ni se spune că avem nevoie pentru a folosi „blank” fără liniuța de subliniere în față Să-l eliminăm.
Eroare: Eticheta de final a fost văzută, dar erau elemente deschise. De la rândul 379, coloana 2; la rândul 379, coloana 6
- ↩ ↩↩
↩
↩↩↩↩