Грешка при валидиране на файла. Проверка на формуляра за възможни клиенти – Пълното ръководство. Последователност в поведението и външния вид

Оставете коментар 6,950

Хората са склонни да правят грешки. Грешки възникват, когато хората взаимодействат с потребителски интерфейси. Това понякога се случва, защото потребителите правят грешки. Понякога възникват грешки в самото приложение. Независимо от причината, грешките и тяхното третиране имат огромно влияние върху UX. Неправилната обработка на грешки, съчетана с безполезни съобщения за грешки, може да предизвика обратна реакция от страна на потребителя, което впоследствие може да доведе до отказа на потребителя да използва вашето приложение.

В тази статия ще разгледаме как можете да оптимизирате дизайна на приложението си, за да предотвратите персонализирани грешки и как да създавате ефективни съобщения за грешки, когато възникнат грешки, независимо от това какво въвежда потребителят. Ще разгледаме също как една добре обработена грешка може да превърне провала в възхищение. Adobe представи ново приложение за проектиране и инженерство Experience Design (Adobe XD), което ви позволява да проектирате интерактивни проекти и състояния на грешки. Можете да изтеглите и изпробвате Adobe XD безплатно.

Какво е състояние на грешка?

Състоянието на грешка е екран, който се показва на потребителя, когато нещо се обърка. Това е пример за ситуация, в която потребителят прави нещо различно от желаното състояние. Тъй като грешките могат да възникнат в неочаквани комбинации, тези състояния могат да включват много различни проблеми, от несъвместими потребителски операции (например неправилно въвеждане на данни) до невъзможността на приложението да се свърже със сървъра или дори невъзможността да се обработи потребителската заявка.

Екрани за грешки

Всяка грешка, независимо от причината, се превръща в спънка за потребителя по пътя към напредъка през UX. За щастие, добре оформена грешка може да намали неприятния ефект.

Превенцията е по-добра от лечението

Ако създавате приложение, трябва да разберете какви основни взаимодействия на потребителя с приложението могат да доведат до грешка. Например, обикновено е много трудно да се попълни правилно формуляр при първия опит или е невъзможно да се синхронизират правилно данните, ако устройството има лоша мрежова връзка. Трябва да имате предвид тези точки, за да сведете до минимум възможността от грешки. С други думи, по-добре е да предотвратите възможността за грешка чрез показване на съвети, използване на ограничения и гъвкавост.

Например, ако дадете на хората възможността да търсят и резервират хотели, защо да оставяте налични дати в миналото и да показвате грешка, ако потребителят избере такава дата?

Както е показано в примера на Booking.com, можете просто да използвате инструмент за избор на дата, който позволява на потребителите да избират само днешна и бъдещи дати. Това ще подкани потребителите да изберат само валидни дати.

Инструмент за избор на дата в приложението Boocking.com. Показва се пълният месец, но датите от миналото не са налични.

Екран за грешка при валидиране на формуляра

Формата е комуникация. Както всяка комуникация, тя трябва да бъде последователна комуникация между две страни - потребителя и вашето приложение. Валидирането играе важна роля в тази комуникация. Валидирането на формуляра е предназначено да води потребителите през сложности, грешки и недоразумения. Когато се потвърди правилно, тази комуникация става ясна и разбираема. Като цяло валидирането на добра форма има четири важни елемента:

Точно време за докладване на грешки (или успешно завършване)
Правилното място за съобщението за валидиране
Правилен цвят на съобщението
Разбираем език на съобщението

Точно време (проверка на низ)

Валидирането на формуляра е неизбежно и е логическа част от въвеждането на потребителя (тъй като въвеждането от потребителя може да бъде податливо на грешки). Разбира се, състоянията, които могат да причинят грешка, трябва да бъдат сведени до минимум, но проверката на грешката не може да бъде премахната. И така, най-важният въпрос е: "Как можете да улесните потребителя да се възстанови от грешка?"

Потребителите не харесват процеса на попълване на формуляра, особено когато получат известие за грешка в края. Особено разочароващо е да получавате съобщения за грешка в множество полета след попълване на дълъг формуляр. И най-досадното нещо е липсата на яснота какви грешки сте допуснали и къде.

Валидацията трябва незабавно да информира потребителя за правилността на този отговор веднага след като потребителят е въвел данните. Основният принцип на доброто валидиране е: „Говорете с потребителите! Кажете им какво не е наред!” и валидирането на низове в реално време информира потребителите за коректността на въведените данни. Този подход позволява на потребителите бързо да коригират грешки и да не чакат грешките да се покажат, след като щракнат върху бутона за изпращане.

Въпреки това, трябва да избягвате валидирането на всяко натискане на клавиш, защото в повечето случаи няма да можете да проверите данните, преди потребителят да е приключил с въвеждането на своя отговор. Формулярите, които валидират стойността веднага по време на процеса на въвеждане, започват да дразнят потребителя веднага щом той започне да въвежда данни.

Google Forms показва грешка в имейла, дори когато все още не сте приключили с въвеждането.

От друга страна, формулярите, които се валидират след въвеждане на данни, не информират незабавно потребителя за грешката.

Проверката на Apple Store се извършва след въвеждане на данни.

Михаил Конжевич в статията си „Валидиране на низове във форми – създаване на опит! проучи различни стратегии за валидиране и предложи хибридна стратегия: ранно възнаграждение, късно наказание.

Хибрид - ранна награда, късно наказание - подход

Правилното място

Ориентацията към потребителя е друг важен инструмент. Когато се чудите къде да отидете за вашето съобщение за валидиране, следвайте този съвет: Винаги поставяйте съобщението си в контекста на действие. Ако искате да кажете на потребителя за грешка в определено поле, покажете го до него. Най-добре е да поставите бърза проверка отдясно на полето за въвеждане или под него.

Грешки във формуляра в реално време.

Правилен цвят (интуитивен дизайн)

Цветът е един от най-добрите инструменти за използване при създаване на валидиране. Тъй като работи на интуитивно ниво, червено за грешка, жълто за предупреждение и зелено за указване на успех е особено мощно. Но се уверете, че цветовете са добре приети от потребителите. Това е критичен аспект на добрия визуален дизайн.

Текстът на грешката трябва да бъде разбираем и ясно да се откроява на фона на приложението.

Изчистване на съобщението

Типичното съобщение за грешка може да гласи „имейлът е невалиден“, без да обяснява на потребителя защо имейлът е неправилен. (Типография? Имейл зает от друг потребител?) Ясните инструкции или насоки могат да направят нещата по различен начин. Можете да видите в пример как формата информира потребителя, че имейлът му вече е зает. Също така се появяват няколко предложения (възстановяване на вход или парола).

И така, сега е моментът да се покаже страницата за грешка, за да се покаже, че нещо се е объркало. Като пример, нека си представим ситуация, при която връзката е прекъсната и потребителят е на екрана, който е единственият наличен. Трябва да използвате тази възможност, за да уведомите хората какво се случва и да предоставите бърз модел на помощ – вашето съобщение трябва да бъде ръка за помощ за потребителите. Следователно никога не трябва да показвате следното:

Съобщение за фатална грешка.Съобщенията, които говорят за вътрешна грешка в кода на приложението или съдържат текст като „възникна грешка тип 2“, са загадъчни и страшни.

Съобщение за грешка, написано от разработчика за разработчика.

Грешка в задънена улица.Просто защото подобни съобщения не предоставят никаква полезна информация на потребителя.

Екранът за грешка в Spotify гласи „Възникна грешка“ и не съдържа опции или стъпки за разрешаване на проблема.

Недефинирано съобщение за грешка.Такъв екран (в примера по-долу) дава на потребителя толкова информация, колкото и предишния. Потребителите нямат представа какво означава това или какво да правят с него.

Приложението Buffer съдържа хубаво съобщение за грешка, но не предава никаква информация на потребителя.

Не плашете потребителя с грешки. Също така, не се опитвайте да запознаете потребителя с техническите подробности на проблема. Говорете за грешката на прост и разбираем език. За да направите това, опитайте се да не използвате технически жаргон и да изразявате мислите си на езика на потребителя.

Направете съобщенията си четими и полезни - грешките трябва да са учтиви, ясни и дидактични и да включват следната информация:

Какво се обърка и защо (евентуално).
Какво трябва да направи потребителят, за да коригира грешката.

Приложението Remote обяснява защо потребителите не виждат нищо и предлага решение.

Включете хумор и изображения в съобщенията за грешки

Отчитането на грешки е чудесна възможност за използване на икони и илюстрации, защото хората са по-възприемчиви към визуална информация, отколкото просто към текст. Но можете да отидете още по-далеч и да добавите изображения към приложението си, което ще бъде полезно за потребителите. Това ще персонализира приложението ви и ще смекчи вашето съобщение.

Azendoo използва илюстрация и хумор, за да вдъхнови потребителя да реши проблем.

Хуморът удължава живота. Малко хумор никога не вреди и ще ви помогне да разсеете объркването от грешка. Можете да намерите много примери за забавни публикации в Littlebigdetails. Ето някои от любимите ми:

Basecamp: При грешка при валидиране на формуляра, героят отляво прави изненадано изражение.

Показва се леко нахално съобщение за грешка, когато се опитвате да въведете твърде много точки при създаване на нов акаунт в Gmail.

Въпреки това, бъдете внимателни с хумора, защото може да не винаги е подходящ във вашия доклад за грешки; зависи от сериозността на грешката. Например хуморът работи добре за прост проблем с валидиране като грешка 404 (страница не е намерена). Но когато потребителят прекара известно време, гледайки страница, която казва „О!“ - изглежда не на място.

Изчерпателен контролен списък за перфектната страница за грешки

Добрите страници за грешки са помощна ръка за потребителите и трябва да отговарят на следните шест критерия:

Съобщението за грешка се появява динамично, веднага след откриване на грешката. Той трябва да информира потребителя за проблема.
Бъдете в безопасност за въведените данни. Вашето приложение не трябва да нарушава, изтрива или отменя това, което потребителят е въвел или изтеглил, когато е била открита грешката.
Говорете с потребителя на същия език. Съобщението трябва да предоставя ясно разбиране какво се е объркало и защо; какво трябва да направи потребителят, за да отстрани грешката?
Не шокирайте и не обърквайте потребителите. (Съобщението не трябва да е твърде провокативно).
Не губете контрол над системата. (Ако проблемът не е критичен, потребителят трябва да може да го прави с останалата част от приложението).
Използвайте чувство за хумор, за да смекчите проблема.

Решения за най-често срещаните грешки

404 грешка (страницата не е намерена)

Основната цел на страница 404 е да пренасочи вашия потребител към страницата, която е търсил възможно най-скоро. Вашата страница 404 трябва да предлага няколко ключови връзки, към които потребителят да отиде. Най-сигурният вариант е да имате връзка към „началната страница“ на сайта на страница 404. Също така можете да поставите „докладване за проблем“, така че потребителят да ви уведоми, че страницата не работи. Но се уверете, че преходът към началната страница е по-ясен преход и се откроява по-визуално.

Проблем с влизането

Екранът на формуляра за вход често е минималистичен и съдържа поле за въвеждане на потребителско име и поле за парола. Но минимализмът не е равен на простотата. Има много причини, поради които потребителят може да се забие на екрана за вход. Основното правило на страницата за вход е да не принуждава потребителя да гадае.

Нека да разгледаме решенията на най-често срещаните проблеми, използвайки примери от MailChimp, който върши страхотна работа при докладването на грешки.

Потребителят е забравил името си в сайта. Ако откриете подобна грешка, трябва да предложите връзка, където потребителят може да я поправи. Кажете на потребителя къде може да го получи (например: „проверете пощата си, изпратихме ви писмо“) или дайте връзка за възстановяване на името на сайта.

Потребителите правят много опити да влязат в сайта, използвайки грешна парола. За да се предотвратят подобни сървърни атаки, потребителските акаунти се блокират след твърде чести неуспешни опити. Това е обичайна практика за сигурност, но потребителят трябва да бъде предупреден, преди акаунтът му да бъде заключен.

Отхвърляне на кредитна карта

Кредитна карта може да бъде отхвърлена по няколко причини: грешка при форматирането на данните (печатна грешка или липсващи данни) или картата може да бъде отхвърлена, защото е изтекла или открадната. Габриел Томеску в статията си „Анатомия на формата на кредитна карта“ предлага следната стратегия и за двете грешки:

За първия проблем трябва да следвате стандартната проверка на низа и визуална индикация за грешка:

Когато обаче кредитна карта бъде отхвърлена от платежна система по някаква причина, това обикновено изглежда като кражба. Имате нужда от ясни данни от потребителя. И дори след това все още трябва да уведомите потребителя за случилото се; съобщението за грешка трябва да е много ясно.

Проблем с връзката

Интернет връзката не е достъпна навсякъде и поддръжката офлайн трябва да бъде ключов аспект в живота на всяко модерно приложение. Когато връзката падне, трябва да помислите внимателно за офлайн UX. Потребителите трябва да могат да взаимодействат с възможно най-много от вашето приложение. Това означава, че приложението трябва да кешира съдържание за добър офлайн UX.

Етикети:,,,

Валидирането е един от най-важните аспекти на добрия уеб дизайн. Нека да разгледаме какво представлява и как да проверим валидността на HTML кода. Да вземем за пример най-разпространената система за управление на съдържанието (CMS) – WordPress. След това ще споделим списък с грешки, които срещнахме на практика и най-важното ще предложим собствени доказани методи за отстраняването им.

Защо е необходимо да се проверява валидността на сайта

Просто казано, проверката на уеб страница ще определи дали тя отговаря на стандартите, определени от World Wide Web Consortium (W3C). Това обикновено се прави чрез проверка на валидността на отделни страници с помощта на услугата за онлайн валидиране на W3C.

Подобно на граматическите правила в различните езици, има и правила в програмирането. Проверката ви позволява да видите дали страницата отговаря на тези правила и ако има грешки или предупреждения, ще бъдат предоставени препоръки как да ги коригирате. По-долу ще разгледаме по-подробно необходимостта от такава проверка.

Какво влияе на валидността на сайта?

Чудили ли сте се как браузърите „четат“ уеб страница? Те имат двигатели за анализиране на код и превръщането му във визуализация за хората. За съжаление, всеки браузър има свой собствен механизъм за обработка на код и това може да доведе до различно показване на страниците ви.

Невалидна уеб страница може да бъде прочетена по различен начин от браузърите. Това ще доведе до факта, че посетителите ви може дори да не могат да видят правилно съдържанието на страницата в браузърите си. По-нататъшната проверка ще коригира почти всички основни разлики и ще направи вашата уеб страница четлива от почти всички уеб браузъри (най-често по-старите версии на Internet Explorer са изключение). Оттук идва и терминът „кросбраузерно оформление“ – т.е. оформление, което е еднакво добро (съвместимо) за всички популярни браузъри.

Как това се отразява на SEO? Важно е да разберете, че роботите на търсачките обичат семантичните уеб страници. Семантичното оформление, според Wikipedia, е подход за създаване на уеб страници в HTML, базиран на използването на HTML тагове в съответствие с тяхната семантика (цел). В допълнение, структурната семантична уеб страница позволява на роботите за търсене да определят по-точно важността както на отделните елементи на уеб страницата, така и на целия текст като цяло. Според Google валидният код не влияе по никакъв начин на класирането на страницата. Но в същото време наличието на грешки в кода може да повлияе негативно на сканирането на микро-маркиране и адаптивността за мобилни устройства.

Инструменти за валидиране на вашия сайт

Разбирайки необходимостта от липса на грешки при валидиране на страниците на сайта, нека да разгледаме как да търсим тези грешки.

Има много безплатни услуги за валидиране на сайтове, като услугата за проверка на маркиране на W3C, анализатор на уеб страници, Browsershots и други.

Няма нищо по-досадно от попълването на лошо написан формуляр за възможни клиенти на целева страница. Спомнете си колко пъти трябваше да попълните отново всички полета поради факта, че паролата, която измислихте, не отговаряше на системата според определени критерии, никой не се опита да ви уведоми предварително.

Имайте предвид, че оптимизирането на формуляр за възможни клиенти е ключов компонент от процеса на оптимизиране на конверсията и фокусът тук трябва да бъде върху валидирането на полето.

Какво е валидиране на формуляр за възможни клиенти?

Валидирането на формата за потенциален клиент е технически процес, по време на който системата проверява коректността на въведените от потребителя данни. Ако човек е допуснал грешка при попълването на формуляра (например е посочил данните в грешен формат), тогава системата ще го насочи към тази грешка (или просто към нейното присъствие) и ще предложи да я коригира. Ако потребителят е въвел всички данни правилно, тогава няма да се появят допълнителни съобщения (или ще се появи отметка до полето) и той ще премине към следващия етап на регистрация.

Например, Twitter няма да ви позволи да преминете към следващата стъпка за регистрация, ако въведете имейл адреса си в грешен формат:

Когато въведете имейл адреса във формата, от който се нуждае системата, ще се появи отметка до полето, което показва, че форматът на въведените данни е правилен:

Същността на валидирането е да се гарантира, че потребителите въвеждат данни във формата, изискван от системата (например имейл адресът трябва да отговаря на стандарта [защитен с имейл], но например паролата трябва да съдържа поне 7 знака).

Има два основни типа валидиране на формуляри.

Валидирането е валидиране на предоставени от потребителя стойности и показване на намерени грешки.

Принципи

Задачата на дизайнера е да се увери, че потребителят не прави грешка и не е необходима валидация, за това:

Ограничете избора на умишлено неправилни стойности в списъка: блокирайте тези стойности или не ги показвайте в списъка.
Ограничете въвеждането на неподходящи знаци. Ако трябва да въведете само числа в поле и това е очевидно за потребителя, игнорирайте въвеждането на букви, вместо да показвате грешка. Използвайте маски в полета, където форматът е известен на стойностите.
Напишете съвети за попълване на формуляра. Например заместител в полетата за въвеждане.

Валидирането на новоотворен празен формуляр е забранено. Изключението са чернови, когато потребителят вече е попълнил този формуляр, след известно време се е върнал към него и е бил попълнен с грешки.

Видове валидиране

Има три типа валидиране: моментално, извън фокус и подаване на формуляр.

Колкото по-рано интерфейсът съобщи за грешката, толкова по-добре - за потребителя е по-лесно да се върне и да поправи грешката.

Най-бързият начин да съобщите за грешка е с незабавна проверка. Но това е възможно само в случаите, когато по време на процеса на въвеждане е ясно, че стойността е неправилна. Обикновено такива грешки са свързани с неправилна клавиатурна подредба (кирилица вместо латиница) или въвеждане на букви в цифрово поле (TIN, KPP и др.) За тези случаи използваме полета с маски: въвеждането на неподходящи знаци в тях е блокирано. Следователно има само два типа валидиране в нашите интерфейси:

при загуба на фокус- основният вид валидиране
чрез подаване на формуляра- за случаите, когато валидирането при загуба на фокус не е възможно.

Загуба на валидиране на фокуса

Кога да се използва

Как работи

Не проверявайте полетата за празни при загуба на фокус - не показвайте грешка, ако полето не е попълнено, може би потребителят ще се върне и ще попълни полето малко по-късно. Можете да покажете грешка в такива случаи само след подаване на формуляра.

Проверката се задейства веднага след загуба на фокус, ако стойността в полето е попълнена. Ако се открие грешка, полето се маркира в червено. Фокусът не се връща автоматично в това поле:

Текстът за грешка се появява в подсказката, когато полето получи курсор или фокус:

Полето за грешка трябва да остане маркирано, ако е получило фокус, стойността му не е коригирана и след това е загубило фокус.

Червеното осветяване се премахва от полето веднага щом потребителят започне да коригира грешната стойност.

Потвърждение при подаване на формуляр

Кога да се използва

Използвайте този вид проверка, когато не можете да валидирате полета при загуба на фокус. Например, за да проверите попълването на задължителните полета.

Как работи

Проверката се извършва, след като потребителят натисне бутона за изпращане: всички полета с грешки във формуляра са маркирани, страницата се превърта до първото поле с грешка, фокусът се премества към това поле, курсорът се премества до края на реда, а до полето се появява подсказка с подсказка.

При превъртане до първото поле от горната граница на прозореца до грешното поле има отстъп от 48px - шест модула.

Блокиране на бутона за изпращане

В малки формуляри, вместо да проверявате дали задължителните полета са попълнени, можете да блокирате бутона за изпращане на формуляра. Използвайте това поведение, когато е очевидно защо бутонът за изпращане на формуляра е неактивен. Например във формата за вход:

Веднага след като всички задължителни полета бъдат попълнени, бутонът става активен. Ако след това потребителят изтрие стойността в едно от полетата, бутонът трябва да стане отново неактивен.

Съобщения за грешки

Грешки могат да бъдат докладвани по два начина:

Подсказки

Как работят

Подсказка с намек се появява в два случая:

При задържане на курсора на мишката върху поле с грешка.
Когато полето за грешка получи фокус.

Ако стойността в полето с грешката е променена, изгубен фокус и след това върнат на фокус - подсказката с текста на старата грешка вече не се появява. Това правило работи еднакво за всички видове валидации: както при загуба на фокус, така и при подаване на формуляр.

Подсказката за задържане на мишката отменя подсказката за фокусиране.

Подсказката може да се появи над или вдясно от контрола за грешки, така че да не се припокрива с полезна информация:

Последователност в поведението и външния вид

Показване на подсказки вдясно от полетата. Ако в този случай те припокриват важно съдържание на страницата, покажете подсказки в горната част. Поддържайте последователност, но не забравяйте, че съдържанието е по-важно от него.

Червени текстове на страницата

Как работят

Червеният текст за грешка се появява веднага след като е настъпило валидиране и полето за грешка е маркирано.

Веднага щом потребителят започне да коригира стойността, червеното маркиране на полето изчезва и цветът на текста за грешка се променя на -  # 333.

Текстът за грешка изчезва, когато фокусът се загуби и вече не се появява, ако полето отново получи фокус. Това правило работи еднакво за всички видове валидации: както при загуба на фокус, така и при подаване на формуляр.

Отпечатайте текста за грешка вдясно, ако има място във формуляра и самото съобщение е кратко. По този начин формулярът не трябва да се раздалечава, за да се покаже грешката.

Ако няма място за текст вдясно от полето, разгънете формуляра и покажете съобщение под полето.

При по-сложни формуляри покажете съобщение за грешка в подсказката.

Проверка на зависими полета

Зависимите полета са полета, чието значение зависи едно от друго.

Грешки, които са свързани с нарушаване на зависимостта на полето, показваме след подаване на формуляра. Например TIN и KPP. Ако потребителят посочи TIN от 10 цифри и остави полето с контролната точка празно, след подаване на формуляра, празното поле с контролната точка ще бъде маркирано.

TIN може да бъде от два вида:

10-цифрено за юридически лица
12-цифрено IP.

Ако потребителят е посочил TIN от 12 цифри, тогава организацията е индивидуален предприемач и няма контролна точка, тогава полето за контролна точка не е необходимо да се попълва. И обратно, ако контролната точка е попълнена и TIN е посочен с 12-цифрено число, възможно е TIN да е посочен неправилно.

Маркирането на зависимите полета изчезва веднага щом потребителят започне да коригира стойността в едно от тези полета.

Ако форматът на стойността не е в ред при попълване на зависимо поле, докладвайте тази грешка, когато загубите фокус. Например, потребителят е въвел 3 числа в полето TIN и е премахнал фокуса. Такова поле трябва да бъде подчертано незабавно.

Пример

Има формуляр с 5 полета:

Име на организацията- обикновен текст, задължително
КРЪЧМА- 10 или 12 цифри, контролна сума за загуба на фокус, задължителна
Контролен пункт- 9 цифри с проверка на контролната сума при загуба на фокус, задължително, ако INN се състои от 10 цифри
електронна поща- имейл адрес, проверете за загуба на фокус чрез маска [защитен с имейл], по избор
Телефон- международен формат, проверка за загуба на фокус чрез маска +00000000000, задължително

Анализ на грешки при валидиране на сайта

Най-накрая имаше малко свободно време между безкрайна поредица от поръчки и реших да започна своя блог. Нека се опитаме да го подобрим по отношение на валидирането. По-долу в статията ще ви разкажа какво е валидиране на сайт, html и css код, защо е необходимо и как да приведете сайта към стандартите с помощта на конкретен пример.

Какво е валидиране на сайта?

С прости думи, това е тест за съответствие със стандартите. За да може всеки браузър да показва правилно вашия сайт. Валидността на сайта не оказва голямо влияние върху промоцията, но със сигурност няма да е по-лоша.

Конкретен пример за преминаване на валидиране за страница на уебсайт

Нека вземем първата страница, на която се натъкваме на моя сайт - Base64 кодиране и декодиране в Java 8. Нека попълним адреса на страницата във валидатора и да видим резултата:

Открити са грешки при проверката на този документ като HTML 4.01 Transitional! Резултат: 105 грешки, 67 предупреждения (и) Да, картината е неприятна: повече от сто грешки и 67 предупреждения - как търсачките индексират моя блог и хората посещават? Но нека не се разстройваме, а ще се научим да преминаваме валидиране, да коригираме грешки. И така, първото предупреждение:

Не може да се определи режимът на синтактичен анализ! Валидаторът може да обработва документи или като XML (за типове документи като XHTML, SVG и др.) или SGML (за HTML 4.01 и предишни версии). За този документ наличната информация не беше достатъчна за недвусмислено определяне на режима на синтактичен анализ, тъй като: MIME Media Type (text / html) може да се използва за типове документи XML или SGML Не може да бъде открит известен тип на документ Няма XML декларация (напр.) може да се намери в началото на документа. Няма XML пространство от имена (напр ) може да се намери в основата на документа. По подразбиране валидаторът се връща към режим SGML. Предупреждение Не е намерен DOCTYPE! Проверка с HTML 4.01 преходен тип документ по подразбиране. В този документ не може да бъде намерена или разпозната декларация DOCTYPE. Това обикновено означава, че документът не декларира своя тип документ в горната част. Това може също да означава, че декларацията DOCTYPE съдържа правописна грешка или че не използва правилния синтаксис. Документът беше проверен с помощта на „резервна“ дефиниция на типа на документа по подразбиране, която много наподобява „HTML 4.01 Transitional“. Това е същото. И корекцията е проста: в самото начало на страницата добавете маркера:

Проверяваме дали сме успели и виждаме, че с този един таг сме премахнали 105 грешки и 3 предупреждения! Сега ни остават само 64 предупреждения. Започваме да ги разглобяваме един по един.

Предупреждение: Атрибутът тип за стиловия елемент не е необходим и трябва да бъде пропуснат. От ред 5, колона 1; до ред 5, колона 23 / икона x "> ↩