Comments 46
Контекс применения вместо DIV использовать class ограничен, это усложнит логику приложений и сделает ее более медленной. А как быть если у нас несколько классов? Как быть если мы захотим поменять класс в рантайме?))) Этот подход пользуются в vuejs в контекст кастомные компонентов. В первую очередь DIV нужен, чтобы отделить JS кастомные компоненты от native, и уменьшить работу с DOM. Плюс DIV может быть не обязательно с классом, у него уже есть предопредленные свойства…
А как быть если у нас несколько классов? Как быть если мы захотим поменять класс в рантайме?)))
Есть класс, который определяет суть, а есть классы — которые поведение и отображение. Как может поменяться суть элемента в рантайме? Был котиком, а стал машинкой? В чём проблема с "несколькими" классами? Несколько классов никуда не денутся, классы которые отображают состояние, а не суть — вполне остаются.
Я меняю <div class=“open”/> на <div class=“close”/> с помощью JS функции toggle(). Суть поменялась?
А что значит "опен" и "клоуз"? Это не их суть, это их состояние. Что именно "опен" и "клоуз"? Что это за класс? Или у вас открыто "ничто"?
У вас был <div class="menu open" /> и он менялся на <div class="menu close" />.
А должно стать <menu class="open" />, меняющийся на <menu class="close" />.
Если же вы хотите превращать <menu-open /> в <menu-close /> или <open class="menu" /> в <close class="menu" />, то это по меньшей мере странно.
<div/> сам по себе универсален. При реализации вывода элементов я создам <div class="grid"> и с помощью JS функции toggle() буду менять на <div class="list">, мне не нужно знать что это за сущность (Пример).P.S. Абстракция в программировании не просто так существует :)
Так в примере grid и list — лишь способы отображения. Давайте представим, что вы не знаете, в каком сейчас состоянии находится этот элемент? Как вы будете его искать? По селектору div? Самое интересное, что вы сами дали ему название, которое не связано ни с grid, ни с list:
<div id="items" class="grid">
<div class="item">P.S. Абстракция в программировании не просто так существует :)
Да, и потому удительно, что так много верстальщиков не могут в базовую абстракцию. К примеру, вот вы не можете абстрагировать от отображения и акцентироваться на сути объекта.
А то, что вы можете менять объект не акцентируясь на сущности — это тоже правильно. Вот только при чём здесь вообще div'ы? Вы не сможете написать абстракцию для двоих разных элементов?
<movies class="grid">
<books class="grid">Давайте представим, что вы не знаете, в каком сейчас состоянии находится этот элемент?
Искать, это технологии из 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. Мой пример выше, это всего-лишь пример. Не надо на его основании делать заключительные выводы. Суть заключается в том, что придумывать читабельные тэги — это утопия. Все это больше похоже на то, что верстальщикам стало скучно просто верстать, и хотелось бы внести разнообразие в свою работу. ¯\_(ツ)_/¯
Для автора статьи было бы откровением шаблон заторы типа jade:
.card-container
.card-title
Можно использовать кастомный тэг например card-container вмести с классом если необходимо сам тег определяет суть блока, в то время как класс - состояние или свойство. Нормальная парадигма, правда есть один не очевидный недостаток, если вдруг ты не знаешь, что такой тэг уже существует в html, либо какой то из подключенных компонентов тоже использует кастомные теги с подобными именами - можно нарваться на конфликт.
*не в ту ветку ответил
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) на фреймворке/рендер либе — бесполезно
Началось все с дома, так что, получается, вы предлагаете каждый отдельный кирпич называть не кирпичом, только потому что у него поменяется цвет? Белый кирпич и красный кирпич - всё равно каждый из них кирпич. Так почему вдруг в вебе каждый блок должен иметь уникальное название?
Не каждый блок должен иметь класс, но как тогда называть блок без имени, если div должен умереть?
Что за "блок без имени"? Если у какого-то блока настолько нету роли, что вы не можете придумать ему имя — просто удалите его.
У каждого элемента есть предназначение, а значит можно дать имя. Ужасно поддерживать вёрстку, в которой есть куча безымяных дивов и спанов. Смотришь на него и думаешь: "чего его добавили?". Это из разряда называть реальные переменные в реальной программе "foo".
Но почему-то среди верстальщиков быдлокодинг считается нормальной практикой.
Имя элемента несёт семантическую роль. Это шапка, это артикль, и тд. Для нужд вёрстки приходится использовать куда больше элементов, чем это требуется для семантики, поэтому никуда не деться от кучи "лишних" дивов. Например, какая семантическая роль будет у элемента, чьё предназначение - быть контейнером для стиля clearfix?
Например, какая семантическая роль будет у элемента, чьё предназначение — быть контейнером для стиля clearfix?
ClearFixContainer? Хотя когда я последний раз верстал 5 лет назад — клирфиксом никто не пользовался уже вроде, были решения получше.
Я могу ещё тысячу разных вариаций применений тегов div сказать, их все будем в стандарт добавлять?
Я могу ещё тысячу разных вариаций применений тегов div сказать, их все будем в стандарт добавлять?
В какой стандарт? Вы пока отвечали на последний комментарий — забыли всю предыдущую ветку?
>В какой стандарт?
HTML 6, вестимо. Или какой там следующий номер по счету.
>Вы пока отвечали на последний комментарий — забыли всю предыдущую ветку?
Я помню не только лишь ветку, но и саму статью. Если дивы должны умереть, то на каждую функцию, причём не только семантическую, но и техническую, надо вводить новый тег. Вопрос, зачем? Нет смысла отделять один кирпич от другого, если это оба кирпичи, разве что разных цветов, как говорил верхний комментатор.
А что оставлять div'ы и span'ы без классов нынче считается чем то очень плохим? Должен ли я думать как назвать дочерей какого то '.item', если могу просто кинуть div, подразумевая его как 'item__title' и span как 'item__description', постучать в таблице стилей к ним как .item>div и .item>span. Разве сделав так я не выиграю некоторое количество памяти, если количество элементов будет стремиться к бесконечности?
p.s. Я всегда чувствую себя дико глупо, когда пишу комментарии, но неужели мой подход ущербный?
На сколько я знаю, в вашем случае браузер сначала найдет все дивы, а только потом будет искать родителя .item. То есть обход браузеры делают справа налево.
А что оставлять div'ы и span'ы без классов нынче считается чем то очень плохим?
Всегда считалось. По крайней мере среди людей, которые как-то стараются писать поддерживаемый код
Разве сделав так я не выиграю некоторое количество памяти, если количество элементов будет стремиться к бесконечности?
Нет, конечно. С точки зрения оптимизации вы сделаете только хуже. Но если бы это было чуть-чуть лучше — ущерб для читабельности всё-равно сильно большей, чем потенциальный выигрыш в оптимизациях.
Для какой именно стилизации? Почему бы не прописать какую конкретно цель он исполняет? Как можно поддерживать код в котором висят безымяные дивы?
Ок, а если у роль блока - тупо быть блоком?
Ещё немного, и они заново изобретут XML.
Ну ладно. Сделал я свой новый тег. А потом приняли новый стандарт для разметки где такое имя будет задействовано. Вероятность, конечно, не очень большая, но вдруг. Хорошо, если сайт живой и его исправят. А если это какой-то архив и никто его не будет адаптировать для новых браузеров?
Можно еще верстать на теге b вместо div - на две буквы меньше - тоже круто будет.
Можно пойти от обратного - на что бы жаловались разработчики, если бы этот подход был стандартом?
Первое, что приходит на ум - неструктурированность. Есть тэги, которые являются только названиями, и есть те, которые модифицируют контент стандартным html образом.
Это как минимум запутает новичков, да и для остальных работа с такими данными будет сложнее, чем с изначальной html структурой.
Не имеет смысл, давать каждому кирпичу свое имя. От этого кирпич останется кирпичом. А вот собрать кирпичи, которые образуют лестницу к веранде и назвать их "лестница к веранде" смысл есть.
Иными словами, код:
<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/>И не будем перегружать верстку деталями.
Если мы просто переменуем сущестующие компоненты, мы из стандартной каши получим кашу нестандартную)
Скорее наоборот. Нужно оставить только "типизированные дивы": вот тут таблица, тут текст, тут картинка. Ну и плюс стили.
Есть только <div>, а дальше просто уточняйте, что он содержит и как выглядит.
Автору следует написать в спортлото и W3C. В W3C же одни неграмотные олды сидят. Может в языке С отменим массивы, оставим одни указатели, или наоборот? По факту и то и то доступ к памяти. Это разные вещи. Да за такое Керниган и Ричи башку свернули бы, если смогли.
Хм. Я всё описываемое уже лет 15 назад делал в xul xbl ,жаль это w3c стандартом не стало. Но видимо были причины.. А вообще правильно, сейчас большинство web аппликаций не про html вообще. Если все всё делают в условном react или vue то почему бы такой компонентный подход не стандартизировать?
DIV должен уйти: улучшаем HTML