Filvalideringsfel. Lead Form Validering - Den kompletta guiden. Enhetligt beteende och utseende

Lämna en kommentar 6,950

Människor tenderar att göra misstag. Buggar uppstår när människor interagerar med användargränssnitt. Ibland händer detta för att användare gör misstag. Ibland uppstår fel i själva applikationen. Oavsett orsak har fel och deras hantering en enorm inverkan på UX. Felaktig felhantering, tillsammans med värdelösa felmeddelanden, kan orsaka en negativ reaktion från användaren, vilket i efterhand kan leda till att användaren överger din ansökan.

I den här artikeln kommer vi att utforska hur du kan optimera din applikationsdesign för att förhindra användarfel och hur du skapar effektiva felmeddelanden om fel uppstår oavsett vad användaren matar in. Vi ska också titta på hur ett väl hanterat misstag kan förvandla misslyckande till beundran. Adobe har introducerat en ny design- och utvecklingsapplikation, Experience Design (Adobe XD), som låter dig designa interaktiva projekt och feltillstånd. Du kan ladda ner och prova Adobe XD gratis.

Vad är ett feltillstånd?

Ett feltillstånd är en skärm som visas för användaren när något har gått fel. Detta är ett exempel på en situation där användaren gör något som skiljer sig från det önskade tillståndet. Eftersom fel kan uppstå i oväntade kombinationer kan dessa tillstånd innefatta problem som sträcker sig från inkonsekventa användaroperationer (som felaktig inmatning) till att ett program inte kan ansluta till en server eller till och med inte kan behandla en användarförfrågan.

Skärmar med fel

Varje misstag, oavsett orsak, blir en stötesten för användaren på sin UX-resa. Lyckligtvis kan ett välformaterat fel minska den obehagliga effekten.

Att förebygga är bättre än att bota

Om du bygger en applikation måste du förstå vilka är de viktigaste användarinteraktionerna med applikationen som kan leda till ett fel. Till exempel är det vanligtvis väldigt svårt att fylla i ett formulär korrekt vid första försöket, eller så är det omöjligt att synkronisera data korrekt om enheten har en dålig nätverksanslutning. Du måste överväga sådana punkter för att minimera risken för fel. Det är med andra ord bättre att förhindra möjligheten att göra fel genom att visa tips, använda restriktioner och flexibilitet.

Till exempel, om du tillåter människor att söka och boka hotell, varför lämna tillgängliga datum i det förflutna och skicka ett felmeddelande om användaren väljer ett sådant datum?

Som visas i exemplet på Booking.com kan du helt enkelt använda en datumväljare som tillåter användare att endast välja dagens datum och datum i framtiden. Detta kommer att uppmuntra användare att endast välja giltiga datum.

Datumväljare i Booking.com-appen. Hela månaden visas, men tidigare datum är inte tillgängliga.

Felskärm för formulärvalidering

Form är kommunikation. Som all kommunikation bör det vara en seriell kommunikation mellan två parter - användaren och din applikation. Validering spelar en stor roll i denna kommunikationsprocess. Formulärvalidering är utformad för att vägleda användare genom komplexitet, fel och missförstånd. Med korrekt validering blir sådan kommunikation tydlig och begriplig. Generellt sett består god formvalidering av fyra viktiga element:

Rätt tidpunkt att informera om fel (eller framgångsrikt slutförande)
Rätt plats för valideringsmeddelande
Korrekt meddelandefärg
Tydligt meddelandespråk

Korrekt tid (strängvalidering)

Validering av formulärfel är oundvikligt och är en logisk del av användarinmatning (eftersom användarinmatning kan vara felbenägen). Naturligtvis bör tillstånd som kan orsaka ett fel minimeras, men felvalidering kan inte tas bort. Så den viktigaste frågan är: "Hur förenklar man felåterställningsprocessen för användaren?"

Användare gillar inte processen att fylla i ett formulär, särskilt när de får ett felmeddelande i slutet. Det är särskilt frustrerande att få ett felmeddelande i flera fält efter att ha fyllt i ett långt formulär. Och mest irriterande är otydligheten om vilka misstag du gjort och var.

Validering bör omedelbart informera användaren om riktigheten av det givna svaret omedelbart efter att användaren har angett uppgifterna. Huvudprincipen för god validering är: ”Prata med användare! Berätta för dem vad som är fel!" och strängvalidering i realtid informerar användarna om riktigheten av de inmatade uppgifterna. Detta tillvägagångssätt tillåter användare att snabbt korrigera fel och inte vänta på att fel ska visas efter att ha tryckt på bekräftelseknappen.

Du bör dock undvika att validera varje tangenttryckning eftersom du i de flesta fall inte kommer att kunna verifiera data innan användaren har skrivit klart sitt svar. Formulär som validerar ett värde när de skriver börjar irritera användaren så fort de börjar mata in data.

Google Formulär visar ett e-postfel även när du inte har skrivit klart ännu.

Å andra sidan, formulär som valideras efter datainmatning informerar inte användaren tillräckligt snabbt om felet.

Validering i Apple Store utförs efter datainmatning.

Mikhail Konzhevich i sin artikel "Strängvalidering i former - skapa upplevelse! utforskade olika valideringsstrategier och föreslog en hybridstrategi: tidig belöning, sen bestraffning.

Hybrid - tidig belöning, sent straff - tillvägagångssätt

Rätt plats

Användarorientering är ett annat viktigt verktyg. När du undrar var du ska placera ditt valideringsmeddelande, följ detta råd: placera alltid meddelandet i sammanhanget för en åtgärd. Om du vill berätta för användaren om ett fel i ett specifikt fält, visa det bredvid. Snabbvalidering är bäst placerad till höger om inmatningsfältet, eller under det.

Fel i formuläret i realtid.

Korrekt färg (intuitiv design)

Färg är ett av de bästa verktygen att använda när du skapar en validering. i hur det fungerar på en intuitiv nivå, är röd för fel, gul för varning och grön för framgång särskilt kraftfulla. Men se till att färgerna uppfattas väl av användarna. Detta är en kritisk aspekt av bra visuell design.

Feltexten ska vara tydlig och tydligt sticka ut mot bakgrunden av ansökan.

tydligt budskap

Ett typiskt felmeddelande kan säga "e-post är ogiltig" utan att förklara för användaren varför e-postmeddelandet är ogiltigt. (Typografi? Är e-postmeddelandet upptaget av en annan användare?) Enkla instruktioner eller riktlinjer kan göra saker annorlunda. Du kan se i exemplet hur formuläret informerar användaren om att hans e-post redan har tagits. Dessutom visas flera förslag (inloggning eller lösenordsåterställning).

Så det är dags att visa en felsida för att visa att något gick fel. Som ett exempel, låt oss föreställa oss en situation där anslutningen är nere och användaren är på en skärm som är den enda tillgängliga. Du bör använda den här möjligheten för att låta folk veta vad som händer och tillhandahålla en snabb hjälpmodell - ditt meddelande bör vara en hjälpande hand för användarna. Därför bör du aldrig visa följande:

Kritiskt felmeddelande. Meddelanden som talar om ett internt fel i applikationskoden eller innehåller text som: "ett typ 2-fel har inträffat" är kryptiska och skrämmande.

Ett felmeddelande skrivet av en utvecklare för en utvecklare.

Återvändsfel. Helt enkelt för att sådana meddelanden inte ger någon användbar information till användaren.

Felskärmen på Spotify säger "Ett fel har inträffat" och innehåller inga alternativ och steg för att lösa problemet.

Ospecificerat felmeddelande. En sådan skärm (i exemplet nedan) ger användaren lika mycket information som den tidigare. Användare har ingen aning om vad detta betyder eller vad de ska göra åt det.

Buffer-appen har ett trevligt felmeddelande, men den ger ingen information till användaren.

Skrämma inte användaren med fel. Försök inte heller leda användaren in i de tekniska detaljerna kring problemet. Prata om felet på ett enkelt och begripligt språk. För att göra detta, försök att inte använda teknisk jargong och uttrycka dina tankar på användarens språk.

Gör dina inlägg läsbara och användbara - fel ska vara artiga, tydliga och lärorika och innehålla information som:

Vad gick fel och varför (förmodligen).
Vad ska användaren göra för att åtgärda felet.

Remote-appen förklarar varför användare inte kan se någonting och erbjuder en lösning.

Inkludera humor och bilder i felmeddelanden

Felmeddelanden är ett utmärkt tillfälle att använda ikoner och illustrationer eftersom människor uppfattar visuell information bättre än bara text. Men du kan gå ännu längre och lägga till bilder till din applikation som kommer att vara användbara för användarna. Detta kommer att anpassa din app och mjuka upp ditt budskap.

Azendoo använder illustration och humor för att inspirera användaren att lösa ett problem.

Humor förlänger livet. Lite humor skadar aldrig och hjälper till att lindra förvirringen av ett misstag. Du kan hitta massor av exempel på roliga meddelanden på Littlebigdetails. Här är några av mina favoriter:

Basecamp: När formulärvalideringen misslyckas gör tecknet till vänster ett förvånat uttryck.

Ett lite fräckt felmeddelande visas när du försöker ange för många punkter när du skapar ett nytt Gmail-konto.

Var dock försiktig med humor eftersom det kanske inte alltid är lämpligt i ditt felmeddelande; det beror på hur allvarlig felet är. Till exempel fungerar humor bra för ett enkelt valideringsproblem som "404-fel" (sidan hittades inte). Men när en användare ägnar en viss tid åt att titta på en sida som säger "Oh!" – det ser malplacerat ut.

En omfattande checklista för den perfekta felsidan

Bra felsidor är en hjälpande hand för användare och måste uppfylla följande sex kriterier:

Felmeddelandet visas dynamiskt omedelbart efter att ett fel har upptäckts. Det bör informera användaren om problemet.
Var säker för inmatade data. Din applikation ska inte bryta, radera eller ångra det som användaren har angett eller laddat upp vid den tidpunkt då felet uppstod.
Prata med användaren på samma språk. Budskapet ska ge en tydlig förståelse för vad som gick fel och varför; vad ska användaren göra för att rätta till felet?
Chocka eller förvirra inte användare. (Meddelandet ska inte vara för provocerande).
Tappa inte kontrollen över systemet. (Om problemet inte är kritiskt bör användaren kunna komma åt resten av programmet).
Använd ditt sinne för humor för att mildra problemet.

Lösningar för de mest populära felen

404-fel (sidan hittades inte)

Huvudsyftet med en 404-felsida är att omdirigera din användare till sidan de letade efter så snart som möjligt. Din 404-sida bör erbjuda flera nyckellänkar dit användaren kan gå. Det säkraste alternativet är att ha en länk till webbplatsens "hemsida" på 404-sidan. Du kan också lägga in ett "rapportera ett problem" för att användaren ska meddela dig att sidan är nere. Men se till att övergången till huvudsidan är mer av en tydlig övergång och sticker ut mer visuellt.

Inloggningsproblem

Inloggningsformulärsskärmen ser ofta minimalistisk ut och innehåller ett användarnamnsfält och ett lösenordsfält. Men minimalism är inte lika med enkelhet. Det finns många anledningar till att en användare kan fastna på inloggningsskärmen. Huvudregeln för inloggningssidan - få inte användaren att gissa.

Låt oss titta på lösningar på de vanligaste problemen med hjälp av exempel från MailChimp, som gör ett bra jobb med felmeddelanden.

Användaren har glömt sitt namn på sajten. Om du hittar ett liknande fel bör du tillhandahålla en länk där användaren kan fixa det. Berätta för användaren var han kan få det (till exempel: "kolla din e-post, vi har skickat ett e-postmeddelande till dig") eller ange en länk för att återställa namnet på webbplatsen.

Användare gör många försök att komma in på webbplatsen med fel lösenord. För att förhindra sådana serverattacker blockeras användarkonton efter för många misslyckade försök. Detta är en vanlig säkerhetspraxis, men användaren måste varnas innan deras konto blockeras.

Kreditkortsavvisning

Ett kreditkort kan avvisas av flera skäl: ett dataformateringsfel (stavfel eller saknade data) eller ett kort kan avvisas på grund av att det har gått ut eller blivit stulet. Gabriel Tomescu föreslog i sin artikel Anatomy of a Credit Card Shape följande strategi för båda felen:

För det första problemet bör du följa standardsträngvalidering och visuell felindikering:

Men när ett kreditkort avvisas av en betalningsprocessor av någon anledning ser det vanligtvis ut som en kidnappning. Du behöver tydlig information från användaren. Och även efter det behöver du fortfarande meddela användaren vad som hände; felmeddelandet bör vara mycket tydligt.

Anslutningsproblem

Internetanslutning är inte tillgänglig överallt och offlinesupport bör vara en nyckelaspekt i livet för alla moderna applikationer. När anslutningen sjunker måste du tänka noga på ditt offline-UX. Användare ska kunna interagera med så mycket av din applikation som möjligt. Detta innebär att appen måste cachelagra innehåll för ett bra offline-UX.

Taggar: , , ,

Validering är en av de viktigaste aspekterna av bra webbdesign. Låt oss titta på vad det är och hur man kontrollerar HTML-koden för giltighet. Som ett exempel, låt oss ta det vanligaste innehållshanteringssystemet (CMS) – WordPress. Efter det kommer vi att dela en lista över fel som vi stött på i praktiken och, viktigast av allt, vi kommer att erbjuda våra egna, beprövade metoder för att eliminera dem.

Varför är det nödvändigt att kontrollera webbplatsens giltighet

Enkelt uttryckt, en kontroll av en webbsida kommer att avgöra om den överensstämmer med de standarder som utvecklats av World Wide Web Consortium (W3C). Detta görs vanligtvis genom att kontrollera enskilda sidor för giltighet med hjälp av W3C:s onlinevalideringstjänst.

Precis som grammatikregler på olika språk finns det även regler inom programmering. Validering låter dig se om sidan följer dessa regler, och om det finns fel och varningar kommer rekommendationer att tillhandahållas för att eliminera dem. Mer detaljer om behovet av en sådan kontroll kommer att diskuteras nedan.

Vad påverkar sajtens giltighet

Har du någonsin undrat hur webbläsare "läser" en webbsida? De har "motorer" för att analysera koden och omvandla den till en visuell form för människor. Tyvärr har varje webbläsare sin egen kodhanteringsmekanism, och detta kan göra att dina sidor visas annorlunda.

En ogiltig webbsida kan läsas av webbläsare på olika sätt. Detta kommer att resultera i att dina besökare kanske inte ens kan se innehållet på sidan korrekt i sina webbläsare. Validering kommer senare att korrigera nästan alla större skillnader och göra din webbsida läsbar av nästan alla webbläsare (äldre versioner av Internet Explorer är det vanligaste undantaget). Det är härifrån termen "layout över webbläsare" kom ifrån. layout som är lika bra (kompatibel) för alla populära webbläsare.

Hur kommer detta att påverka SEO? Det är viktigt att förstå att sökmotorrobotar älskar semantiska webbsidor. Semantisk layout, enligt Wikipedia, är ett tillvägagångssätt för att skapa HTML-webbsidor baserade på användningen av HTML-taggar i enlighet med deras semantik (syfte). Dessutom tillåter en strukturell semantisk webbsida sökrobotar att mer exakt bestämma betydelsen av både enskilda delar av en webbsida och hela texten som helhet. Enligt Google påverkar inte en giltig kod sidrankningen på något sätt. Men samtidigt kan förekomsten av fel i koden negativt påverka skanningen av mikrodata och anpassningsförmågan till mobila enheter.

Verifieringsverktyg för din webbplats

För att förstå behovet av frånvaron av valideringsfel på webbplatsens sidor, låt oss titta på hur man söker efter dessa fel.

Det finns många gratis webbvalideringstjänster som W3C Markup Validation Service, Web Page Analyzer, Browsershots och andra.

Det finns inget tråkigare än att fylla i ett dåligt skrivet formulär för potentiella kunder på en målsida. Kom ihåg hur många gånger du var tvungen att fylla på alla fält på grund av att lösenordet du kom fram till inte passade systemet enligt vissa kriterier, vilket ingen försökte meddela dig om i förväg.

Tänk på att optimering av potentiella kunder är en nyckelkomponent i koch fokus här bör ligga på fältvalidering.

Vad är validering av leadformulär?

Validering av formulär för potentiella kunder är en teknisk process under vilken systemet kontrollerar riktigheten av de uppgifter som användaren har angett. Om en person gjorde ett misstag när han fyllde i formuläret (till exempel skrev han in uppgifterna i fel format), kommer systemet att påpeka för honom detta fel (eller helt enkelt dess närvaro) och erbjuda att rätta till det. Om användaren angav alla uppgifter korrekt, kommer inga ytterligare meddelanden att visas (eller en bock visas bredvid fältet), och han fortsätter till nästa steg av registreringen.

Till exempel kommer Twitter inte att tillåta dig att gå vidare till nästa registreringssteg om du anger en e-postadress i fel format:

När du anger e-postadressen i det format som systemet behöver visas en bock bredvid fältet som indikerar att formatet på de angivna uppgifterna är korrekt:

Kärnan i valideringen är att säkerställa att användare anger data i det format som krävs av systemet (till exempel måste e-postadressen överensstämma med standarden [e-postskyddad], men lösenordet måste till exempel innehålla minst 7 tecken).

Det finns två huvudtyper av formulärvalidering.

Validering är validering av användarspecificerade värden och visning av hittade fel.

Principer

Designerns uppgift är att se till att användaren inte gör ett misstag och att validering inte behövs, för detta:

Begränsa urvalet av uppenbart felaktiga värden i listan: blockera dessa värden eller visa dem inte i listan.
Begränsa inmatningen av olämpliga tecken. Om ett fält kräver att endast siffror anges och det är uppenbart för användaren, ignorera bokstäverna istället för att visa ett fel. Använd jokertecken i fält där formatet är känt för värdena.
Skriv uppmaningar för att fylla i formuläret. Till exempel en platshållare i inmatningsfält.

Validering på en nyöppnad tom blankett är förbjuden. Ett undantag är utkast, när användaren redan har fyllt i detta formulär, efter en tid återvände han till det, och det var fyllt med fel.

Typer av validering

Det finns tre typer av valideringar: omedelbar, vid förlust av fokus och vid inlämning av formulär.

Ju tidigare gränssnittet rapporterar ett fel, desto bättre – det är lättare för användaren att gå tillbaka och åtgärda felet.

Det snabbaste sättet att rapportera ett fel är omedelbar validering. Men det är endast möjligt i de fall då det är klart under inmatningsprocessen att värdet är felaktigt. Typiskt är sådana fel associerade med en felaktig tangentbordslayout (kyrillisk istället för latin) eller inmatning av bokstäver i ett numeriskt fält (TIN, KPP, etc.) I dessa fall använder vi fält med masker: inmatning av olämpliga tecken i dem blockeras . Därför finns det bara två typer av validering i våra gränssnitt:

genom förlust av fokus- den huvudsakliga typen av validering
vid inlämning av formulär- för de fall då validering genom förlust av fokus inte är möjlig.

Validering av fokusförlust

När ska användas

Hur fungerar det

Validera inte att fält är tomma vid förlust av fokus - visa inte ett fel om fältet är tomt, användaren kan komma tillbaka och fylla i fältet lite senare. I sådana fall kan du visa ett fel först efter att du har skickat in formuläret.

Validering utlöses omedelbart efter att fokus tappats, om värdet i fältet är ifyllt. Om ett fel hittas markeras fältet i rött. Fokus återgår inte automatiskt till detta fält:

Feltexten visas i verktygstipset när fältet håller muspekaren eller fokuseras:

Ett fält med ett fel ska förbli markerat om det fick fokus, dess värde inte korrigerades och sedan tappade fokus.

Den röda markeringen tas bort från fältet så snart användaren har börjat korrigera det felaktiga värdet.

Validering av formulärinlämning

När ska användas

Använd den här typen av validering när du inte kan validera fält vid förlust av fokus. Till exempel för att kontrollera om obligatoriska fält är ifyllda.

Hur fungerar det

Kontrollen sker efter att användaren har tryckt på knappen Skicka data: alla fält med fel i formuläret är markerade, sidan rullar till det första fältet med ett fel, fokus flyttas till detta fält, markören flyttas till slutet av raden , visas ett verktygstips med en ledtråd bredvid fältet.

Att rulla till det första fältet från fönstrets övre kant till det felaktiga fältet lämnar ett indrag på 48px - sex enheter.

Blockerar knappen Skicka

I små formulär, istället för att markera de obligatoriska fälten, kan du blockera formulärets skicka-knapp. Använd det här beteendet när det är uppenbart varför formulärets skicka-knapp är inaktiverad. Till exempel på inloggningsformuläret:

Så snart alla obligatoriska fält är ifyllda blir knappen aktiv. Om användaren efter det har raderat värdet i ett av fälten, bör knappen bli inaktiv igen.

Felmeddelanden

Fel kan rapporteras på två sätt:

Verktygstips

Hur de fungerar

Tipset verktygstips visas i två fall:

När du håller muspekaren över ett fält med ett fel.
När fältet med felet får fokus.

Om värdet i fältet med felet ändrades, tappade fokus och sedan fick fokus igen, visas inte längre verktygstipset med texten till det gamla felet. Den här regeln fungerar på samma sätt för alla typer av valideringar: både när det gäller förlust av fokus och vid inlämning av formulär.

Svävningsverktygstipset åsidosätter fokusverktygstipset.

Verktygstipset kan visas överst eller till höger om kontrollen med ett fel, så att det inte överlappar användbar information:

Enhetligt beteende och utseende

Visa verktygstips till höger om fält. Om de i det här fallet överlappar viktigt innehåll på sidan, visa verktygstipsen högst upp. Håll dig till konsekvens, men kom ihåg att innehåll är viktigare än innehåll.

Röda texter på sidan

Hur de fungerar

Den röda feltexten visas så snart validering har skett och felfältet är markerat.

Så fort användaren börjar korrigera värdet försvinner den röda markeringen i fältet och färgen på feltexten ändras till -  #333.

Feltexten försvinner när fokus tappas och dyker inte upp igen när fältet får fokus igen. Den här regeln fungerar på samma sätt för alla typer av valideringar: både när det gäller förlust av fokus och vid inlämning av formulär.

Visa feltexten till höger om det finns utrymme på formuläret och själva meddelandet är kort. På så sätt behöver formuläret inte utökas för att visa felet.

Om det inte finns plats för text till höger om fältet utökar du formuläret och visar meddelandet under fältet.

På mer komplexa formulär, visa ett felmeddelande i verktygstipset.

Validering av beroende fält

Beroende fält är fält vars värde beror på varandra.

Fel som är relaterade till överträdelser av fältberoende visas efter att formuläret skickats in. Till exempel TIN och KPP. Om användaren angav ett TIN på 10 siffror och lämnade fältet med kontrollpunkten tom, efter att ha skickat in formuläret, kommer det tomma fältet med kontrollpunkten att markeras.

TIN kan vara av två typer:

10-siffrigt för juridiska personer
12-siffrig IP.

Om användaren angav ett TIN på 12 siffror är organisationen en enskild företagare och den har ingen kontrollpunkt, så kontrollpunktsfältet behöver inte fyllas i. Och vice versa, om kontrollpunkten är ifylld och TIN-numret är 12-siffrigt, kan TIN-numret vara felaktigt angivet.

Markeringen av beroende fält försvinner så snart användaren börjar korrigera värdet i ett av dessa fält.

Om värdeformatet bryts när du fyller i ett beroende fält, rapportera ett sådant fel när fokus tappas. Användaren skrev till exempel in 3 siffror i TIN-fältet och tog bort fokus. Detta fält bör markeras omedelbart.

Exempel

Det finns ett formulär med 5 fält:

Organisationens namn- klartext, krävs
TENN- 10 eller 12 siffror, kontrollsummakontroll vid förlust av fokus, obligatoriskt
kontrollstation- 9 siffror med kontrollsumma vid förlust av fokus, obligatoriskt om TIN består av 10 siffror
E-post- e-postadress, kontrollera för förlust av fokus med mask [e-postskyddad], valfritt
Telefon- internationellt format, kontrollera för förlust av fokus med mask +00000000000, obligatoriskt

Analys av webbplatsvalideringsfel

Jag hade äntligen ledig tid mellan en oändlig serie av beställningar, och jag bestämde mig för att starta min blogg. Låt oss försöka förbättra det när det gäller validering. Nedan i artikeln kommer jag att berätta vad validering av sajten, html och css-koden är, varför den behövs och hur man för sajten till standarder med hjälp av ett specifikt exempel.

Vad är webbplatsvalidering?

Med enkla ord är detta en kontroll av överensstämmelse med standarder. Så att vilken webbläsare som helst kan visa din webbplats korrekt. Sidans giltighet har inte någon stor inverkan på marknadsföringen, men det kommer definitivt inte att bli sämre.

Ett specifikt exempel på att godkänna validering för en webbsida

Låt oss ta första sidan på min sida - Base64-kodning och avkodning i Java 8. Låt oss fylla i sidadressen i valideraren och titta på resultatet:

Fel hittades vid kontroll av detta dokument som HTML 4.01 Transitional! Resultat: 105 fel, 67 varningar Ja, bilden är ful: mer än hundra fel och 67 varningar - hur indexerar sökmotorer min blogg och folk besöker? Men låt oss inte bli upprörda, utan lära oss hur man klarar validering, rättar till fel. Så den första varningen:

Det går inte att bestämma analysläge! Validatorn kan behandla dokument antingen som XML (för dokumenttyper som XHTML, SVG, etc.) eller SGML (för HTML 4.01 och tidigare versioner). För det här dokumentet var den tillgängliga informationen inte tillräcklig för att entydigt bestämma analysläget, eftersom: MIME-medietypen (text/html) kan användas för XML- eller SGML-dokumenttyper. Ingen känd dokumenttyp kunde upptäckas. Ingen XML-deklaration (t.ex.) finns i början av dokumentet. Inget XML-namnområde (t.ex ) kan hittas i roten av dokumentet. Som standard faller validatorn tillbaka till SGML-läge. Varning Ingen DOCTYPE hittades! Kontrollerar med standard HTML 4.01 Transitional Document Type. Ingen DOCTYPE-deklaration kunde hittas eller kännas igen i detta dokument. Detta betyder i allmänhet att dokumentet inte anger sin Dokumenttyp överst. Det kan också betyda att DOCTYPE-deklarationen innehåller ett stavfel, eller att den inte använder rätt syntax. Dokumentet kontrollerades med hjälp av en standard "fallback" dokumenttypsdefinition som liknar "HTML 4.01 Transitional". Detta är detsamma. Och korrigeringen är enkel: lägg till taggen i början av sidan:

Vi kollar vad vi gjorde och ser att med bara denna tagg tog vi bort 105 fel och 3 varningar! Nu har vi bara 64 varningar kvar. Låt oss börja ta isär dem en efter en.

Varning: Typattributet för stilelementet behövs inte och bör utelämnas. Från rad 5, kolumn 1; till rad 5, kolumn 23 /x-ikon">↩