Важливо розрізняти, коли щось deprecated, а коли — obsolete чи removed. Наприклад, такі теги, як
<font>, <center> чи <menuitem> — deprecated, вони можуть частково підтримуватись якимись бравзерами для зворотньої сумісності. Вжиток таких тегів втратив сенс через появу CSS, але їхнє використання в більшості своїй не сильно шкодить.А от, до прикладу,
<keygen> чи <applet> видалено зі специфікації повністю, і бравзери їхній функціонал не підтримують, навіть для зворотньої сумісності, бо ця підтримка ставить під сумнів кібербезпечність сторінки.Коротко життєвий шлях HTML-тегу виглядає приблизно так: Proposed → Living Standard → Deprecated → Obsolete → Removed. Їхню ж долю вирішують WHATWG разом з W3C.
Приблизно причини депрекації можна розділити на такі умовні групи:
Представлення проти семантики.
HTML подолав шлях від того, як сторінка виглядає, до того, що означають її складові. Тому певні теги набувають статусу deprecated через те, що їхня роль тепер виконується CSS. Прикладом можна навести ті ж
<font>, <center>, <marquee> та інші.Безпека та підтримка
Деякі теги були покликані розширити функціонал сторінки та надати можливість декларативно його описувати. Але те, що на папері виглядало як чудове рішення, іноді на практиці ставало справжнім пеклом для підтримки. А часом — і суттєвою діркою в безпеці, як той самий
<keygen>. Він був покликаний створювати public-private пару ключів у бравзері та надсилати публічний ключ при сабміті форми. Що ж могло піти не так? Питань, насправді, на практиці, виникло багато: різні бравзери могли генерувати ключі різної надійності, за бажання зловмисний код міг спокійно вставити власний <keygen> у сторінку, непрозорий механізм, відсутність API для керування ключами та інші.Кращі альтернативи
Іноді призначення старого тегу ставало частиною ширшої специфікації нового, як у випадку з
acronym, який рекомендується заміняти на abbr.Чому нам важливо дотримуватися рекомендацій специфікації? Я знаю, бравзери відображають наші сторінки незалежно від того, чи дотримані найостанніші стандарти, а чи у вас там вилито три баняки div-супу. Але не варто забувати про асистивні технології, те саме SEO, та взагалі передбачуваність розмітки. Якщо ви раптом вирішите використати
<center> для розмітки якоїсь центральної секції, ніхто не може гарантувати, що усі бравзери викинули його зворотню підтримку, і якийсь із них раптом не почне центрувати текст.Так само це може перетворитися на "тихий" технічний борг, бо хто ж звертатиме увагу на якийсь там HTML? Але це може потягнути за собою такі самі "тихі" баги: відображення елементів може відрізнятися, ба більше, бравзери можуть включити quirks-mode, який може зламати ще більше.
Очевидно, що дотримання рекомендацій специфікації дозволить вам зробити вашу розмітку більш стійкою до викликів майбутнього і при цьому не оглядатися постійно назад на помилки минулого.
Веб знаходиться в постійному русі і безперервно розвивається, HTML у тому числі, не зважаючи на те, що багато хто з нас ігнорує його існування. Тому важливо звертати увагу на цей розвиток, аби не опинитися одного дня на узбіччі у валідаційній канаві.
До речі, зʼявилися думка присвятити цей тиждень HTML та зробити короткий огляд його основних версій, а також розібрати, чому світ ніколи не побачить HTML 6. Дайте знати в коментарях, чи хотіли б ви почитати про це якомога скоріше.
І не забувайте про вподобайки. І про донати на детектори дронів для 115 бригади на Покровський напрямок.
Всім цьом у лобіка і гарного початку тижня.
@babichdev