Що таке помилка валідації токена на півдні | Помилки та валідація форм мобільних додатків

Немає нічого більш утомливого, ніж заповнення неписьменно складеної лід-форми на посадочній сторінці. Згадайте, скільки разів вам доводилося перезаповнювати всі поля через те, що придуманий вами пароль не підходив системі за тими чи іншими критеріями, повідомити про які вас ніхто не намагався заздалегідь.

Майте на увазі, що оптимізація лід-форм є ключовим компонентом процесу оптимізації конверсії, і основну увагу тут слід приділити валідації полів.

Що таке валідація лід-форми?

Валідація лід-форм - це технічний процес, у ході якого системою перевіряється вірність введених користувачем даних. Якщо людина припустилася помилки при заповненні форми (наприклад, вказала дані в неправильному форматі), то система вкаже їй на цю помилку (або просто на її наявність) і запропонує виправити. Якщо ж користувач ввів усі дані правильно, то ніяких додаткових повідомлень не виникне (або поруч із полем з'явиться галочка), і він перейде на наступний етап реєстрації.

Наприклад, Twitter не дозволить вам перейти на наступний етап реєстрації, якщо ви введете адресу електронної поштиу неправильному форматі:

Коли ви введете адресу пошти у тому форматі, який потрібен системі, поряд з полем з'явиться галочка, що свідчить про те, що формат введених даних є вірним:

Суть валідації — гарантувати введення користувачами даних у форматі, необхідним системою (наприклад, адреса пошти має відповідати стандарту [email protected], а ось, наприклад, пароль повинен містити щонайменше 7 символів).

Існують два основні види форми валідації.

Людині властиво помилятися. Помилки виникають, коли люди взаємодіють з користувальницькими інтерфейсами. Іноді це відбувається тому, що користувачі роблять помилки. Іноді помилки виникають у самому додатку. Незалежно від причини, помилки та їх обробка мають величезний вплив на UX. Некоректна обробка помилки разом із марними повідомленнями про помилку можуть викликати у користувача негативну реакцію, що згодом може призвести до відмови користувача від використання вашої програми.

У цій статті ми розберемося, як можна оптимізувати дизайн програми для запобігання користувальницьких помилок і як створити ефективні повідомлення про помилку у разі, якщо помилки виникають незалежно від того, що вводить користувач. Також, ми розглянемо, як добре оброблена помилка може перетворити невдачу у захоплення. Adobe представив новий додаток для дизайну та проектування Experience Design (Adobe XD), який дозволяє створювати дизайн інтерактивних проектів та станів помилок. Ви можете скачати та спробувати Adobe XD безкоштовно.

Що таке стан помилки?

Стан помилки – це екран, який показується користувачеві, коли щось пішло не так. Це приклад ситуації, коли користувач робить щось, що відрізняється від бажаного стану. Так, як помилки можуть виникати в несподіваних поєднаннях, ці стани можуть включати в себе абсолютно різні проблеми: від несумісності операцій користувача (наприклад, некоректне введення даних) до неможливості програми підключитися до сервера або навіть неможливості обробити запит користувача.

Екрани з помилками

Кожна помилка, незалежно від її причини, стає каменем спотикання для користувача на шляху просування UX. На щастя, правильно оформлена помилка може зменшити неприємний ефект.

Профілактика краща за лікування

Якщо ви створюєте програму, ви повинні розуміти, які основні взаємодії користувача з програмою можуть призвести до помилки. Наприклад, зазвичай дуже важко правильно заповнити форму з першої спроби, або неможливо коректно синхронізувати дані, якщо пристрій поганий мережне з'єднання. Ви повинні враховувати такі моменти, щоб мінімізувати можливість виникнення помилок. Іншими словами, краще запобігти можливості помилитися за допомогою показу порад, використання обмежень та гнучкості.

Наприклад, якщо ви даєте людям можливість пошуку та резерву готелів, навіщо залишати доступними дати в минулому та виводити помилку, якщо користувач обирає таку дату?

Як показано на прикладі Booking.com, ви можете просто використати вибір дати, який дозволяє користувачам вибрати лише сьогоднішню дату та дати у майбутньому. Це спонукатиме користувачів вибирати тільки валідні дати.

Вибір дати в Boocking.com. Відображається повний місяць, але дати в минулому недоступні. Екран помилки для валідації форми

Форма – це спілкування. Як і будь-яке спілкування, воно має бути представлене послідовною комунікацією між двома сторонами – користувачем та вашим додатком. Валідація грає головну роль процесі такого спілкування. Валідація форми покликана проводити користувачів через складності, помилки та нерозуміння. За правильної валідації, таке спілкування стає чітким і зрозумілим. Загалом хороша валідація форми складається з чотирьох важливих елементів:

• Правильний час для інформування про помилки (або успішне заповнення)
• Правильне місце для валідаційного повідомлення
• Правильний колір повідомлення
• Зрозуміла мова повідомлення

Правильне час (валідація рядка)

Валідація помилок форми неминуча, і є логічною частиною введення даних (з тих пір, як введення даних користувачем може супроводжуватися помилками). Звичайно, стани, які можуть спричинити помилку, мають бути мінімізовані, але валідацію помилок прибирати не можна. Отже, найважливіше питання: "Як спростити процес відновлення після помилки для користувача?"

Користувачі не люблять процес заповнення форми, особливо коли в кінці їм приходить повідомлення про помилку. Особливе розчарування викликає отримання повідомлення про помилки у кількох полях після заповнення довгої форми. І найбільше дратує неясність того, яких помилок ви припустилися і де.

Валідація повинна моментально інформувати користувача про коректність цієї відповіді відразу після того, як користувач ввів дані. Головний принцип хорошої валідації говорить: “Говоріть із користувачами! Кажіть їм, що не так! та валідація рядка у режимі реального часу інформує користувачів про коректність введених даних. Такий підхід дозволяє користувачам швидко виправити помилки та не чекати на відображення помилок після натискання кнопки підтвердження.

Однак слід уникати валідації кожного натискання клавіші тому, що в більшості випадків ви не зможете верифікувати дані до того, як користувач закінчить друкувати свою відповідь. Форми, які валідують значення відразу в процесі набору, починають дратувати користувача відразу, як тільки він починає вводити дані.

Google форми відображають помилку імейлу навіть коли ви ще не перестали друкувати.

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

Валідація в Apple Store здійснюється після введення даних.

Михайло Конжевич у своїй статті “Волідація рядка у формах – створення досвіду! досліджував різні валідаційні стратегії та запропонував гібридну стратегію: рання нагорода, пізнє покарання.

Гібрид – рання нагорода, пізнє покарання – підхід Правильне місце

Орієнтація на користувача – ще один важливий інструмент. Коли ви гадаєте, яке місце вибрати для валідаційного повідомлення, виконайте таку пораду: завжди розміщуйте повідомлення в контексті дії. Якщо ви хочете сказати користувачеві про помилку в конкретному полі, покажіть це поруч. Швидку валідацію найкраще розміщувати праворуч від поля введення або під ним.

Помилки у вигляді реального часу. Правильний колір (інтуїтивний дизайн)

Колір є одним із найкращих інструментів для використання при створенні валідації. так, як він працює на інтуїтивному рівні, особливо сильний вплив має червоний колір для позначення помилки, жовтий для попередження і зелений для того, щоб показати успіх. Але переконайтеся, що кольори добре сприймаються користувачами. Це – критичний аспект гарного візуального дизайну.

Текст помилки повинен бути зрозумілим та чітко виділятися на тлі програми. Чітке повідомлення

Типове повідомлення про помилку могло б говорити: "імейл некоректний", без пояснення користувачеві чому імейл некоректний. (Типографіка? Імейл зайнятий іншим користувачем?) Прямолінійні інструкції або гайдлайн можуть зробити все по-іншому. Ви можете побачити на прикладі, як форма інформує користувача про те, що його імейл вже зайнятий. Також з'являється кілька пропозицій (логін або відновлення пароля).

Отже, час відобразити сторінку з помилкою для того, щоб показати, що щось пішло не так. Як приклад, давайте уявімо ситуацію, коли обірвалося з'єднання і користувач знаходиться на екрані, який є єдиним доступним. Ви повинні використовувати дану можливістьщоб дати людям зрозуміти, що відбувається і надати модель швидкої допомоги - ваше повідомлення має стати простягнутою рукою допомоги для користувачів. Тому вам не слід ніколи показувати наступне:

• Повідомлення про критичну помилку. Повідомлення, які говорять про внутрішню помилку коду програми або містять текст типу: "відбулася помилка тип 2" - загадкові та відлякують.

Повідомлення про помилку, написане розробником для розробника.

• Тупикова помилка. Просто тому, що такі повідомлення не надають корисної інформації для користувача.

Екран з помилкою на Spotify говорить: "Відбулася помилка" і не містить варіантів та кроків щодо вирішення проблеми.

• Повідомлення про невизначену помилку. Такий екран (на прикладі нижче) дає користувачеві стільки інформації, як і попередній. Користувачі гадки не мають, що це означає і що з цим робити.

Програма Buffer містить хороше повідомлення про помилку, але вона не несе жодної інформації для користувача.

Не лякайте користувача помилками. Також не намагайтеся ввести користувача в технічні деталі проблеми. Говоріть про помилку простою та зрозумілою мовою. Для цього постарайтеся не використовувати технічний жаргон і висловлюйте свої думки мовою користувача.

Зробіть ваші повідомлення читабельними та корисними - помилки повинні бути ввічливими, чіткими та повчальними, і містити таку інформацію:

• Що пішло не так і чому (можливо).
• Що повинен зробити користувач, щоб виправити помилку?

Програма Remote app пояснює, чому користувачі нічого не бачать і пропонує рішення. Включайте гумор та зображення у повідомлення про помилки

Повідомлення про помилки – чудова можливість для використання іконок та ілюстрацій тому, що люди краще сприймають візуальну інформацію, ніж просто текст. Але ви можете піти ще далі і додати зображення до вашої програми, що буде корисним для користувачів. Це дозволить персоналізувати вашу програму і пом'якшити ваше повідомлення.

Azendoo використовує ілюстрацію та гумор для того, щоб надихнути користувача вирішити проблему.

Гумор продовжує життя. Небагато гумору ніколи не зашкодить і допоможе пом'якшити сум'яття від помилки. Ви можете знайти безліч прикладів кумедних повідомлень в Littlebigdetails. Ось деякі з моїх коханих:

• Basecamp: При помилці валідації форми, герой зліва робить здивований вираз обличчя.

• Трохи нахабне повідомлення про помилку відображається при спробі ввести занадто багато точок під час створення нового облікового запису в Gmail.

Однак, будьте обережнішими з гумором тому, що він може бути не завжди доречним у вашому повідомленні про помилку; це залежить від ступеня брутальності помилки. Наприклад, гумор добре застосовується для простої проблеми валідації, як “404 помилка” (сторінку не знайдено). Але коли користувач витрачає певну кількість часу на перегляд сторінки, на якій написано "Ох!" - Це виглядає недоречно.

Вичерпний чекіст ідеальної сторінки з повідомленням про помилку

Хороші сторінки помилок є рукою допомоги для користувачів і повинні відповідати наступним шести критеріям:

Повідомлення про помилку з'являється динамічно відразу після виявлення помилки. Воно має інформувати користувача про проблему.

Бути безпечним для введених даних. Ваша програма не повинна ламати, видаляти або скасовувати те, що ввів або завантажив користувач у момент виявлення помилки.

Говорити з користувачем однією мовою. Повідомлення має давати чітке розуміння, що пішло негаразд і чому; що користувачеві потрібно зробити для того, щоб виправити помилку?

Не шокуйте користувачів і не вводьте їх у замішання. (Повідомлення не повинно бути сильно зухвалим).

Не втрачайте контроль над системою. (Якщо проблема не критична, користувач повинен мати можливість з рештою програми).

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

Рішення для найбільш популярних помилок 404 помилка (сторінка не знайдена)

Основна мета сторінки з 404 помилкою - перенаправити вашого користувача на сторінку, яку він шукав якнайшвидше. Ваша 404 сторінка повинна пропонувати декілька ключових посилань, куди можна перейти. Найбезпечніший варіант – це наявність посилання на “ головну сторінку” сайту на 404 сторінці. Також, ви можете розмістити "повідомити про проблему" для того, щоб користувач повідомив вас, що сторінка не працює. Але переконайтеся, що перехід на головну сторінку є більш явним переходом і більше виділяється візуально.

Проблема з логіном

Екран з логін формою найчастіше виглядає мінімалістично і містить поле для введення імені користувача та поле для пароля. Але мінімалізм не дорівнює простоті. Існує безліч причин, чому користувач може зупинитися на екрані логіна. Головне правило логін сторінки – не змушуйте користувача здогадуватися.

Давайте розглянемо рішення для найбільш частих проблемз використанням прикладів з MailChimp , який робить чудову роботу над повідомленнями про помилки.

• Користувач забув своє ім'я на сайті. Якщо ви виявили подібну помилку, ви повинні запропонувати посилання, де користувач може виправити це. Скажіть користувачеві, де він може його отримати (наприклад: “перевірте пошту, ми надіслали вам листа”) або надайте посилання на відновлення імені на сайті.

Користувачі роблять багато спроб входу на сайт, використовуючи неправильний пароль. Для запобігання таким атакам сервера, акаунти користувача блокуються після занадто частих безуспішних спроб. Це звичайна практика безпеки, але користувача необхідно попередити перед тим, як його обліковий запис буде заблоковано.

Відхилення кредитної картки

Відхилення кредитної картки може статися з кількох причин: помилка у форматуванні даних (друкарська помилка або брак даних) або картка може бути відхилена через те, що вона прострочена або викрадена. Габріель Томеску у своїй статті "Анатомія форми кредитної картки", запропонував наступну стратегію для обох помилок:

Для першої проблеми, вам слід дотримуватися стандартної валідації рядка та візуальної індикації помилки:

Однак, коли кредитна картавідхиляється платіжною системоюз певної причини зазвичай це виглядає, як викрадення. Вам потрібні чіткі дані від користувача. І навіть після того, вам все одно необхідно повідомити користувача про те, що сталося; повідомлення про помилку має бути гранично зрозумілим.

Проблема зі з'єднанням

Інтернет з'єднання є не скрізь і оффлайн підтримка має бути ключовим аспектом у житті будь-якої сучасної програми. Коли з'єднання обривається, необхідно добре продумати оффлайн UX. Користувачі повинні мати можливість взаємодіяти з якомога більшою частиною вашої програми. Це означає, що програма повинна кешувати контент для хорошого UX оффлайн.

Теги: , , ,

Валідація – це перевірка значень, вказаних користувачем, та відображення знайдених помилок.

Принципи

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

Обмежте вибір свідомо неправильних значень у списку: блокуйте ці значення або не показуйте у списку.

Обмежте введення невідповідних символів. Якщо в полі потрібно вводити лише цифри, і це очевидно користувачеві, ігноруйте введення букв замість того, щоб показати помилку. Використовуйте маски в полях, де відомий формат.

Напишіть підказки для заповнення форми. Наприклад, плейсхолдер у полях введення.

Валідацію на щойно відкритій порожній формі заборонено. Виняток – чернетки, коли користувач вже заповнював цю форму, через якийсь час повернувся до неї, а вона заповнена з помилками.

Види валідації

Існує три види валідацій: миттєва, втрата фокусу і відправлення форми.

Чим раніше інтерфейс повідомляє про помилку, тим краще – користувачеві простіше повернутися та виправити помилку.

Самий швидкий спосібповідомити про помилку – миттєва валідація. Але вона можлива лише у випадках, коли у процесі введення зрозуміло, що значення некоректне. Зазвичай такі помилки пов'язані з неправильною розкладкою клавіатури (кирилиця замість латиниці) або введенням літер у цифрове поле (ІПН, КПП та ін.). Для цих випадків ми використовуємо поля з масками: введення невідповідних символів у них заблоковано. Тому в наших інтерфейсах є лише два види валідації:

• за втратою фокусу – основний вид валідації
• по відправленню форми - для тих випадків, коли валідація зі втрати фокусу неможлива.

Валідація зі втрати фокусу Коли використовувати Як працює

Не валідуйте поля на порожнечу через втрату фокусу - не показуйте помилку якщо поле не заповнене, можливо, користувач повернеться і заповнить поле трохи пізніше. Показувати помилку в таких випадках можна лише після надсилання форми.

Валідація спрацьовує відразу після втрати фокусу, якщо значення у полі заповнено. Якщо знайдено помилку, поле підсвічується червоним. Фокус у це поле автоматично не повертається:

Текст помилки з'являється в тултипі, коли поле отримує наведення або фокус:

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

Червоне підсвічування знімається з поля, коли користувач почав виправляти помилкове значення.

Валідація при відправленні форми Коли використовувати

Використовуйте цей вид валідації, коли не можна перевірити поля втрати фокуса. Наприклад, для перевірки заповнення обов'язкових полів.

Як працює

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

При прокручуванні до першого поля від верхньої межі вікна до помилкового поля залишається відступ 48px-шість модулів.

Блокування кнопки надсилання

У невеликих формах, замість перевірки заповнення обов'язкових полів, можна блокувати кнопку відправлення форми. Використовуйте цю поведінку, коли очевидно, чому кнопка надсилання форми неактивна. Наприклад, на формі входу:

Як тільки заповнені всі обов'язкові поля – кнопка стає активною. Якщо після цього користувач стирає значення в одному з полів - кнопка знову повинна стати не активною.

Повідомлення про помилки

Про помилки можна повідомляти двома способами:

Тултипи Як працюють

Тултип із підказкою з'являється у двох випадках:

Під час наведення на поле з помилкою.

Коли поле з помилкою отримує фокус.

Якщо значення в полі з помилкою було змінено, втратило фокус, а потім знову опинилося у фокусі - тултип з текстом старої помилки вже не виникає. Це правило однаково працює для всіх типів валідацій: і втратою фокусу, і при відправленні форми.

Тултип за наведенням перекриває тултип по фокусу.

Тултип може з'являтися зверху або праворуч від контролю помилки, так щоб він не перекривав корисну інформацію:

Одноманітність поведінки та зовнішнього вигляду

Показуйте тултипи праворуч від полів. Якщо вони перекривають важливий вміст на сторінці, виводьте тултипи зверху. Дотримуйтесь однаковості, але пам'ятайте, що контент важливіший за нього.

Червоні тексти на сторінці Як працюють

Червоний текст помилки з'являється відразу, як відбулася валідація і помилкове поле підсвітилося.

Як тільки користувач почав виправляти значення, червоне підсвічування поля зникає, і колір тексту помилки змінюється на  #333.

Текст помилки пропадає через втрату фокусу і більше не з'являється, якщо поле наново отримує фокус. Це правило однаково працює для всіх типів валідацій: і втратою фокусу, і при відправленні форми.

Виводьте текст помилки праворуч, якщо на формі є місце, а повідомлення коротке. Так форму не доведеться розсувати, щоби показати помилку.

Якщо праворуч від поля немає місця для тексту, розсувайте форму та виводьте повідомлення під полем.

На складніших формах виводьте повідомлення про помилку в тултипі.

Валідація залежних полів

Залежні поля - поля, значення яких залежить друг від друга.

Помилки, пов'язані з порушенням залежності полів, ми показуємо після сабміту форми. Наприклад, ІПН і КПП. Якщо користувач вказав ІПН із 10 цифр, а поле з КПП залишив порожнім, після відправлення форми порожнє поле з КПП буде підсвічене.

ІПН може бути двох видів:

• 10-значний у юридичних осіб
• 12-значний у ІП.

Якщо користувач вказав ІПН із 12 цифр, значить організація - індивідуальний підприємець, і в неї немає КПП, отже, поле КПП заповнювати не потрібно. І навпаки, якщо заповнено КПП, а ІПН вказаний 12-значний, можливо невірно вказаний ІПН.

Підсвічування залежних полів зникає, коли користувач почав виправляти значення в одному з цих полів.

Якщо під час заповнення залежного поля порушено формат значення, повідомляйте про таку помилку при втраті фокусу. Наприклад, користувач ввів 3 цифри в полі ІПН і прибрав фокус. Таке поле має підсвітитися одразу.

приклад

Є форма з 5 полів:

• Назва організації - проста текстова, обов'язкова
• ІПН - 10 або 12 цифр, перевірка контрольної суми зі втрати фокусу, обов'язкова
• КПП - 9 цифр з перевіркою контрольної суми зі втрати фокусу, обов'язкове, якщо ІПН складається з 10 цифр
• Електронна пошта - адреса пошти, перевірка втрати фокусу по масці [email protected], необов'язкове
• Телефон - міжнародний формат, перевірка зі втрати фокусу по масці +00000000000, обов'язкова

Розбір помилок валідації сайту

Нарешті з'явився вільний час між нескінченною низкою замовлень, і я вирішив зайнятися своїм блогом. Спробуємо його покращити у плані валідації. Нижче у статті я розповім, що таке валідація сайту, коду htmlта css, навіщо вона потрібна та як привести сайт до стандартів на конкретному прикладі.

Що таке валідація сайту?

Простими словами це перевірка на відповідність стандартам. Щоб будь-який браузер міг відображати ваш сайт коректно. Великий вплив валідність сайту на просування не чинить, але гірше точно не буде.

Конкретний приклад проходження валідації для сторінки сайту

Візьмемо першу сторінку на моєму сайті - Кодування та декодування base64 на Java 8. Заб'ємо адресу сторінки у валідатор і дивимося результат:

Errors found while checking this document as HTML 4.01 Transitional! Result: 105 Errors, 67 warning(s) Так, картина вимальовується неприємна: більше сотні помилок і 67 попереджень - як взагалі пошуковики індексують мій блог, і заходять люди? Але не засмучуватимемося, а навчимося проходити валідацію, справляти помилки. Отже, перше попередження:

Зовнішньо до визначеного Parse Mode! validator може процеси документів, які є як XML (для документів, такі як XHTML, SVG, etc.) або SGML (для HTML 4.01 and prior versions). Для цього документа, інформація доступна була не достатня для визначення часткового режиму безмежно, тому, що: MIME Media Type (text/html) може бути використаний для XML або SGML документи типи Невідомі Document Type можуть бути розпізнані No XML declaration (e.g ) could be found at the beginning of the document. No XML namespace (e.g ) може бути підтверджено керуванням документа. Як default, validator is falling back to SGML mode. Warning No DOCTYPE found! Checking with default HTML 4.01 Transitional Document Type. No DOCTYPE Declaration може бути знайдено або переглянуто в цьому документі. Це, як правило, те, що документ не зазначає його документ типу вгорі. Це може також бути те, що DOCTYPE declaration contains spelling error, або що це не використовує правильну syntax. Document was checked using a default "fallback" Document Type Definition that closely resembles “HTML 4.01 Transitional”. Це одне і теж. А виправляється просто: на початку сторінки додати тег:

Перевіряємо, що у нас вийшло і бачимо, що одним цим тегом ми прибрали 105 помилок та 3 попередження! Тепер у нас залишилося лише 64 попередження. Починаємо розбирати їх по одному.

Warning: Тип типу, що відображається для елемента стилю, не потребує і повинен бути заміщений. From line 5, column 1; to line 5, column 23 /x-icon">↩↩↩↩↩A Це означає, що для елемента style не потрібен атрибут type – це зайве. На сторінці у нас два такі зауваження. Аналогічне попередження і по JavaScript:

Warning: Тип типу є необхідним для JavaScript ресурсів. From line 418, column 1; to line 418, column 31 ↩↩$(doc Таких у нас 8 помилок. Забираємо дані атрибути та ура – ​​ще на 10 попереджень менше!

Error: CSS: background: Перший argument для linear-gradient функцій повинен бути вгору, не вгору. At line 39, column 61 0%,#E8E8E8 100%);↩ border-r Наступна помилка - перший аргумент у linear-gradient має бути to top, а не top. Виправимо. Далі помилка:

Error: CSS: Parse Error. From line 65, column 13; to line 65, column 16 margin: 0 auto;↩padd Тут у мене неправильно закоментовано css. Треба просто прибрати цей рядок. Або закоментувати по-іншому /* та */. Я так зробив, як звик так.

Error: CSS: @import не може бути здійснений після будь-якого valid statement other than @charset and @import.. At line 88, column 74 0,600,700,300); початок файлу, і вона зникне.

Error: Bad value _blanck для позначення target on element a: Reserved keyword blanck used. From line 241, column 218; Тут не подобається значення атрибуту target, нам повідомляють, що треба використовувати «blank» без нижнього підкреслення спереду. .Прибираємо.

Error: End tag li seen, але вони були відкритими елементами. From line 379, column 2; to line 379, 6

↩ ↩↩

↩↩↩↩↩↩
↩↩
↩↩↩