Comments 92
Вы отходите от стандарта т.к. все теги регламентированы по своей семантике и существуют соглашения о именовании тегов
Если использовать имена тегов без черточек - да. Это уход от стандарта, но - можно именовать теги как my-tag в таком случае стандарт соблюден
+ из-за нарушения стандарта в случае с именованием тегов - не наступает никаких последствий - то есть да правило нарушено - но ничего плохого из-за этого не происходит.
Вы упираетесь в сугубо личное понятие лаконичности и читаемости в место того, чтобы соответствовать стандартам. Люди знающие стандарты HTML будут все равно с трудом читать вашу разметку и без ваших пояснений никак не обойтись
Нормально люди будут читать такие теги, будут видеть говорящее имя. Да любое восприятие личное, нет же какого-то общественного восприятия? Это какая-то философия а не аргумент.
У вас будут проблемы с SEO
Не будет проблем с SEO. Еще раз - мы продолжаем использовать теги h1-h6, strong, article, form и так далее - а отказываемся только от div - который не несет в сеюе никакой семантики.
Ваша верстка не семантичная
Семантика - https://ru.wikipedia.org/wiki/Семантика - это буквально смысл.
И я как раз и призываю вкладывать смысл в названия тегов, английскими словами. Опять же размечать списки с помощью <li> параграфы <p> а меню выносить в <nav>
То есть моя верстка - семантичная , а div class - не семантично
У вас будут проблемы со скринридером
У всех будут проблемы со скринридером кто не оптимизировал свой сайт под него, особенно если это electron приложение с доской задач а-ля trello
Вы не экономите количество символов т.к. для каждого элемента вновь приходится писать вам display:block
Да нет цели эконоить символы я прошу вместо </div> писать </person> это конечно больше символов - чтобы явно видеть какие теги закрываются и да оучше писать в css свойство display чтобы по css коду явно было видно как этот элемент отображается. Я за наглядность, а не за экономию символов.
В итоге больше бойлерплейта пишите т.к. люди использующие классы в CSS переиспользуют куски стилей. Взгляните как пример на tailwind
Бойлерплейта в итоге не больше. Я же не говорю отказываться от css классов, так же их можно переиспользовать. Но если оформление какого-то блока индивидуально - то его можно записать в сили тега а не в класс который иначе бы использовался в проекте только один раз
Ваша разметка хуже сжимается алгоритмами сжатия
В ответе на другой комментарий я разобрал этот вопрос - не не хуже а так же или лучше.
Да и блин, вы серьезно будете парится из-за пары килобайт разницы в сжатии на всю html страницу?
Результаты сжатия gzip
Вот папка с примерами файлов и сжатыми их версиями
Вы можете напороться на то, что выйдет новый HTML6 тег, а он у вас уже в проекте под другим соусом и все сломается
Если использовать теги с черточками то нет.
Шанс что повится тег с таким же вот прям именем очень низкий.
То есть чисто теоретически - могу, а могу и не напороться. Мы недавно все напоролись на то что докер образы перестали пулиться - фигня случается, адаптируемся.
Что случится если появится новый тег? Браузер для него свои стили допишет? Обычно я использую некое подобие reset.css , но может, действительно может где-то чутка поеет верстка - поправить дело 5 минут. В вебе постоянно что-то обновляется и меняется, потому мы и занимаемся поддержкой.
Но все эе вы понимаете насколько низкий шанс такого случая?
Ваш подход допускает использование deprecated тегов которые выходят из обихода
Допускает - но это на совести разработчика - не надо именовать свои теги названиями существующих пусть и в прошлом тегов, хоть на работе сайта это никак и не отразится.
Вы игнорируете доступные форматы микроразметки типа open graph мечтая о том, что когда-нибудь примут ваши теги (к счастью никогда не примут)
Я их не игнорирую - они просто за рамками этой статьи и никак не связаны с именованием тегов. Opengraph остается opengraph'ом и так же пишется, микроразметка - так же добавляется.
Я не мечтаю и это не мои теги ... даже не знаю что на это сказать сказать... я же не новый стандарт вам втюхиваю - это ваши теги - ваши названия тегов которые вы придумаете сами так же как придумываете названия переменным.
Игнорируете факт, что современные веб-фреймворки уже позволяют писать в таком стиле, о каком вы пишите, компилируя все в итоге в православный div элемент и позволяя избежать проблем из всех пунктов выше.
Вот именно что фреймворки - синтаксический сахар и в нем все равно внутри "православный" div. Блин ощущение что я с верующим спорю о боге ))) нет проблем в пунктах выше - нечего избегать.
Поддержка устройств у вас получится на выходе тоже ограниченная.
Тому нет доказательств. Я проверял, на телевизорах, смарт-часах, разумеется телефонах, старых iphone 4,5 , дополнительно на сайте browserstack смотрел с разных устройств.
Могу сказать что это не работает в IE6. ну и в терминальных браузерах типа links , вот эти теги всегда отображаются как строчные элементы.
Текстовый контент в RSS лентах будет некорректно оформлен при применении кастомной разметки
Я не понял что вы имеете ввиду... RSS это отдельный XML формат , для генерации rss пишут отдельные скрипты которые берут контент из БД и отдают xml
Ну не нужно размечать текст ВЕЗДЕ своими тегами. Но опять же если текстовый контент в RSS ленте разметить через дивы с классами - тоже ерунда получится.
Ну и в целом я предлагаю повысить читаемость кода именно веб-приложений, онлайн игр, приложений кинотеатра для смарт-тв(они тоже на html написаны), калькуляторов всяких, интерактивных карт, почтовых клиентов, crm, админок, ПРИЛОЖЕНИЙ - которые чтобы увидеть надо пароль ввести - которые не индексируются, в которых нет контента для запуска screen reader, приложений которые пишется под свою webview / electron / cordova , таких как slack , как веб-версия телеграм или whatsapp , а не чисто контентных/новостных сайтов где самое главное не просесть в поисковике и добится максимально быстрой индексации и ранжирования.
Если я правильно помню, никто не даёт гарантий, как оно будет работать на самом деле. И это страшно.
Если хочется так сильно верстать компонентами - так попробуйте react/vue, где они представлены ровно в виде "кастомных тегов".
Не правильно помните, есть пруфы где кто-то отказывается от того что теги с кастомными именами будут работать? Эти теги часть спецификации html5.
Я и верстаю компонентами, речь не о компонентах а о нейминге тегов.
Внутри компонентов реакт, разработчики все так же пишут <div className="go"> так что это не решает проблемы. JSX реакта это не html, я пишу о html-тегах.
Представьте что у вас половина переменных в коде будет называться не просто `count` или `person` а всегда будут вложены в объект с одним и тем же именем по всей кодовой базе, например data
не count , а data = { class: 'count', value: 1 } не person а data = { class: 'person', value: 'Bob'}
вот то же самое и происходит с div , в html div это такой вот безликий объект data
окей, что будем делать, если хром зарелизит какой-нибудь html6, где все наши loader и т.п. теги будут зарезервированы? экстренно перевёрстывать весь сайт?
теги с черточками в названии не будут зарезервированы, это гарантировано на сколько это возможно спецификацией html
эта будущая проблема надуманна, в конце концов да - замените пару тегов на их же с префиксом
хром зарелизил обязательный https так что куча старых сайтов перестало открываться
CORS когда-то сломал еще миллионы сайтов
и сайты сейчас чаще перписывают из-за обновления js и deprecated какого-нибудь браузерного api , кастомные имена тегов рисков не добавляют
а вот компоненты реакт как раз таки "после обеда уже легаси"
сначала с классовых их на хуки надо переписывать, а то новые либы из npm не работают, сейчас вот серверные компоненты завезли
использование фреймворка в этом плане добавляет гораздо больше нестабильности чем возможные будущие обновления брузера и спецификации html, но нас это как видите не останавливает и мы продолжаем массово обновлять веб-приложения так что не парьтесь ни к чему плохому использование своих имен тегов не приведет
Так для этого придумали <!DOCTYPE>. У html6 он должен быть другим, хз за что автора минусят, семантические теги это довольно удобно (и их использует много кто, например, гугл.)
Вы забываете о семантике. И тут основной минус вашей верстки, то что понятно вам, уже не понятно поисковикам. div это абстрактный блок, но если вы замените h1 например на main-title и h2 на second-title вы потеряете в семантичности верстки, если пренебречь правилами семантики и забить на все устройства чтения веба кроме современных браузеров, ваш подход имеет право на жизнь. Но практического смысла в нем никакого нету, для уменьшения количества бойлерплейта в коде пользуйтесь современными фрейиворками и/или шаблонзаторами. А также вы забываете про стандарты, а они не просто так. Надеюсь мне не доведётся работать на проектах, где надо учить собственные хтмл теги, которые ничего кроме кастомного имени под собой не имеют - абсолютно не нужные мне знания, которые затормозят вход на проект.
в стать об этом написано - читайте внимательно - в частности про заголовки
заменять в первую очередь я как раз предлагаю абстрактные div и span
но если вы замените h1 н
а я не заменю h1 потому что это нецелесообразно, но если мне по каким-то другим причинам(которых я пока не придумал) понадобится сделать кастомный тег для заголовка то я пропишу ему role="heading" aria-level="1" так что семантика будет сохранена.
Практический смысл как раз таки есть в моем подходе, а вот практического смысла писать div вместе с атрубутом class - нет
В практическом смысле в памяти браузера объект с установленным атрибутом занимает больше места , ну если совсем грубо то как-то так:
<div class="test"></div>
// в памяти браузера это
HTMLElement {
...
nodeName: 'div'
attributes: [ class ]
classNames: ['test']
...
}
<test></text>
// в памяти браузера это
HTMLElement {
...
nodeName: 'test'
...
}при прочих равных и одинаковой функциональности этот тег меньше жрет всех ресурсов, с одной стороны это мелочи, с другой - тегов тысячи ... но если уж вообще рассуждать о некотором практическом смысле - то все же - чем меньше свойств тем быстрее работает. Да компы быстрые не играет роли свой тег или блок с классомб по скорости там тысячные доли миллисекунды разницы, но это все равно просто не имеет смысла, тому нет причин больше печатать чтобы оно потом дольше грузилось.
Вы в статье пишите
потому что в данном случае, использование кастомного тега увеличивает количество шаблонного-кода, а не уменьшает
ни слова про семантику для сео. Ваш пример с aria-level=1 это вот прямо из пальца высосано ради сугубо вашего понимания семантичности и локаничности, я даже готов поспорить, что в сео парсерах и контент анализаторах ваши вундертеги даже с атрибутами проставленными проиграют статье из обычного article, h1, p тегов, времени только жалко на такие эксперименты и вам что-то доказывать. Неужели вы не видите и так излешне большого зоопарка фронтенд решений которые родились на основе фреймворков, вам похоже мало так вы ещё предлагаете забить на стандарты и руководствоваться чисто внутренними ощущениями лаконичности, на которой вы делаете упор и акцент.
я в статье говорю что для заголовка лучше использовать h1
Помимо этого так же стоит отдавать предпочтение тегам main footer article section aside когда они подходят по смыслу вместо div .
и про тег article так же сказал
про SEO говорится что нет разницы между ничего не значащим <div class="bar" и ничего не значащим <bar>
ну и в конце концов - вот в интерфейсе почты например или календаря для авторизованного юзера разве нужно SEO ? - посмотрите я тут примеры кода скинул - https://habr.com/ru/articles/819465/#comment_26899193
Выходит что проще всегда писать как для сео и не изобретать велосипед. Иначе нужно практиковать два подхода одновременно, с учётом сео и скрин ридеров и без учёта их с фантазией над тегами. Я в статье правильное место ваше процитировал, вы пишите про h1 но причина для вас в бойлерплейте меньшем, а не в семантике и это принципиально важный момент. Вам там в комментариях уже подсказали, что используйте emmet и будет вам счастье. Я когда вижу див с классом лоадер, не проговариваю в уме несколько его смыслов. Блок со стилем лоадер - условно. Когда я вижу кастомный тег, я в первую очередь думаю про наличие веб-компонента и мог бы потратит время на поиски того, чего нет. С хожу найти сакральный смысл в том, что автор просто так считает писать лаконично - я не настолько экстрасенс. Попробуйте изучить реакт, вьюжс или ангуляр, там как раз можно писать в таком духе разметку как вам нравится, а на выходе получать семантичную с точки зрения вёрстку для сео и скринридеров.
Попробуйте изучить реакт, вьюжс или ангуляр,
Вы даёте мне странные советы. Посмотрите мой профиль что ли.
Я написал на angular ни одно приложение. Знаю реакт лучше многих, это пожалуй основной фреймворк на котором я пишу на работе, ну и было несколько проектов на vue. А ещё в прошлом riotjs , meteor, backbone.
Я прекрасно знаю как в каком фронтенд фреймворке делается вёрстка и все нюансы со стилизацией и организацией как компонент так и вообще ui китов.
Когда я вижу кастомный тег, я в первую очередь думаю про наличие веб-компонента
Всё бывает в первый раз, это как раз таки из-за того что такой подход в новинку, а это из-за того что его мало кто использует.
Но если это веб-компонент то это как-то по другому видно, потому что есть такой файл например и он где-то импортируется выше, ну у меня vscode по клику перекидывает в него.
В принципе можно договориться что если тег из нескольких частей через чёрточки - то веб-компонент, а если всё слитно - то просто тег.
То что вы сейчас испытываете называется когнитивное сопротивление, это нормально когда встречаешься с чем-то новым.
А вот то что возможность языка которая в нем уже кучу лет для опытных разработчиков является чем-то новым не нормально
В принципе можно договориться что если тег из нескольких частей через чёрточки - то веб-компонент, а если всё слитно - то просто тег.
На наших проектах так и есть, часть веб компонентов смешана с vue.js в моем профиле есть публикация на тему веб-компонента одного из, а в блоге можно найти еще пяток статей на тему веб-компонентов. У нас есть wc-wysiwyg, svg-icon, web-link и еще парочка внутренних. Так что для меня ничего нового и
Так что в целом ваш подъеб
А вот то что возможность языка которая в нем уже кучу лет для опытных разработчиков является чем-то новым не нормально
Не засчитан. Мы пользуемся кастомными элементами в HTML активно уже несколько лет точно. А то что вы как якобы опытный разработчик не ушли дальше переименования HTML тегов - выглядит очень печально и уныло, низкий уровень развития и приводит к таким вот статьям. В современных проектах в большинстве своем теги с дефисом и являются кастомными веб-компонентами. Погуглите web-component naming convention и почитатйе.
Т.к. ваши комментарии перешли в плоскость попыток поплеваться слюной и перейти на личности, не вижу уже смысла далее вам отвечать и разжевывать очевидные вещи для опытных разработчиков.
И не называйте HTML лаконичным кодом - это просто язык разметки, который вам еще предстоит осилить, если хотите вменяемо конкурировать на рынке с другими опытными фронтенд специалистами
Надеюсь мне не доведётся работать на проектах, где надо учить собственные хтмл теги, которые ничего кроме кастомного имени под собой не имеют
Ну свои собственные переменные и имена классов в новом проекте вы же как-то учите? Имя тега в данном случае призвано заменить название одного из его css классов не более того
Никак не учу, я работаю в диком ентерпрайзе. У нас на всех проектах есть дизайн системы и сторибуки для компонентов. Пишу тонны бойлерплейта для всяких хитро выдуманных админок и внутренних срм систем
Ну если никак не учите то будете так же читать доки по дизайн системе. Что там внутри кастомное не кастомное имя на уровень абстракции выше не попадет.
Но опять же, вы апеллируете к своему личному опыту и своей персональной насмотренности, к субъективному восприятию чужого кода которое коротко можно описать одной фразой - "так сложилось что я привык по другому и лень переучиваться"
А с инженерной точки зрения есть что сказать по поводу качества работы такого кода? Если например представить что вам не нужно его писать, а вы только пользователь, на комп которого загружается такой вот код. Ведь в конце концов программирование создано не для вашего удобства чтобы вам на работе было комфортно сидеть, а для того чтобы решать задачи пользователей программных продуктов и если вы как разработчик давно не замечаете трёх сущностей в коде, то может как пользователь видите что на некоторых сайтах устройство нет-нет да залагает от парсинга всего этого энтерпрайза?
"так сложилось что я привык по другому и лень переучиваться"
Так сложились стандарты разработки и я придерживаюсь, вы не придумали ничего нового, никакого ноу-хау или технологического прорыва, вы решили в один момент, что писать велосипеды с выдуманными тегами это круто. Нет не круто, вам куча народа об этом сказала и рейтинг вашей статьи тоже намекет. Я тоже прошел путь от HTML4, jquery, backbone, knockout, angular1, polymer до vue 3 + web-components. React'a по жизни избегал и не писал на нем, хотя и приходилось некоторые проекты переводить с него на vue. Не вам мне рассказывать про "переучиваться". В вебе без этого никак.
А с инженерной точки зрения есть что сказать по поводу качества работы такого кода?
Вам я уже выше написал, что вы забили на семантику, на стандарты, на SEO, на скринридеры. Восхищяетесь своей идеей писать код "лаконично" а по сути велосипедить ведь вам тяжело понять смысл div.loader и вы пытаетесь сделать еще один XML
Начинаю считать этот тред бесполезным уже холиваром
еще один XML
О, вы тоже заметили?
вам куча народа об этом сказала и рейтинг вашей статьи тоже намекет.
нет уж простите - говорите об этом только вы и еще пара человек в комментариях и постоянно пытаетесь выставить лично меня не компетентным, что-то про мою конкуренцию с другими фронтенд разработчиками. Не нужно пожалуйста критиковать описанный в статье подход через понижения авторитета его автора в глазах аудитории ok?
И рейтинг статьи положительный и много кто добавил ее в закладки - сравните это с другими публикациями за последние сутки - так что ни на что он не намекает.
Что касается "скринридеров" и иже с ними - ну допустим есть какие-то программы которые это не обработают, но html например для electron приложения так можно писать? или для веб версии crm / мессенджера? Если посмотреть на современные SPA , дашборд в админке или интерфейс конструктора сайтов , там каким боком вообще нужны стандарты seo и скринридеры?
Опять же если эта практика станет больше распространена то и seo / поисковики подстроятся, выработают новые эрвистики на основе имен тегов.
И то что google вводил новый формат разметки для amp страниц, яндекс так же для своих быстрых страниц, а telegram устраивал конкурс с разметкой популярных сайтов для корректной работы своего instantview говорит о том что текущая верстка сайтов не особо им помогает разбирать контент.
Вы можете мне ответить на этот вопрос что-то кроме "так нельзя" / "иди учи реакт" / "верстать" и тому подобное?
Телеграм отлично парсит на основе open graph все уже придумали за вас. Боюсь представить, если каждый в место open graph будет просить свои и имена тегов вставлять, которые считают лаконичными.А вот чтобы миллионы разработчиков по всему миру согласовали непонятное количество имен тегов - утопия. Хотя в целом они и согласовали - div всем хватает. Вас никто не унижает и фраз про преподавание и учение тоже не было, вы слишком интимно воспринимаете данную дискуссию. Просто сама дискуссия уже потеряла технический смысл и напоминает обмен упреками, что мне не интересно. Цели как-то унизить вас или оскорбить у меня нету. Извините, если чем-то вас задел. Ваш бы энтузиазм да в правильное русло направить, а пока вы напоминаете мне меня же 10 лет назад, когда я радовался в первом ангуляре что теперь могу писать теги какие хочу)
"а пока вы напоминаете мне меня же 10 лет назад" - ну вот это что?
я старше вас, мне 36 лет, вам полагаю около 32, и разработкой занимаюсь дольше. Комплимент что я не растерял энтузиазм за годы в айти и продолжаю смотреть на привычные вещи свежим взглядом?
А вот чтобы миллионы разработчиков по всему миру согласовали непонятное количество имен тегов - утопия. я же не говорю о том чтобы в разных проектах использовали одинаковые согласованные имена "новые" имена тегов. - это будут примерно английские слова - которые поисковики научаться анализировать.
вообще не понимаю чего вы так прицепились когда сами пишете статьи про веб-компоненты? c точки зрения семантики я делаю почти то же самое только говорю что еще не всегда обязательно этот тег регестирировать.
ну вот вы сами же и переходите на личности и то о чем просите не писать - пишите
мне 36 лет, вам полагаю около 32, и разработкой занимаюсь дольше.
Это ведь и есть личные оценочные суждения, мы с вами одинаково застали развитие интернета. Свой первый код на бейсике я писал еще в начальной школе, а первый сайт за деньги сделал где-то в 2006 итого 18 лет веб-разработки уже позади т.к. я этим занимаюсь до сих пор. Только эта информация далеко за темой треда текущего и вы сами к этому тред подводите. Фу таким быть. Я просто поделился с вами, что когда-то тоже радовался идее писать собственные теги на свое усмотрение.
нет это вы используете назидательный тон по отношению ко мне, почти в каждом своем сообщении, вот цитаты:
- "Ваш бы энтузиазм да в правильное русло направить"
- "Попробуйте изучить реакт, вьюжс или ангуляр, там как раз"
- "если хотите вменяемо конкурировать на рынке с другими опытными фронтенд специалистами"
из-за этого у читателя в голове формируется образ как взрослый опытный дядя говорит какому-то новичку что нельзя писать так как ему вздумается. Тем самым в глазах читателя вы понижаете авторитет автора - просто говоря с ним свысока, за счет чего у невнимательного читателя срабатывает когнитивное искажение - что раз источник "плохой" - то и информация которую он сообщает ложна.
понимаете? А это я собеседую этих фронтенд специалистов и вот кто про такие теги даже не слышал - у меня собес не пройдет )
Предлагаю вернуться к тегам. Где это не работает?
Вы же видите что код однозначно читабельнее , что тег это просто <></> а его имя можно придумывать так же как имя переменной. И развитие стандарта html привело к тому что они сделали возможным создавать свои теги на случай если не достаточно имеющихся , но разработчики продолжили все оборачивать в div и span, даже нишевые решения, аппки для webview приложения заточенные только под одну платформу smartTV например.
Кастомные элементы придумали не просто ради того, чтобы вы делали кучу разношерстных тегов которые все можно заменить дивом с классом. Кастомные элементы это про возможности инкапсуляции логики, шаблона, стилей в одном теге + такие фишки как shadow DOM, хуки жизненного цикла тега и т.п. Но вы просто игнорируете все замечания. Кастомные элементы как хороший пример это audio, video, canvas, details.
Также идет борьба с лишними тегами т.к. они устаревают, но благодаря таким как вы может внестись путаница с тегами типа - marquee, font, frame, param, plaintext
В вашем мире просто не будет существовать deprecated тегов
Предлагаю вернуться к тегам. Где это не работает?
Ой все, спорить с нарциссом с повышенным чувством ЧСВ невозможно. Вы не воспринимаете критику и засолились на уровне ананизма на себя любимого и своих лаконичных идей. Вы бы у меня собес тоже не прошли, хоть и старше и кодите дольше, толку только ноль. То что вы долго сидите на одном месте не делает вам чести и вы не становитесь опытнее со временем. Понтоваться своим возрастом и стажем - очень тупо. А в моем случае опускаться еще до вашего уровня глупо.
вам нужно спорить не со мной нарциссом, а с текстом статьи, кто бы не был ее автором, приводя и подкрепляя весомые аргументы, не переходя на личности, вы же так или иначе все сводите к обсуждению автора материала, его энтузиазму опыту и психологическим особенностям
Вам уже написал много технических аргументов, но вы в обиженку превратились просто и начали рассуждать уже про тон сообщений которым вы читаете мои комменты, про свой возраст, про ваше видение собеседований и тп.
Еще разок напихаю вам по пунктам
Вы отходите от стандарта т.к. все теги регламентированы по своей семантике и существуют соглашения о именовании тегов
Вы упираетесь в сугубо личное понятие лаконичности и читаемости в место того, чтобы соответствовать стандартам. Люди знающие стандарты HTML будут все равно с трудом читать вашу разметку и без ваших пояснений никак не обойтись
У вас будут проблемы с SEO
Ваша верстка не семантичная
У вас будут проблемы со скринридером
Вы не экономите количество символов т.к. для каждого элемента вновь приходится писать вам display:block
В итоге больше бойлерплейта пишите т.к. люди использующие классы в CSS переиспользуют куски стилей. Взгляните как пример на tailwind
Ваша разметка хуже сжимается алгоритмами сжатия
Вы можете напороться на то, что выйдет новый HTML6 тег, а он у вас уже в проекте под другим соусом и все сломается
Ваш подход допускает использование deprecated тегов которые выходят из обихода
Вы игнорируете доступные форматы микроразметки типа open graph мечтая о том, что когда-нибудь примут ваши теги (к счастью никогда не примут)
Игнорируете факт, что современные веб-фреймворки уже позволяют писать в таком стиле, о каком вы пишите, компилируя все в итоге в православный div элемент и позволяя избежать проблем из всех пунктов выше.
Поддержка устройств у вас получится на выходе тоже ограниченная.
Текстовый контент в RSS лентах будет некорректно оформлен при применении кастомной разметки
Вы отходите от стандарта т.к. все теги регламентированы по своей семантике и существуют соглашения о именовании тегов
Если использовать имена тегов без черточек - да. Это уход от стандарта, но - можно именовать теги как my-tag в таком случае стандарт соблюден
+ из-за нарушения стандарта в случае с именованием тегов - не наступает никаких последствий - то есть да правило нарушено - но ничего плохого из-за этого не происходит.
Вы упираетесь в сугубо личное понятие лаконичности и читаемости в место того, чтобы соответствовать стандартам. Люди знающие стандарты HTML будут все равно с трудом читать вашу разметку и без ваших пояснений никак не обойтись
Нормально люди будут читать такие теги, будут видеть говорящее имя. Да любое восприятие личное, нет же какого-то общественного восприятия? Это какая-то философия а не аргумент.
У вас будут проблемы с SEO
Не будет проблем с SEO. Еще раз - мы продолжаем использовать теги h1-h6, strong, article, form и так далее - а отказываемся только от div - который не несет в сеюе никакой семантики.
Ваша верстка не семантичная
Семантика - https://ru.wikipedia.org/wiki/Семантика - это буквально смысл.
И я как раз и призываю вкладывать смысл в названия тегов, английскими словами. Опять же размечать списки с помощью <li> параграфы <p> а меню выносить в <nav>
То есть моя верстка - семантичная , а div class - не семантично
У вас будут проблемы со скринридером
У всех будут проблемы со скринридером кто не оптимизировал свой сайт под него, особенно если это electron приложение с доской задач а-ля trello
Вы не экономите количество символов т.к. для каждого элемента вновь приходится писать вам display:block
Да нет цели эконоить символы я прошу вместо </div> писать </person> это конечно больше символов - чтобы явно видеть какие теги закрываются и да оучше писать в css свойство display чтобы по css коду явно было видно как этот элемент отображается. Я за наглядность, а не за экономию символов.
В итоге больше бойлерплейта пишите т.к. люди использующие классы в CSS переиспользуют куски стилей. Взгляните как пример на tailwind
Бойлерплейта в итоге не больше. Я же не говорю отказываться от css классов, так же их можно переиспользовать. Но если оформление какого-то блока индивидуально - то его можно записать в сили тега а не в класс который иначе бы использовался в проекте только один раз
Ваша разметка хуже сжимается алгоритмами сжатия
В ответе на другой комментарий я разобрал этот вопрос - не не хуже а так же или лучше.
Да и блин, вы серьезно будете парится из-за пары килобайт разницы в сжатии на всю html страницу?
Результаты сжатия gzip
Вот папка с примерами файлов и сжатыми их версиями
Вы можете напороться на то, что выйдет новый HTML6 тег, а он у вас уже в проекте под другим соусом и все сломается
Если использовать теги с черточками то нет.
Шанс что повится тег с таким же вот прям именем очень низкий.
То есть чисто теоретически - могу, а могу и не напороться. Мы недавно все напоролись на то что докер образы перестали пулиться - фигня случается, адаптируемся.
Что случится если появится новый тег? Браузер для него свои стили допишет? Обычно я использую некое подобие reset.css , но может, действительно может где-то чутка поеет верстка - поправить дело 5 минут. В вебе постоянно что-то обновляется и меняется, потому мы и занимаемся поддержкой.
Но все эе вы понимаете насколько низкий шанс такого случая?
Ваш подход допускает использование deprecated тегов которые выходят из обихода
Допускает - но это на совести разработчика - не надо именовать свои теги названиями существующих пусть и в прошлом тегов, хоть на работе сайта это никак и не отразится.
Вы игнорируете доступные форматы микроразметки типа open graph мечтая о том, что когда-нибудь примут ваши теги (к счастью никогда не примут)
Я их не игнорирую - они просто за рамками этой статьи и никак не связаны с именованием тегов. Opengraph остается opengraph'ом и так же пишется, микроразметка - так же добавляется.
Я не мечтаю и это не мои теги ... даже не знаю что на это сказать сказать... я же не новый стандарт вам втюхиваю - это ваши теги - ваши названия тегов которые вы придумаете сами так же как придумываете названия переменным.
Игнорируете факт, что современные веб-фреймворки уже позволяют писать в таком стиле, о каком вы пишите, компилируя все в итоге в православный div элемент и позволяя избежать проблем из всех пунктов выше.
Вот именно что фреймворки - синтаксический сахар и в нем все равно внутри "православный" div. Блин ощущение что я с верующим спорю о боге ))) нет проблем в пунктах выше - нечего избегать.
Поддержка устройств у вас получится на выходе тоже ограниченная.
Тому нет доказательств. Я проверял, на телевизорах, смарт-часах, разумеется телефонах, старых iphone 4,5 , дополнительно на сайте browserstack смотрел с разных устройств.
Могу сказать что это не работает в IE6. ну и в терминальных браузерах типа links , вот эти теги всегда отображаются как строчные элементы.
Текстовый контент в RSS лентах будет некорректно оформлен при применении кастомной разметки
Я не понял что вы имеете ввиду... RSS это отдельный XML формат , для генерации rss пишут отдельные скрипты которые берут контент из БД и отдают xml
Ну не нужно размечать текст ВЕЗДЕ своими тегами. Но опять же если текстовый контент в RSS ленте разметить через дивы с классами - тоже ерунда получится.
Ну и в целом я предлагаю повысить читаемость кода именно веб-приложений, онлайн игр, приложений кинотеатра для смарт-тв(они тоже на html написаны), калькуляторов всяких, интерактивных карт, почтовых клиентов, crm, админок, ПРИЛОЖЕНИЙ - которые чтобы увидеть надо пароль ввести - которые не индексируются, в которых нет контента для запуска screen reader, приложений которые пишется под свою webview / electron / cordova , таких как slack , как веб-версия телеграм или whatsapp , а не чисто контентных/новостных сайтов где самое главное не просесть в поисковике и добится максимально быстрой индексации и ранжирования.
В итоге имеем, что так писать можно, но все может развалится, список депрекейтед тегов надо помнить в вашем случае + нездоровая боязнь писать див элементы, восприятие кастом элементов только с точки зрения что можно писать слова которые нравятся, бойлерплейт в цсс, а также отсутствие навыков с веб фрейиворками в которых в таком стиле уже давно пишут и не тратят столько времени в пустую на такие глупые идеи. Веб практикует компонентный подход нравится вам или нет. Что нативные веб компоненты, что реакт/вью/ангуляр/свелти, вас осталось лишь подтянуться до современного уровня. Удачи вам.
Послушайте мистер php разраб, вы не оборзели? Я же просил вас вот в этом комментарии перестать говорить свысока типа я какой-то стажер, а вы умудренный опытом сеньер-помидор.
Вы зачем говорите про "отсутствие навыков с веб фреймворками " и что мне нужно подтягиваться до какого-то уровня?
Вы верстку своего сайта https://manytomany.ru/ до современного уровня подтяните.
Вот мое резюме - https://career.habr.com/a-l-e-x-s-t-e-p я работал в том числе в известных "проверенных" так сказать, компаниях в том числе делал фронт приложений которыми пользуются и сейчас сотни людей, когда-то работал лидом и руководил такими вот сайто-делами. Писал на angular, vue, react , но сейчас больше react . Но нет, наверно во всех компаниях подряд на всех собеседованиях все эти годы люди ошибались я то оказывается и фреймворки их знать не знаю и верстать не умею )
Зачем вы упорно тыкаете в мою вымышленную вами некомпетентность и незнание современного стека разработки под веб?
Сайт manytomany заброшен и доживает последний год оплаченного домена, им уже несколько лет никто не занимается и площадка мертва, хз зачем вы копались в этом)) видимо припекло жопу, но ничего бывает. Последние 7 лет я занимаю руководящие должности в командах веб/фронтенд разработки и имею слабое отношение к пхп) проекты которые мы поддерживаем и пишем используют десятки тысяч людей ежедневно, сотни людей это посещаемость моего полузабытого блога) Вам действительно стоит подучить фреймворки и вы мигом перестанете восхищаться возможностью писать всякую ересь в хтмл. Пока вы похожи на реакт макаку из многочисленных шуток про реакт)) к счастью у меня на jsx аллергия и я так не велосипедил, как это делают поклонники Фейсбук технологий) к вам это все придет с опытом, не расстраивайтесь. Я даже сохранил вам плюсовой рейтинг статьи, а так был бы совсем нолик у вас судя по рейтингу +1 так что вы серчаете зря, умейте принимать критику спокойнее, всё-таки возраст ближе к 40, невралгия дело опасное
тем не менее не вам мне говорить учить фреймворки которые я знаю с первых лет их появления. Вы как по комментариям вообще определяете уровень знания феймворков? Я вот перешел в ваш профиль чтобы понять с кем это я таким важным говорю вообще, потому что учитывая уровень пафоcа подумал может в соавторстве с вами Чистый код писали или вы там сын мэра.
И при чем здесь принятие критики - на критику по пунктам я ответил и местами согласен - вы нападаете на мою компетентность почти в каждом комментарии. Вы с первого своего сообщения переврали текст статьи и начали писать что мне нужно изучить фреймворки. Подгорело у вас потому что сами пишете про веб-компоненты - а тут что-то похожее но наоборот и не про веб-компоненты.
"реакт макака" ... - у меня испанский стыд...
то я его не знал и надо было подучить - теперь поклонник фейсбук технологий
Кем вы там руководите последние 7 лет? Ребят - не работайте с этим зазнавшимся пиздюком.
Да не знаете вы его. Или пруфы в студию. Ваше резюме это лишь плод фантазий, я таких на собесах много видел, 40 лет и мозгов нету, зато ЧСВ и понты своим возрастом и стажем. Ваш вклад в опенсус разработку ровно 0, ни одной библиотеки набравшей хотябы сотню инсталлов в нпм и пяток звёздочек на Гите. Кичитесь знаниями кода, но хоть одну статью вы написали про веб фреймворки? Нет. Я же их написал с полсотни. Вёрстку можете а блоге глянуть, там и показатели lighthouse хорошие, попробуйте поискать в своих закромах что-то получше. Зазнавшийся олдфаг с заявкой на изменения стандартов хтмл как раз тут именно вы и такой уровень графоманства уже не лечится.
Вы просто хамло, софт-скилс уровня какого-то быдла из подольска без высшего образования и воспитания. Лезете тут в треды и самоутверждаетесь путем наезда вообще не по теме, уверен и на галере своей так же отрываетесь на коллегах. Показатели лайтхаус у тебя? Звездочки? Что еще монеток в hamster combat больше? Все регалии собрал?
Замете хамством я отвечал исключительно на Ваше хамство)
уровень быдла из Подольска
это как раз еще одна заметка про ваше ЧСВ, что вы считаете себя прям лучше и умнее видимо аж целого большого города в подмосковье) лишний раз убедился, что вы конченный графоман у которого кончились аргументы и осталось лишь просто плеваться и переходить на личности т.к. технических аргументов просто нету, а ответить необходимо т.к. в жопе зудит и обида горит, что какой-то пиздюк 30летний дает советы, а не хвалит дитяточку. В гневе человек показывает истинное лицо и я увидел ваше. Это первый и единственный тред, где я так долго пытался кого-то вразумить и пожертвовал кармой, чтобы немного поучить графомана)
Я просил вас перестать разговаривать в назидательном тоне, так будто вы имеете какое-то представление о моих знаниях, а наезжать вот так не по делу как вы видите, я, да и на самом деле кто угодно можем не хуже. и так же можем обвинить вас во лжи и фальсификации - хоть что блог не ваш сказать и все там списано, да что угодно так же как вы насочинять. Или вы специально меня до гнева доводили чтобы увидеть "истинное лицо"? Ну люди зляться если их злить я еще очень мягко вам отвечаю.
Все технические аргументы и ответы на критику в этом комментарии - https://habr.com/ru/articles/819465/#comment_26903223
там вы путаетесь в аргументах своих и то частично признаете, то отрицаете, то пишите нет нарушений если писать через дефис, то в других тредах этой статьи показываете примеры написания тегов без использования дефиса. Крч не убедительные у вас аргументы, уровня `я обосрался, но все еще могу ходить` а за уровень ваших знаний легко очень судить т.к. кроме резюме то у вас ничего и не накопилось за такое большое время разработки, что в целом и не удивительно
Ну а что у меня должно было прям накопиться? Я как многие программисты работаю на работе - код в репозиториях компании, чаще всего это закрытые коммерческие решения.
Ну есть свой пет-проект https://vkontakte.store какие-то деньги приносит
github не пустой пару либ выкладывал, чаще концепты. Прям специально для opensource я ничего не делаю и не считаю что должен. Вот впервые долгое время решил мнение свое подбронее написать в ответ на понравившуюся статью - вон сколько хейта словил )
Я просто не тщеславный чтобы в блоги писать звездочки собирать и из-за кармы с рейтингом париться.
Если я вам сейчас ссылки на проекты покидаю - ну тоже скажете что это мои фантазии) Да и большинство проектов мы делаем командой - так что будет нечестно просто сказать - вот я сделал - а расписывать что именно я там делал это ну прям долго.
В интернете мы в основном наблюдаем "крикливое меньшинство" а есть еще "молчаливое большинство" которое молча читает делает выводы и уходит не оставляя следов и часто среди них есть люди которые лучше разбираются в вопросе - но не считают нужным что-то комментировать / вносить свой вклад или выкладывать код.
И еще раз - это не я придумал и навязываю тут вам "новый стандарт" - весь этот пост вообще является ответом / дополнением к другой статье где на автора тоже что-то некоторые накинулись не вникнув в суть.
побежали с другом карму восстанавливать? ))) коллеционер звездочек блин
статья в закладках у 15 человек это тоже вы благородно постарались ? Позаботьтесь лучше о своем рейтинге и карме если считаете это чем-то важным.
Рейтинг статьи скачет - тема спорная , если бы не было согласных плюсующих - ушла бы в минус еще вчера.
список депрекейтед тегов надо помнить в вашем случае + нездоровая боязнь писать див элементы
Наблюдаю дискуссию двух экспертов. Немножко инжектну инфы в диалог, если не против.
Deprecated-элементы обязательно имеют одно слово в названии. Если черточка есть - то это кастом теги и они валидны.
Юзать deprecated-элементы плохо, это факт. А валидные кастомные - это норм по стандарту HTML5.
бойлерплейт в цсс
Для кастомных элементов желательно только указать свойство display. И все.
отсутствие навыков с веб фрейиворками в которых в таком стиле уже давно пишут и не тратят столько времени в пустую на такие глупые идеи
Идея называть части разметки кастомным именем на самом деле неглупая. Не обижайте w3c. Название элементов своими именами - это и есть семантика в том смысле как она задумывалась. Можно разве что обсуждать целесообразность использования. Тут мнений будет много.
Веб практикует компонентный подход
Да, согласен. Без компонентов уже никуда. Они состоят из
HTML Templates
Custom Elements
Shadow DOM
ES modules
Что будете юзать для их создания подскажет личный опыт или руководство на работе.
Однако, автор говорит только о Custom Elements. И вообще больше о подходе HTML first.
Семантика - https://ru.wikipedia.org/wiki/Семантика - это буквально смысл.
И я как раз и призываю вкладывать смысл в названия тегов, английскими словами. Опять же размечать списки с помощью <li> параграфы <p> а меню выносить в <nav>То есть моя верстка - семантичная , а div class - не семантично
Смысл для кого? Наверное, имеется ввиду смысл для машинного чтения - поисковых пауков, скринридеров и т.п. Для них ваши кастомные теги без обозначения ролей и ариа-атрибутов не несут совершенно никакой семантической нагрузки. Собственно, как и дивы. Смысл для программиста, читающего код, передается в классах, атрибутах, или как вы предлагаете в кастомных именах тегов. Но это не имеет отношения к семантике верстки.
для каждого элемента вновь приходится писать вам display:block
display: flex/grid
Еще можно дополнить то, что "неизвестные через черточку" теги не только валидны в HTML 5, а также отображаются со свойством css display: contents.
И это дает прикольный профит - такие теги можно использовать в качестве тегов-группировщиков, которые не влияют на отображение дочерних элементов. Удобно управлять вставленными в DOM document fragments.
ну и конечно это все упрощает и написание css селекторов
ради интереса запустите поиск по своему проекту, сколько раз у вас в коде встречается совершенно ничего не означающее слово div не наделенное никаким смыслом
По всем измеримым метрикам этот подход эффективнее, вы не сможете по научному / математически доказать обратное, а лишь апеллировать к субъективному восприятию , стилю / моде / удобству "наши деды так писали и мы будем" и т.п.
Всё так, конечно же. И совершенно никто не спорит, что данная фича чертовски эффективна и на порядки более удобна для работы.
Однако же — обратная совместимость, бессердеШная ты с...ка ©.
Это наиболее частая причина отказа от слишком уж "новомодных" фич. И никакие "деды" тут совершенно ни при чём — банально учитывание аудитории сайта. То есть, предусмотрительность разработчиков.
Если у вас аудитория условно достаточно молодая (которая постоянно обновляет всё на десктопах и смартфонах, технически довольно продвинутая) — можно внедрять. Если же у вас аудитория включает и условных дедушек-бабушек (для которых любое обновление что-то сродни шаманским пляскам) — надо писать как можно проще, "чтоб работало на любых дроволётах".
Иначе никакая ТП никак не объяснит условным Марье Ивановне или Ивану Марьевичу, почему у них вдруг не работает любимый сайт.
Или, кратко резюмируя: далеко не всегда то, что удобнее для разработчика, реально удобнее для клиента и его аудитории.
internet explorer 7 их поддерживает какая еще обратная совместимость ?
я писал так проекты в 2009м если не нужна была поддержка ie6
Поддержка может быть и весьма ограниченной.
то что предлагаю я(свои имена тегам) работает начиная с ie7
то что в статистике can i use какой-то браузер не полностью поддерживает Custom Elements - это именно про js api веб компонент , конструкции видаclass FlagIcon extends HTMLElement { и тому подобное
сами имена тегов и css и js селекторы по ним работают
В целом же, лично у меня правило такое: изначально делать всё на "ванильном" HTML (и CSS, и JS) — к новым методам прибегать лишь тогда, когда заставит крайняя нужда (или когда никакое иное решение просто невозможно).
Так точно будет работать всегда и везде.
Я лично не пишу много "бойлерплейт-кода".
Я ввожу в IDE ".loader" и оно само по табу разворачивается в див с нужным классом.
Когда я проскроллил страницу с кодом вниз, и начала тега не видно, а только закрывающие, то моя IDE (умничка) зафиксировала вверху редактора всё дерево открывающих тегов.
На мой взгляд, вы не теми методами решаете озвученные проблемы.
То есть те методы - это написать код который будет помогать генерировать бойлерплейт код? Больше кода богу кода?
Я ввожу в IDE "<loader" и оно само по табу мне пишет <loader></loader>
Да, не в блокноте пишем, AI половину генерирует, но все таки каждый символ чего-то да стоит и каждая сущность чего-то да значит. И даже перевод взгляда в "шапку" ide где прописан путь и перевод курсора на закрывающий тег(чтобы наверху увидеть как он там открыт) - какое-то время да занимает, в сравнении с тем - когда можно все это увидеть просто смотря на конструкцию закрытия тега. Вы поймите, что вы каждый раз даете своей сущности название - div. Регулярно, совершенно разные блоки вы называете одним и тем же именем или позволяете это сделать IDE за вас.
Ну это то же самое что давать многим переменным одинаковые имена по типу myvar1 myvar2.
Что станет хуже если ваша ide когда вы пишите loader будет генерировать '<loader></loader>' ? Ну перенастройте ide и пишите на одну точку меньше и перводите взгляд и курсор реже.
Я ввожу в IDE "<loader" и оно само по табу мне пишет <loader></loader>
Ну вот. вы абсолютно то же самое пишете, что и я выше. Даже количество вводимых символов совпадает.=)
С переменными сравнение немного некорректное. вы видите именование в именах тегов. Я вижу имена в названиях классов. И в названиях классов нет никаких myvar1. А в сухом итоге мы с вами вводим семь символов, нажимаем [tab] и получаем то что хотели.
нет на выходе мы получаем разное количество символов и смыслов
я на выходе получаю одну смысловую единицу - только тег с его именем
вы на выходе получаете три смысловые единицы - тег, атрибут, название
2 из которых всегда одинаковые и мало что значат
зависит конечно от длины названий тегов но скорее всего и мой css будет компактнее и файлы отдаваемые юзеру в итоге будут меньше весить и git diff проще смотреть и анализировать и все остальные плюсы лаконичности вплоть до меньшего потребления оперативной памяти
в моем случае браузер видет только тег - в вашем случае браузер видит тег атрибут и значение атрибута, так или иначе вся эта информация обрабатывается человеком / компьютером.
Еще раз взгляните свежим не замыленым / привыкшем взглядом на html. Да - можно писать везде div class=" - можно - но для чего? какие цели достигаются написанием этого бойлерплейта? что вы в конце концов хотите сказать миру своим `div class="`? то что у вас в ide есть автокоплит? :)))
Исторически так сложилось не более того, книжки старые так были написаны, потом уже те кто читал эти книжки - учил других не особо вспоминая о новых возможностях, далее те кто учит html просто не видят примеров со своими именами тегов и даже не догадываются что так можно, информации по фронтенду так много что никто не копается в деталях и так не успевают за всем уследить - смотрят как все делают и повторяют за ними. А тем временем по меркам IT это просто огромный срок, уже лет 15 наверно как существует возможность вкладывать в сами имена тегов смысл а не только в их атрибуты.
Просто уже давно нет причин писать <div class
еще раз - вы вводите в IDE - только имя и я ввожу в IDE только имя
ваша IDE генерирует div class - моя нет
при этом результат работы и того и другого кода идентичен
вопрос - вам для чего нужен этот div class, чтобы что? или кому он вообще нужен и для чего?
то есть ваша ide сгенерировала то что вам то и не нужно и никому не нужно - какой-то текст который вы уже давно автоматически взглядом пропускаете и смотрите только на имя класса - а зачем это делать если можно этого не делать?
Мне кажется, вы изобрели XML. Чем ваш подход отличается от XML?
я ничего не изобретал , этим занимается w3c
я же просто пишу на html и хочу читать чужой код наполненный смыслом - поэтому обращаюсь к разработчикам с просьбой - давайте осмысленные имена тегам
мой подход к написанию валидного html отличается только тем, что я даю оригинальные имена тому, что большинство фронтенд-разработчиков именует как `div`
xml тут не при чем, просто вы знаете что в xml через DTD можно свои имена тегам придумавать, но не знаете что точно так же можно делать и в html и без DTD - поэтому сравниваете с xml , он тут не при чем - я использую нативные задокументированные возможности языка html
Вы предлагаете использовать теги H1, H2, P, EMPH, STRONG, HR, ABBR, IMG, A и тому подобные, то есть теги с осмысленными названиями? Так оно всегда и было.
я предлагаю вместо вот такого кода
писать вот такой
и то и другое - это html код календарей - там нет особо тегов для разметки текста это datepicker'ы, только в одном случае все на одних только div и span а в другом с именованными тегами
тегов с осмысленными названиями толком не было и нет до сих пор на сайтах
Вторая картинка вовсе не HTML, а очень даже XML.
Однако в первом случае есть одна тонкость, которую вы упустили из виду. Второй случай простой, удобный, очевидный. То есть он вообще никак не защищён от копирования, не обфусцирован. То есть копирасты будут агрессивно против него.
Вторая картинка это валидный именно html код который исполняют браузеры.
Я не хочу с вами спорить о том что есть xml а что html вот тут неплохо описали разницу - https://habr.com/ru/articles/810945/ и тут https://habr.com/ru/articles/252283/
На счет копирастов - нуу интереная мысль с одной стороны... с другой - это только фронтенд - обычно есть же еще остальная немаловажная часть проекта - бэк и обсуфицированный js код . Думаю эта результирующая верстка все равно не являющаяся исходным кодом а лишь сгенерированная им, мало чего даст желающим скопировать проект.
и то и другое - это html код календарей
тут вы немного лукавите. во второй код следует вернуть семантику, то есть атрибуты role и aria-*. Они предназначены для машинного чтения, а не для программиста. И ваши кастомные теги их не заменяют.
Чёрточки забыли поставить в ваших кастомных тегах. А если все будет с черточками, то сойдёт. HTML 5 не запрещает такое.
Вспомнил почему-то XML острова )
Речь пойдет именно о тегах с кастомными именами, не о веб-компонентах.
Теги с валидными (дефис) кастомными именами — это Custom Elements, а они являются частью веб-компонентов. Иными словами, теги с кастомными именами являются веб-компонентами. Даже если не написано ни строчки JS. С точки зрения парсера это все равно кастомный элемент.
Но посмотрите как легко и нативно мы можем избавится от большей части шаблонного кода
Мне кажется, даже новички используют emmet и/или шаблонизаторы для кодогенерации. Часть разметки копируют из других проектов. В IDE модно создавать сниппеты, также есть gist. Ну и сейчас всякие Copilot и ChatGPT могут генерировать бойлерпоейт по запросу. Этим я хочу сказать, а проблема ли в бойлерплейте, при наличии такого количества решений?
что это у нас закрывается? Да, вверху страницы у этих тегов есть классы и id и может какие-то другие опознавательные признаки, но что касается закрытия, в каком-то коде можно встретить комментарии с классом закрывающегося тега где-то нет, а можно писать так
Это, как будто, тоже не проблема. Форматтеры правит отступы. IDE рисует вертикальные линии, а с настройками/плагинами раскрашивает линии и теги в разные цвета. Сюда же превью открывающего тега при наведении на закрывающий, прилипающий к верху открывающий тег (недавно появилось в VSCode) и возможность свернуть дочерние узлы.
К этому можно добавить хорошую практику не допускать роста разметки компонента. Декомпозировать разметку на части, не создавать God component и т.д.
но я лично не нашел доводов против использования имен без черточек
В спецификации HTML есть довод. Дефис нужен, чтобы избежать коллизии имён с потенциальными новыми тегами. Вот кто-то напишет <search> для формы поиска. А такой тег недавно добавили в стандарт и внедрили в браузеры. Не исключено добавление новых тегов, некоторые уже на подходе.
Другой довод — валидность документа. Элемент с несуществующим в стандарте именем и без дефиса приведёт к ошибкам в валидаторе и других инструментах. В свою очередь это может сломать пайплайны CI, где прогоняется валидация и тесты.
Третий довод — класс элемента. Элемент с дефисом, даже если он не зарегистрирован, всё равно будет экземпляром HTMLElement. Так заложено в парсере. Несуществующий элемент без дефиса будет экземпляром HTMLUnknownElement. Согласно описанию из спеки DOM, это невалидный элемент.
Ну и как отмечено в статье, из такого элемента не сделать Custom Element без переименовали. Что тоже можно отнести к доводам против подхода без дефисов.
Что касается SEO - то поисковикам совершенно без разницы
<div class="bar">(а скорее после компиляции реактом это будет какой-нибудь<div class="sc-dd348ae-0">) или<bar>
Не соглашусь. В мире, где сайты и веб-приложения используют семантически верную разметку и микроформаты — может быть. Но в мире сплошных дивов, обратной совместимости, легаси и ошибок валидности, поисковые движки вынуждены применять эвристики.
Конечно, доказательств этого у меня нет. В SEO в принципе сложно что-то доказать. Но я уверен, что теги, классы, атрибуты и их композиция влияют на SEO. Поисковые машины распознают паттерны, имена классов (когда они осмысленные, а не хеш), элементы, вложенность для вычленения из этого какой-то информации.
Косвенно это подтверждают такие штуки, как Schema, RDFa и прочее. Они основываются на классах и атрибутах для перелачи информации поисковикам. Это отражено как в спецификации, так и в документации поисковиков
Идею статьи я понимаю. Я сам об этом думал. Но я бы использовал имена тегов с дефисом. И применял бы такой подход только для каких-то группирующих контейнеров, не несущих в себе семантики. Ну и стоит держать в голове несколько нюансов. Первый — кастомные элементы по умолчанию display: inline. Второе — помимо классических браузеров есть ещё специальные, которые могут иначе себя вести при использовании кастомных элементов.
Хорошие доводы, спасибо!
Но то что emmet упрощает генерацию бойлерплейта - он же все равно его генерирует и далее этот код существует и отправляется на клиент, а можно вообще жить без это кода. Я надеялся что кто-то такой же дотошливый как и я сможет скинуть ссылку на программу которая текст из div class=text может прочитать, а из тега text или my-text не может. Но с таким я пока не сталкивался, отсюда и вывод что это код, пусть его и AI генерирует, не нужен никому, ни на каком этапе.
Специальным браузерам точно так же, что прост div что кастомный тег, нет разницы и для div нужно прописывать aria чтобы придать ему смысл и для кастомного тега так же
То есть вы тот описанный в статье человек, который боится что где-то, когда-то , "на умном холодильнике" что-то пойдет не так
Если какие-то парсеры всё-таки споткнутся о кастомный тег - значит и веб-компоненты нельзя использовать? Ну давайте тогда будем их использовать хотя бы в приложениях которые не предназначены для парсинга, онлайн играх, этих вот телеграмм ботов со встроенным web-app , закрытых админках и crm?
он же все равно его генерирует и далее этот код существует и отправляется на клиент, а можно вообще жить без это кода.
А почему это стало проблемой? Вы в статье указали, что подход с кастомными элементами априори эффективнее по всем метрикам, а в комментариях указали, что смысла в <div class> вообще нет. Но я могу привести некоторые аргументы за то, что смысл есть
Первый аргумент — компрессия. Алгоритмы сжатия (gzip, brotli) работают на словарях, а они формируются из повторяющихся токенов. Большое количество повторяющихся div, class и подчеркиваний (в подходе с БЭМ) приводит к более эффективному словарю и сжатию соответственно. В итоге получается забавная ситуация. Ваш лаконичный код, где вы боролись за лишние символы, будет сжат хуже и весить больше, чем такой же код с div и class.
Второй аргумент — User Agent Stylesheet. <div> по умолчанию block, кастомные элементы по умолчанию inline. Если вы предлагаете менять <div class> на кастомные элементы, то чтобы это было эквивалентно, для некоторых кастомных элементов нужно будет дописывать в CSS display: block, 14 дополнительных символов. В итоге в одном месте сэкономили, в другом дописали.
Третий аргумент — утилитарные классы и микроформаты. Даже если заменить <div class="card"> на <app-card>, может возникнуть желание использовать микроформаты на основе классов. Или размечать классами-модификаторами разные варианты карточек. Или использовать утилитарные классы для текста. Во всех случаях добавляется один или несколько классов. Получаем <app-card class="text-italic color-secondary">. Вернулся к атрибуту class. Сильно ли это отличается по объёму от <div class="card text-italic color-secondary"> и стоит ли оно того?
Вы можете возразить, что можно применять кастомные атрибуты. Но классы универсальны, они могут использоваться как на кастомных элементах, так и на стандартных. Кастомные атрибуты же будут невалидны для стандартных элементов. Можно вместо классов использовать data-*. Но если мы говорим про лаконичность, то это точно не про data-*.
Я надеялся что кто-то такой же дотошливый как и я сможет скинуть ссылку на программу которая текст из div class=text может прочитать, а из тега text или my-text не может.
А зачем такая программа должна существовать? DOM будет построен, а значит прочитать свойство textContent или innerText можно будет. Я не говорил, что текст кастомных элементов прочитать нельзя.
Специальным браузерам точно так же, что прост div что кастомный тег, нет разницы
Разница есть. Как пример специального браузера возьму Reader Mode. Он в разных браузерах реализован по-разному. Но общая суть одна: разобрать страницу, вычленить из неё основной контент и отобразить его в специальном виде, отбросив всё остальное.
Для этого Reader Mode полагается на эвристики, в первую очередь на семантику. Если использовать кастомные элементы вообще для всего сайта (я помню, что вы так делать не предлагали), то браузер просто ничего не распознает и не предложит включить Reader Mode. Если заменить только некоторые элементы, то Reader Mode просто выкидывает все кастомные элементы из итогового результата. А вот <div> с определёнными классами или без них в некоторых ситуациях не выкидывает.
То есть вы тот описанный в статье человек, который боится что где-то, когда-то , "на умном холодильнике" что-то пойдет не так
Нет, я не тот человек из статьи. Я активно использую веб-компоненты на своих проектах, но в виде интерактивных элементов. Я ровно так же, как и вы, задумывался об использовании валидных кастомных элементов в качестве альтернативы для некоторых generic-контейнеров.
Но я более прагматичен и придерживаюсь стандартов HTML. Поэтому я за использование валидных имён кастомных элементов и за замену ими нативных элементов только в ограниченном ряде случаев. Но в целом для меня достаточно много аргументов против, чтобы не заменять массово все <div> на кастомные элементы.
Спасибо! Мне нравится ваш серьезный вдумчивый подход.
Но на счет сжатия хоть это и звучит на первый взгляд правдоподобно, там как минимум нет разницы - количество токенов идентично.
Вот примеры сжатых через gzip файлов - https://drive.google.com/drive/folders/1Uijwa_bV0ULh72T3jlZJtC5jj9_d96nW?usp=sharing
Может их открыть и сами убедиться в том что файлы идентичны
Если в файл custom.html добавить хоть один div - то размеры сжатых файлов будут одинаковые - этот пример лежит в папке two
что касается дописывания display:block - во первых gzip сжатие =)
ну и тут уже вкусовщина - я за явное определение в css того как элемент должен отображаться
вот допустим у вас в css класс .wallet - допустим он применен к div - я за то чтобы в нем однозначно было написано что он блочный, хотя на практике все чаще flex или grid или inline-block
то есть в css все равно даже если использовать div - стоит указывать display
По поводу Reader Mode - пожалуйста уточните вы имеете ввиду режим чтения когда браузер меняет внешний вид страницы? или режим озвучивания для слабовидящих?
Если вы про вытаскивание текста из страницы - то это и сейчас не работает даже если использовать div
Попробуйте открыть в таком режиме интерфейс почты или календаря или вот вам пример из safari для новой главной страницы яндекса
Hidden text
Для корректной работы таких читалок сайт в большинстве случаев нужно специально адаптировать и название используемых тегов там не играют роли. Все равно нужно написать стили для печатной версии @media print {} а в них так же можно задать стили кастомным тегам как и классам.
+ остаются веб-приложения где такой режим как-бы не нужен - в доске trello например или в интерфейсе github как вы считаете reader mode имеет смысл ?
Если же вы говорите о программах которые озвучивают текст - то что для div что для my-tag-name - нужно писать aria атрибуты тут тоже нет разницы
ну и про микроформаты...
Третий аргумент — утилитарные классы и микроформаты. Даже если заменить
<div class="card">на<app-card>, может возникнуть желание использовать микроформаты на основе классов. Или размечать классами-модификаторами разные варианты карточек. Или использовать утилитарные классы для текста. Во всех случаях добавляется один или несколько классов. Получаем<app-card class="text-italic color-secondary">. Вернулся к атрибутуclass. Сильно ли это отличается по объёму от<div class="card text-italic color-secondary">и стоит ли оно того?
Дело в объеме кода как такового, а в объеме бессмысленного ничего не говорящего бойлерплейт кода. И даже если в общем символов больше - то типовых, ничего не значащих символов всё равно меньше.
Если мы захотим использовать микроразметку или добавлять классы своим тегам - мы да так и напишем <app-card class="text-italic color-secondary"> но в коде ниже у нас будет говорящий закрывающий тег </app-card> а не безликий </div>
И есть логическое разделение сущностей , согласитесь что css класс .card это вот что-то совсем не то же самое по своему назначению, что .color-secondary , а в случае использования div мы ставим их на один уровень. Когда тже мы используем app-card - мы в своем коде разделяем эти понятия, что вот есть карточка и у нее есть свои или внешние доп классы
Классы и атрибуты микроразметки продолжают работать, говорящее имя тега им не мешает , можете проверить - https://webmaster.yandex.ru/tools/microtest/
<div class="adr">Москва, ул. Льва Толстого, 16 </div>
<office-address class="adr">Москва, ул. Льва Толстого, 16 </office-address>
<book-name
about="urn:ISBN:0091808189"
typeof="http://purl.org/ontology/bibo/Book"
property="http://purl.org/dc/terms/title"
>Canteen Cuisine</book-name>'
<book-desc
about="urn:ISBN:1596913614"
typeof="http://purl.org/ontology/bibo/Book"
property="http://purl.org/dc/terms/description"
>White's autobiography</book-desc>.Картинка с валидацией микроразметки
Валидатор HTML не должен ругаться на элементы с черточками
Очевидно, что производные от XML языки (как XAML\AXAML в .NET) намного удобнее HTML. Приведенный автором пример синтаксиса как раз прекрасно существует в них. HTML больше похож на какой-то неудобный конструктор, куда не хочется возвращаться после десктоп разработки
HTML ведь тоже производный от XML язык. Проблема в том, что Тим Бернерс-Ли делал HTML для разметки научных документов, состоящих в основном из текста. Он не предполагал, что с его помощью будут делать веб-интерфейсы. Уже потом на скорую руку добавили формы, поля ввода в стиле Windows98 и прочее, потому что на HTML пытались делать интерфейсы.
А XAML и другие подобные языки изначально создавались для разработки интерфейсов и там by design были продуманы соответствующие механизмы.
Вот дело как раз в том, что уже давно, такая опция, by desing, есть и в html
Но разработчики её не используют... продолжая верстать интерфейс приложений как будто это текст книги
Я с вами согласен. А на счет производных от XML имел в виду валидацию по XSD, что потенциально и дает указанную автором поста расширяемость, но чего нет в HTML
Как это нет?) Все в HTML5 очень четко. Не уступает XML.
Есть теги встроенные, есть теги кастомные (правильно названы те, что имеют чёрточку в названии). Кастомные теги делятся тоже на два вида: зарегистрированные и незарегистрированные.
Незарегистрированные кастомные теги отображаются как display:contents.
HTML5 просто не будет орать, что встретил неизвестный элемент, потому что неизвестный кастомный элемент с валидным именем имеет тип HTMLElement наравне со стандартными зарегистрированными. Ничем не отличается.
document.createElement("as-sasas-sas").constructor
// -> ƒ HTMLElement() { [native code] }А кроме HTMLElement есть неправильные элементы (invalid). Они имеют тип HTMLUnknownElement.
Это те элементы, которые
имеют неправильный синтаксис имени
имя которых состоит из одного слова, но оно не зарегистрировано в доктайпе HTML5.
document.createElement("llalalalala").constructor;
// -> ƒ HTMLUnknownElement() { [native code] }Так как имена тегов находятся все в едином глобальном неймспейсе, то именовать кастомные теги надо многосложно, в соответствии с FQN. Так вы минимизируете вероятность конфликта имён с другими любителями кастомных тегов.
Для соединения слов лучше использовать kebab-case. Это позволит в последствии добавлять к ним логику, не меняя нейминга. Нативный lowercase сложнее читать и он чреват конфликтом с нативными элементами. Если же нативные веб-компоненты не нужны, то snake_case ещё более предпочтительный.
Стили лучше не прикреплять к именам тегов, так как это не позволяет использовать одни и те же стили для разных компонент - их придётся дублировать. Для стилей лучше использовать атрибуты или классы, которые можно добавлять к разным тегам. Первые более гибкие благодаря богатству css3-селекторов, вторые - более традиционные. В обоих случаях, опять же, не забываем про FQN и нейминг.
snake_case ещё более предпочтительный.
Офигенный совет юзать невалидные теги.
document.createElement("snake_case").constructor
// HTMLUnknownElement() { [native code] }Так как имена тегов находятся все в едином глобальном неймспейсе, то именовать кастомные теги надо многосложно, в соответствии с FQN.
Офигенный совет юзать FQN в названиях тегов: типа файловый путь до декларации тега в сорсе. Эм, я не против смелых и безумных идей, но для чего это извращение? Там у ТС HTML-first. И я давно не видел, что объявление стилей привязывают к именам тегов.
Ужас-то какой. Вам шашечки или ехать?
FQN про неймспейсы, а не про пути к файлам.
Будьте добры, раскройте мысль тогда. C HTML 4.0 не путаете?
Насколько помню, HTML5 не поддерживает кастомные неймспейсы для элементов. В спеке писалось, что валидные кастомные имена элементов могут содержать только черточку, двоеточия там нет.
document.createElement("span:foo").constructor
// HTMLUnknownElement() { [native code] }Что касается document.createElementNS, то она же относится к XHTML, а не HTML5. Сможете привести какой-то пример для HTML5?
Если у вас получится привести пример, интересно увидеть наглядное преимущество использования неймспейсов. Потому что я вижу только один проблемный момент. И он заключается в том, что кто-то может зарегистрировать имя кастомного элемента и юзать его как веб-компонент (управлять поведением тега через js). Если же использовать кастомный элемент как разметку (то есть не как веб-компонент), то проблемы нет.
Так как я уверен, что для HTML5 нет неймспейсов, поэтому и подумал, что вы предлагаете использовать пути к файлам. Иначе тогда вас вообще не понял )
Нейминг HTML-тегов