Во многих домах есть комната, существующая только потому, что вокруг неё возвели четыре стены, и теперь ей нужно какое-то предназначение. В результате такие «комнаты-заглушки» используются чаще, чем все остальные комнаты дома, хоть изначально они для этого и не предназначались. Их универсальность и уникальность позволяют нам часто их изменять, не ограничиваться их целью и ощущать свободу их планировки.
Тег
div
во многом напоминает такие комнаты. Он является чистым листом. Он подходит для любого потока, позволяет управлять своими функциями, и может становиться всем, что мы пожелаем. Целые веб-сайты могут создаваться (и создаются) почти исключительно на одних div
. Загуглите «single div designs», и вы найдёте бесчисленное множество дизайнеров, демонстрирующих свои навыки владения CSS, превращая один div в любую форму, которая им понадобится.Иногда это вселяет трепет, но этой статье я хочу сказать, что нам следует двигаться дальше, к миру без div с именами классов или ID. В мир уникальных элементов HTML. Семантического HTML. Нам нужно сосредоточиться на основах.
После прочтения твита Хамона Холмгрена я создал проект со скучным названием Custom HTML Tags. В этом твите он говорит, что не стоит использовать div с именами классов для создания HTML-компонентов, а вместо этого применять специализированные теги HTML.
Красота в простоте. Специализированные теги HTML по умолчанию являются div-ами. Просто убрав точку-префикс перед именами классов, мы можем сохранить точно такие же стили, как и раньше. Соответствующие HTML и CSS будут более семантичными, а также потребуют меньше символов.
Задайтесь вопросом: сколько имён классов я назначил div-ам за свою жизнь? Когда вы ищете эти компоненты в своём HTML, то вы ищете сам div или имена классов?
Я изучил эти вопросы в своём проекте, превратившемся в мысленный эксперимент, и выяснил, что не только могу создать целую веб-страницу совершенно без использования div, но и могу уменьшить размер сайта, стилизовать всё при помощи правильного конвейера сборки и собрать самый маленький проект за всю свою жизнь.
anubisthejackle/custom-html-tags — этот проект в первую очередь является мысленным экспериментом. Скорее всего, он ещё очень сырой.
Но как насчёт доступности?
Я не специалист по доступности для людей с ограниченными возможностями, и не хочу им притворяться. Моя цель заключалась в создании этого проекта, а решать проблемы доступности я буду по мере их возникновения. Я связался со всеми специалистами по доступности, которых смог найти в Twitter, попросил их изучить страницу и дать свои рекомендации.
Также я отсканировал страницу несколькими сканнерами доступности. Она оказалась неидеальной, но мне кажется, результаты достаточно хороши, чтобы прекратить любые споры о том, что специализированный HTML никогда не сможет стать доступным для людей с ограниченными возможностями.
Как выполнялась стилизация
Я не дизайнер, и я не хотел тратить много времени на CSS, поэтому выбрал для этого проекта Tailwind CSS. Однако я не стал добавлять классы в HTML, потому что намеревался разделить концепции. Я воспользовался apply в таблице стилей, чтобы применить стили Tailwind непосредственно к специализированному HTML, при необходимости добавляя любые нужные мне специализированные CSS.
Как ни странно, мне показалось, что такой способ использования Tailwind демонстрирует его истинный потенциал. Мы сосредоточились на том, что встраиваемые классы являются эквивалентом встраиваемых стилей, и совершенно забыли про функцию apply.
Благодаря правильному конвейеру сборки мне удалось уменьшить размер таблицы стилей, оставив в нём только самое необходимое для работы страницы. То же самое относится и к JavaScript, а также к HTML. Все они миниатюризированы, что ускоряет загрузку страницы.
Можно ли реализовать то же самое на основе своих стилей, а не Tailwind? Разумеется. Tailwind необязателен, но в этом проекте я не хотел много думать над CSS, поэтому нашёл простое в настройке и использовании решение. Если вкратце, то он просто работает.
JavaScript
В этом проекте JavaScript использовался только для добавления доступности. До момента внесения обновлений для улучшения доступности специализированные теги HTML просто были эквивалентны стандартным конфигурациям div браузера, и это вполне работало. Но базовые теги HTML содержат аспекты, которые большинство разработчиков не учитывает: параметры ARIA по умолчанию.
Без них инструменты обеспечения доступности не знают, как работать с тегами, и от них не надо этого ожидать. Тем не менее, несложно создать специализированные элементы в JavaScript и назначить им необходимые атрибуты ARIA.
Непрактичность проекта
Сам по себе проект никогда не был рассчитан на практическое использование. Это был доведённый до крайности мысленный эксперимент для демонстрации того, насколько далеко мы можем зайти. Идея заключалась в том, что если мы можем дойти до такого большого масштаба, то нет никаких препятствий для реализации этого принципа в более мелких и сфокусированных масштабах.
Именно это я и выяснил. После освоения основ такую систему можно реализовать не полном масштабе, но и в относительно простой форме. Нет никаких причин не использовать специализированные теги HTML для отдельных компонентов в продакшн-проекте.
Если вкратце, то не существует абсолютно никаких причин для обязательного использования div в своих проектах.
Так зачем его использовать?
На правах рекламы
Серверы с бесплатной панелью управления VestaCP или HestiaCP для максимально удобного и быстрого размещения сайта. Любой параметр сервера (CPU, RAM, NVMe) можно увеличить в любой момент в пару кликов через удобную панель управления собственной разработки.
Подписывайтесь на наш чат в Telegram.
nullc0de
Мда, на лицо не понимание существующих веб стандартов, а их пишут не глупые люди, хоть решения вам могут не нравится, они выбраны как самое наилучшее решение проблемы и чтобы уменьшить количество побочных проблем…
Контекс применения вместо DIV использовать class ограничен, это усложнит логику приложений и сделает ее более медленной. А как быть если у нас несколько классов? Как быть если мы захотим поменять класс в рантайме?))) Этот подход пользуются в vuejs в контекст кастомные компонентов. В первую очередь DIV нужен, чтобы отделить JS кастомные компоненты от native, и уменьшить работу с DOM. Плюс DIV может быть не обязательно с классом, у него уже есть предопредленные свойства…
TheShock
А как быть если у нас несколько классов? Как быть если мы захотим поменять класс в рантайме?)))
Есть класс, который определяет суть, а есть классы — которые поведение и отображение. Как может поменяться суть элемента в рантайме? Был котиком, а стал машинкой? В чём проблема с "несколькими" классами? Несколько классов никуда не денутся, классы которые отображают состояние, а не суть — вполне остаются.
rotanev
Я меняю <div class=“open”/> на <div class=“close”/> с помощью JS функции toggle(). Суть поменялась?
TheShock
А что значит "опен" и "клоуз"? Это не их суть, это их состояние. Что именно "опен" и "клоуз"? Что это за класс? Или у вас открыто "ничто"?
Keyten
У вас был
<div class="menu open" />
и он менялся на<div class="menu close" />
.А должно стать
<menu class="open" />
, меняющийся на<menu class="close" />
.Если же вы хотите превращать
<menu-open />
в<menu-close />
или<open class="menu" />
в<close class="menu" />
, то это по меньшей мере странно.rotanev
TheShock, Keyten В том-то и дело,
<div/>
сам по себе универсален. При реализации вывода элементов я создам<div class="grid">
и с помощью JS функцииtoggle()
буду менять на<div class="list">
, мне не нужно знать что это за сущность (Пример).P.S. Абстракция в программировании не просто так существует :)
TheShock
Так в примере grid и list — лишь способы отображения. Давайте представим, что вы не знаете, в каком сейчас состоянии находится этот элемент? Как вы будете его искать? По селектору
div
? Самое интересное, что вы сами дали ему название, которое не связано ни с grid, ни с list:Да, и потому удительно, что так много верстальщиков не могут в базовую абстракцию. К примеру, вот вы не можете абстрагировать от отображения и акцентироваться на сути объекта.
А то, что вы можете менять объект не акцентируясь на сущности — это тоже правильно. Вот только при чём здесь вообще div'ы? Вы не сможете написать абстракцию для двоих разных элементов?
rotanev
Искать, это технологии из 2000-х. Сегодня сборкой клиентской части занимаются фреймверки (тот же React.js), который создает ссылки на объект:
Развитие HTML/CSS будет в этом направлении, а не в создании читабельных тэгов. Уже сейчас класс в CSS может иметь вид
.hf278yf713fy7g813 {}
, который «ссылается» на JS объектlet movies;
.На сегодняшний день, я не вижу смысла писать HTML/CSS «с нуля» ручками в блокноте, да еще чтобы потом открывать не React/Sass проект, а исходный код HTML/CSS, и пытаться его читать. Sass + React.js — доказали свою эффективность не на одном проекте.
P.S. Мой пример выше, это всего-лишь пример. Не надо на его основании делать заключительные выводы. Суть заключается в том, что придумывать читабельные тэги — это утопия. Все это больше похоже на то, что верстальщикам стало скучно просто верстать, и хотелось бы внести разнообразие в свою работу. ?\_(?)_/?
pfffffffffffff
Для автора статьи было бы откровением шаблон заторы типа jade:
.card-container
.card-title
Format-X22
Который лет 5 или больше уже теперь Pug, но память она такая, инертная :)
dronex
Можно использовать кастомный тэг например card-container вмести с классом если необходимо сам тег определяет суть блока, в то время как класс - состояние или свойство. Нормальная парадигма, правда есть один не очевидный недостаток, если вдруг ты не знаешь, что такой тэг уже существует в html, либо какой то из подключенных компонентов тоже использует кастомные теги с подобными именами - можно нарваться на конфликт.