Как стать автором
Обновить

Комментарии 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" />, то это по меньшей мере странно.

TheShock, Keyten В том-то и дело, <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. Мой пример выше, это всего-лишь пример. Не надо на его основании делать заключительные выводы. Суть заключается в том, что придумывать читабельные тэги — это утопия. Все это больше похоже на то, что верстальщикам стало скучно просто верстать, и хотелось бы внести разнообразие в свою работу. ¯\_(ツ)_/¯

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

Можно использовать кастомный тэг например 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'ы без классов нынче считается чем то очень плохим?

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


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

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

НЛО прилетело и опубликовало эту надпись здесь

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

А что, выбор лишь между безымянным дивом и зоопарком специфических контейнеров с говорящими названиями? Для карточек — свой, для адресов свой, для аннотаций третий, для библиографических записей четвертый, для… а, погодите, для красных и синих карточек мы же должны сделать разные контейнеры, это же разные карточки! /sarcasm off

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

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

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

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

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

И XSLT до кучи.

А SGML может вызвать культурный шок.

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

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

Можно еще верстать на теге 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>, а дальше просто уточняйте, что он содержит и как выглядит.

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

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

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

Зарегистрируйтесь на Хабре , чтобы оставить комментарий