DIV должен уйти: улучшаем HTML +24


AliExpress RU&CIS


Во многих домах есть комната, существующая только потому, что вокруг неё возвели четыре стены, и теперь ей нужно какое-то предназначение. В результате такие «комнаты-заглушки» используются чаще, чем все остальные комнаты дома, хоть изначально они для этого и не предназначались. Их универсальность и уникальность позволяют нам часто их изменять, не ограничиваться их целью и ощущать свободу их планировки.

Тег 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.

Теги:




Комментарии (45):

  1. nullc0de
    /#23158018

    Мда, на лицо не понимание существующих веб стандартов, а их пишут не глупые люди, хоть решения вам могут не нравится, они выбраны как самое наилучшее решение проблемы и чтобы уменьшить количество побочных проблем…

    Контекс применения вместо DIV использовать class ограничен, это усложнит логику приложений и сделает ее более медленной. А как быть если у нас несколько классов? Как быть если мы захотим поменять класс в рантайме?))) Этот подход пользуются в vuejs в контекст кастомные компонентов. В первую очередь DIV нужен, чтобы отделить JS кастомные компоненты от native, и уменьшить работу с DOM. Плюс DIV может быть не обязательно с классом, у него уже есть предопредленные свойства…

    • TheShock
      /#23158170

      А как быть если у нас несколько классов? Как быть если мы захотим поменять класс в рантайме?)))
      Есть класс, который определяет суть, а есть классы — которые поведение и отображение. Как может поменяться суть элемента в рантайме? Был котиком, а стал машинкой? В чём проблема с "несколькими" классами? Несколько классов никуда не денутся, классы которые отображают состояние, а не суть — вполне остаются.

      • rotanev
        /#23166090

        Я меняю <div class=“open”/> на <div class=“close”/> с помощью JS функции toggle(). Суть поменялась?

        • TheShock
          /#23170300 / -1

          А что значит "опен" и "клоуз"? Это не их суть, это их состояние. Что именно "опен" и "клоуз"? Что это за класс? Или у вас открыто "ничто"?

        • Keyten
          /#23170750 / +1

          У вас был <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
          /#23171492

          TheShock, Keyten В том-то и дело, <div/> сам по себе универсален. При реализации вывода элементов я создам <div class="grid"> и с помощью JS функции toggle() буду менять на <div class="list">, мне не нужно знать что это за сущность (Пример).

          P.S. Абстракция в программировании не просто так существует :)

          • TheShock
            /#23172296

            Так в примере grid и list — лишь способы отображения. Давайте представим, что вы не знаете, в каком сейчас состоянии находится этот элемент? Как вы будете его искать? По селектору div? Самое интересное, что вы сами дали ему название, которое не связано ни с grid, ни с list:


            <div id="items" class="grid">
              <div class="item">

            P.S. Абстракция в программировании не просто так существует :)

            Да, и потому удительно, что так много верстальщиков не могут в базовую абстракцию. К примеру, вот вы не можете абстрагировать от отображения и акцентироваться на сути объекта.


            А то, что вы можете менять объект не акцентируясь на сущности — это тоже правильно. Вот только при чём здесь вообще div'ы? Вы не сможете написать абстракцию для двоих разных элементов?


            <movies class="grid">
            <books  class="grid">

            • rotanev
              /#23172728

              Давайте представим, что вы не знаете, в каком сейчас состоянии находится этот элемент?

              Искать, это технологии из 2000-х. Сегодня сборкой клиентской части занимаются фреймверки (тот же React.js), который создает ссылки на объект:

              let movies = React.createElement('div', {class: 'grid'});
              

              Развитие HTML/CSS будет в этом направлении, а не в создании читабельных тэгов. Уже сейчас класс в CSS может иметь вид .hf278yf713fy7g813 {}, который «ссылается» на JS объект let movies;.

              На сегодняшний день, я не вижу смысла писать HTML/CSS «с нуля» ручками в блокноте, да еще чтобы потом открывать не React/Sass проект, а исходный код HTML/CSS, и пытаться его читать. Sass + React.js — доказали свою эффективность не на одном проекте.

              P.S. Мой пример выше, это всего-лишь пример. Не надо на его основании делать заключительные выводы. Суть заключается в том, что придумывать читабельные тэги — это утопия. Все это больше похоже на то, что верстальщикам стало скучно просто верстать, и хотелось бы внести разнообразие в свою работу. ?\_(?)_/?

    • pfffffffffffff
      /#23158650

      Для автора статьи было бы откровением шаблон заторы типа jade:

      .card-container

      .card-title

      • Format-X22
        /#23161332

        Который лет 5 или больше уже теперь Pug, но память она такая, инертная :)

    • dronex
      /#23166092

      Можно использовать кастомный тэг например card-container вмести с классом если необходимо сам тег определяет суть блока, в то время как класс - состояние или свойство. Нормальная парадигма, правда есть один не очевидный недостаток, если вдруг ты не знаешь, что такой тэг уже существует в html, либо какой то из подключенных компонентов тоже использует кастомные теги с подобными именами - можно нарваться на конфликт.

  2. TheShock
    /#23158168

    *не в ту ветку ответил

  3. Sergei_Tishkov
    /#23158286

    У меня есть пара мыслей на тему статьи:
    1) Не вижу ничего плохого в том, чтобы делать разметку таким образом в личном проекте типа лендинга и т.п., где не будет много JS. Действительно, почему нет? HTML будет выглядеть короче и лаконичнее, а поддерживать это все равно тебе, а не кому-то другому.
    2) Если делать такой проект на заказ, например, на фрилансе, то возникают сомнения. Этот подход не распространен, а значит, что любой человек, который после тебя будет дорабатывать этот проект, будет вынужден приспособиться к новой для себя парадигме.
    Меня, когда я работал на стройке, строители научили фразе «лучше безобразно, но единообразно» :) Нынешний подход к разметке как минимум неплох, плюс согласен с комментатром выше, HTML принял такой вид в ходе коллективного творческого подхода миллионов программистов, а значит, он как минимум хорош, если не идеален.
    3) Если делать проект с минимумом JS в коллективе, то надо будет договориться всей тимой, какие компоненты использовать, чтобы не было каши. Это не сильно отличается от случаев, когда у команды был общий набор классов, они все были описаны в CSS, и сейчас будут описаны в CSS, только без "." в селекторах.
    4) Если писать проект в таком стиле, например, на Реакте, то получается странный момент. С одной стороны, можно делать такие HTML тэги, они не помешают Реакту, т.к. он рендерит кастомные html теги, если они называются с маленькой буквы. И в будущем, если понадобится накинуть на них логику, просто глобальной автозаменой все <my-custom-tag></my-custom-tag> переименовываешь в , удаляешь содержимое, и ctrl+c ctrl+v импорт компонента в файл. С другой стороны, почему сразу не сделать на компонентах? Реакт (как и любое другое популярное решение на компонентах типа Вью или Ангуляра) хорош тем, что он очень удобно инкапсюлирует стили, логику и разметку в одном-двух файлах. Недостатком станет то, что чуть-чуть оперативки на рендер потребуется. Но это все равно такие копейки, тем более, если компонент статический, и в нем ререндера не будет. Так что мы получаем разбросанную разметку и стили, вместо того, чтобы получить инкапсюлированные, и более гибкие разметку и стили с легкой возможностью привязывать логику.

    Итого мои выводы:
    1) Использовать кастомный HTML для себя — норм
    2) для дяди — сомнительно
    3) для дяди в команде — сомнительно вдвойне
    4) на фреймворке/рендер либе — бесполезно

  4. ykppon
    /#23158288 / +1

    Началось все с дома, так что, получается, вы предлагаете каждый отдельный кирпич называть не кирпичом, только потому что у него поменяется цвет? Белый кирпич и красный кирпич - всё равно каждый из них кирпич. Так почему вдруг в вебе каждый блок должен иметь уникальное название?
    Не каждый блок должен иметь класс, но как тогда называть блок без имени, если div должен умереть?

    • TheShock
      /#23158328

      Что за "блок без имени"? Если у какого-то блока настолько нету роли, что вы не можете придумать ему имя — просто удалите его.

      • Kroid
        /#23158558

        Вёрстка поедет.

        • TheShock
          /#23163382 / -1

          У каждого элемента есть предназначение, а значит можно дать имя. Ужасно поддерживать вёрстку, в которой есть куча безымяных дивов и спанов. Смотришь на него и думаешь: "чего его добавили?". Это из разряда называть реальные переменные в реальной программе "foo".


          Но почему-то среди верстальщиков быдлокодинг считается нормальной практикой.

          • Kroid
            /#23163818

            Имя элемента несёт семантическую роль. Это шапка, это артикль, и тд. Для нужд вёрстки приходится использовать куда больше элементов, чем это требуется для семантики, поэтому никуда не деться от кучи "лишних" дивов. Например, какая семантическая роль будет у элемента, чьё предназначение - быть контейнером для стиля clearfix?

            • TheShock
              /#23164034

              Например, какая семантическая роль будет у элемента, чьё предназначение — быть контейнером для стиля clearfix?

              ClearFixContainer? Хотя когда я последний раз верстал 5 лет назад — клирфиксом никто не пользовался уже вроде, были решения получше.

              • Kroid
                /#23164104

                Я могу ещё тысячу разных вариаций применений тегов div сказать, их все будем в стандарт добавлять?

                • TheShock
                  /#23172306

                  Я могу ещё тысячу разных вариаций применений тегов div сказать, их все будем в стандарт добавлять?

                  В какой стандарт? Вы пока отвечали на последний комментарий — забыли всю предыдущую ветку?

                  • Kroid
                    /#23172342

                    >В какой стандарт?

                    HTML 6, вестимо. Или какой там следующий номер по счету.

                    >Вы пока отвечали на последний комментарий — забыли всю предыдущую ветку?

                    Я помню не только лишь ветку, но и саму статью. Если дивы должны умереть, то на каждую функцию, причём не только семантическую, но и техническую, надо вводить новый тег. Вопрос, зачем? Нет смысла отделять один кирпич от другого, если это оба кирпичи, разве что разных цветов, как говорил верхний комментатор.

                    • TheShock
                      /#23174322

                      А зачем вводить в стандарт?

      • ykppon
        /#23158616

        А что оставлять div'ы и span'ы без классов нынче считается чем то очень плохим? Должен ли я думать как назвать дочерей какого то '.item', если могу просто кинуть div, подразумевая его как 'item__title' и span как 'item__description', постучать в таблице стилей к ним как .item>div и .item>span. Разве сделав так я не выиграю некоторое количество памяти, если количество элементов будет стремиться к бесконечности?

        p.s. Я всегда чувствую себя дико глупо, когда пишу комментарии, но неужели мой подход ущербный?

        • Cawabunga
          /#23158886 / +1

          На сколько я знаю, в вашем случае браузер сначала найдет все дивы, а только потом будет искать родителя .item. То есть обход браузеры делают справа налево.

        • TheShock
          /#23163396

          А что оставлять div'ы и span'ы без классов нынче считается чем то очень плохим?

          Всегда считалось. По крайней мере среди людей, которые как-то стараются писать поддерживаемый код


          Разве сделав так я не выиграю некоторое количество памяти, если количество элементов будет стремиться к бесконечности?

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

      • Tom_Xor
        /#23158888

        Блок для стилизации.

        • TheShock
          /#23163394

          Для какой именно стилизации? Почему бы не прописать какую конкретно цель он исполняет? Как можно поддерживать код в котором висят безымяные дивы?

      • nazz340
        /#23166100

        Ок, а если у роль блока - тупо быть блоком?

        • TheShock
          /#23170304

          так и представляю в программировании class Class, ведь роль этого класса — быть классом. Глупость, не находите?

  5. WFF
    /#23158476

    Не очень понятно, если я определил, что хочу на всей странице div { box-sizing: border-box; } то эти элементы под это правило не попадают?

    • Sayonji
      /#23161236 / +1

      Я вам даже больше скажу, автор уже наврал: неизвестные элементы ведут себя как span, а не как div.

  6. JTG
    /#23158742

    Ещё немного, и они заново изобретут XML.

  7. FSA
    /#23159758

    Ну ладно. Сделал я свой новый тег. А потом приняли новый стандарт для разметки где такое имя будет задействовано. Вероятность, конечно, не очень большая, но вдруг. Хорошо, если сайт живой и его исправят. А если это какой-то архив и никто его не будет адаптировать для новых браузеров?

    • andreymal
      /#23160152 / +1

      Стандарт обещает, что не будет создавать новых тегов с дефисом в имени. Для кастомных тегов, соответственно, использование дефиса обязательно

  8. jakobz
    /#23160672 / +4

    Можно еще верстать на теге b вместо div - на две буквы меньше - тоже круто будет.

  9. moroz69off
    /#23162088

    Проблема решена

  10. ozonar
    /#23163646

    Можно пойти от обратного - на что бы жаловались разработчики, если бы этот подход был стандартом?

    Первое, что приходит на ум - неструктурированность. Есть тэги, которые являются только названиями, и есть те, которые модифицируют контент стандартным html образом.

    Это как минимум запутает новичков, да и для остальных работа с такими данными будет сложнее, чем с изначальной html структурой.

  11. Fatik
    /#23165322

    Не имеет смысл, давать каждому кирпичу свое имя. От этого кирпич останется кирпичом. А вот собрать кирпичи, которые образуют лестницу к веранде и назвать их "лестница к веранде" смысл есть.
    Иными словами, код:


    <card-container>
      <card-title></card-title>
      <card-description><card-description>
    </card-container>

    ничем не отличается от


    <div class=“card-container”>
      <div class=“card-title”></div>
      <div class=“card-description”></div>
    </div>

    Мы просто притворились, что не знаем что это div.
    Давайте вместо этого сделаем кастомный компонет card. В странице напишем:


    <card/>

    И не будем перегружать верстку деталями.
    Если мы просто переменуем сущестующие компоненты, мы из стандартной каши получим кашу нестандартную)

  12. habramaru
    /#23166084

    Скорее наоборот. Нужно оставить только "типизированные дивы": вот тут таблица, тут текст, тут картинка. Ну и плюс стили.

    Есть только <div>, а дальше просто уточняйте, что он содержит и как выглядит.

    • TheShock
      /#23170306

      И зачем тогда вообще лишняя сущность div?

  13. nordfox
    /#23166086

    Автору следует написать в спортлото и W3C. В W3C же одни неграмотные олды сидят. Может в языке С отменим массивы, оставим одни указатели, или наоборот? По факту и то и то доступ к памяти. Это разные вещи. Да за такое Керниган и Ричи башку свернули бы, если смогли.

  14. nybras
    /#23167942

    Хм. Я всё описываемое уже лет 15 назад делал в xul xbl ,жаль это w3c стандартом не стало. Но видимо были причины.. А вообще правильно, сейчас большинство web аппликаций не про html вообще. Если все всё делают в условном react или vue то почему бы такой компонентный подход не стандартизировать?