Comments 38
Прошу прощения у автора комментария, который задал вопрос про SEO, я тупо промахнулся и вместо написания ответа отклонил его. :с
Касаемо влияния кастомных тегов на SEO и подобного - они равнозначны span, а значит семантики не имеют. Роботы их не учитывают.
Безусловно, им можно задать семантику через атрибут role, но это сомнительно. Если есть возможность - используйте семантические встроенные теги вместо кастомных.
Статья о веб-компонентах. Лайк!
Сделаю несколько уточнений.
Никто, за редчайшими исключениями, не использует кастомные теги, не говоря уже про их API. А очень зря.
Это кажется так. Их используют, просто об этом никто не знает. Ну и используют их крупные компании в основном. Из примеров: интерфейс Chrome, Edge и Firefox, включая DevTools, YouTube, VS Code, GitHub, Photoshop Web, MSN, Windows Store, Bing, Epic Games Store и т.д.
Красивая портянка, не правда ли? Предлагаю сделать её проще и понятней
Замена div + class на кастомный элемент может и сделало код читабельнее и понятнее, но семантика потеряна. Все же заголовок должен быть h*, вводная часть в header, копирайт в footer, а сам компонент - section, article, aside или чем-то ещё в зависимости от контекста. Семантика нужна поисковым роботам, ассистивным технологиям (для доступности), плагинам и т.д.
Даже если это div-ы, у которых нет семантики, роботы все равно умеют анализировать их по другим эвристикам. Я думаю, что за столько лет существования миллиардов сайтов с div-ами, роботов научили определять контент, в том числе по классам, вложенности, каким-то повторяющимся паттернам, даже с div. Утверждать это на 100% я не могу, никто не знает алгоритмов. Но я думаю, что это так.
Отличие лишь в том, что
div- блочный, аspan- строчный.
div - потоковый и ощутимый (Flow и Palpable), а span - потоковый, фразовый и ощутимый (Flow, Phrasing и Palpable). Блочный и строчный - это термины из HTML4, в HTML5 их упразднили в пользу категорий и контентных моделей.
С точки зрения семантики, стилей и функционала кастомные html-элементы равноценны тегу
spanцеликом и полностью.
Не совсем. С точки зрения категорий - да. С точки зрения базовых стилей - да (оба display: inline). Но у кастомных элементов контентная модель - прозрачная, а у span - фразовый контент. Это значит, что в span нельзя вложить div, ul, section (любой не фразовый контент), а в кастомный элемент можно вложить все, что можно в его родителя.
Никто, за редчайшими исключениями, не использует кастомные теги, не говоря уже про их API. А очень зря.
Насколько я помню, кастомные тэги были одной из ключевых концепций в Google Polymer. Ну т.е. не то чтобы их совсем-совсем не применяли, нет. Но во второй уже кажется версии все изменилось. И да, я согласен, что зря.
Кастомный тег ради красивого (сомнительно) именования – это так себе идея.
Когда речь идёт о полноценном использовании web-компонентов (включая теневой DOM) – это совсем другое дело. Но об этом не написано.
Думайте над прочтённым, я привёл аргументы в пользу того, зачем их использовать.
1: Кастомные теги в ~80% случаев заменяют классы, особенно при использовании атрибутов. Это не столько красиво, сколько короче.
И да, дублирование кода (даже такими вещами как атрибут class) - не есть хорошо, хоть и терпимо. Логика тут такая же, как и при необязательных точках с запятой в JS.
2: "Но об этом не написано" - читайте прежде чем писать или очки снимите. Я и про JS API упомянул, и про теневой DOM, и про кастомизацию встроенных тегов.
Вопрос о целесообразности остается открытым. Семантической нагрузки кастомные теги не несут. Экономия на символах тоже выглядит сомнительной. Сейчас вы сэкономили 2 килобайта, а потом подключили библиотеку на 50к. Ну и в чем смысл?
Ремарку о дублировании кода в виде атрибутов class я честно говоря не понял. Вы говорите именно о названии атрибута, или о его содержимом? В первом случае это какой-то бред, во втором я не вижу разницы между дублированием в коде названия класса и дублированием названия тега.Если я сниму очки, то вообще не смогу ничего прочитать, к сожалению.
Я читал вашу статью, будьте уверены. Но сейчас все же выполнил поиск по странице. Слова "web", "shadow", "DOM" и "компонент" в вашей статье не встречаются. Они появились только в комментариях.
1: Вопрос о целесообразности - закрыт. Использовать кастомные теги без семантики заместо вместо div-ов и span-ов без семантики, что бы не было необходимости прописывать классы. Если есть встроенные теги с семантикой - следует использовать их. Я не писал о том, что и про них нужно забыть.
Смысл не в экономии килобайт (вы серьёзно подумали, что для работы кастомных тегов нужна библиотека?), смысл в том, что бы писать меньше (атрибут class, как и data-* не используется), а значит - быстрее. Нет, правда, почему я должен доносить настолько очевидные вещи!?
Бонусом частичное решение проблем каскада (переопределить тег классом проще, чем другой класс).
Если вы и в правду не смогли понять, почему теги предпочтительней классов в ~80% случаев, перечитайте статью, вас интересует первая половина.
2: Прошу, наденьте очки обратно и удалите затемняющий слой, или что там у вас на очках - вы даже с ними плохо видите.
Прочтите статью ЦЕЛИКОМ, вас интересует раздел "Расширенное использование или JS API". Уделите время и вы всё найдёте.
И да, вы не нашли слово "shadow" в тексте потому, что я использовал вместо него слово "теневую" (теневую разметку). Пересмотрите свой опыт использования поиска по словам.
Нет, все же вопрос закрыт только в вашей голове. Совершенно не понятно, почему нужно уходить от классов, и почему это вдруг дата-атрибуты станут не нужными?
У каскада вообще нет никаких проблем. Может быть вы имели ввиду специфичность селекторов?
В комментариях правильно отметили, и я это же пытаюсь вам донести – в кастомных тегах самим по себе нет смысла, они не нужны. Смысл есть в web-компонентах, инкапсулирующих в себе некую функциональность. А кастомные теги являются всего лишь частью этой подсистемы.
Прошу, наденьте очки обратно
Видимо, вы не догадались, что у меня плохое зрение. Иначе ваша реплика выглядит хамством.
Что же, попробую ещё раз.
Значительную часть структуры сайтов делают не из семантических тегов, а из тегов общего назначения - div, span, даже section и article туда можно отнести.
Что бы использовать их в целях стилизации и не “промахнуться", дав стили другому тегу, для них назначают классы и даже атрибуты. Про результату имеется нагромождение div и span, смысл которых понятен только из их класса.
Кастомные теги, если не использовать их API, позволяют использовать их уникальное имя для стилизации и прочего, минуя необходимость писать атрибут class, и в некоторых случаях data-*. Уникальное имя выполняет функции выделения блока среди других, а за счёт отсутствия необходимости писать атрибуты для этого позволяет писать разметку быстрее, а сама разметка становится короче.
Ты же логика и с атрибутами - порой проще написать атрибут без data-*, чём подписать класс, а эффект будет такой же.
Придумал!
С кастомными тегами селектор :nth-of-type можно заставить работать так, как ожидают от него многие новички =) Больше ничего в голову не приходит.
Прошу прощения у автора комментария, который задал вопрос про SEO, я тупо промахнулся и вместо написания ответа отклонил его. :с
Касаемо влияния кастомных тегов на SEO и подобного - они равнозначны span, а значит семантики не имеют. Роботы их не учитывают.
Безусловно, им можно задать семантику через атрибут role, но это сомнительно. Если есть возможность - используйте семантические встроенные теги вместо кастомных.
Я не фронтенд, только пишу свое приложение с фронтом и как-то получилось, что пишу на web components (через Lit). Я так понимаю, что web components хороши для дизайн-систем - создания каких-то базовых компонентов, которые снаружи стилизовать почти невозможно. В частности, нельзя адекватно какие-нибудь иконки прикрутить через внешний CSS. То есть, видимо, для создания приложений надо использовать комбинацию web components (для всяких примитивов - кнопок/табов/прочего) и фреймворка (для компонентов с бизнес-логикой)?
Не в курсе про Lit, но использование веб-компонентов вообще необязательно. Существует нескромный арсенал встроенных, как семантических тегов (вроде section, hr и header) так и возможность стилизовать общие теги (div, span) через классы.
Те же кнопки прекрасно реализованы через тег button.
И да, для использования веб-компонентов, как и других тегов использование JS API обязательно чуть менее, чем полностью.
Осталось прикрутить реактивность и будет великое чудо
Статья о веб-компонентах. Лайк!
Сделаю несколько уточнений.
Никто, за редчайшими исключениями, не использует кастомные теги, не говоря уже про их API. А очень зря.
Это кажется так. Их используют, просто об этом никто не знает. Ну и используют их крупные компании в основном. Из примеров: интерфейс Chrome, Edge и Firefox, включая DevTools, YouTube, VS Code, GitHub, Photoshop Web, MSN, Windows Store, Bing, Epic Games Store и т.д.
Красивая портянка, не правда ли? Предлагаю сделать её проще и понятней
Замена div + class на кастомный элемент может и сделало код читабельнее и понятнее, но семантика потеряна. Все же заголовок должен быть h*, вводная часть в header, копирайт в footer, а сам компонент - section, article, aside или чем-то ещё в зависимости от контекста. Семантика нужна поисковым роботам, ассистивным технологиям (для доступности), плагинам и т.д.
Даже если это div-ы, у которых нет семантики, роботы все равно умеют анализировать их по другим эвристикам. Я думаю, что за столько лет существования миллиардов сайтов с div-ами, роботов научили определять контент, в том числе по классам, вложенности, каким-то повторяющимся паттернам, даже с div. Утверждать это на 100% я не могу, никто не знает алгоритмов. Но я думаю, что это так.
Отличие лишь в том, что
div- блочный, аspan- строчный.
div - потоковый и ощутимый (Flow и Palpable), а span - потоковый, фразовый и ощутимый (Flow, Phrasing и Palpable). Блочный и строчный - это термины из HTML4, в HTML5 их упразднили в пользу категорий и контентных моделей.
С точки зрения семантики, стилей и функционала кастомные html-элементы равноценны тегу
spanцеликом и полностью.
Не совсем. С точки зрения категорий - да. С точки зрения базовых стилей - да (оба display: inline). Но у кастомных элементов контентная модель - прозрачная, а у span - фразовый контент. Это значит, что в span нельзя вложить div, ul, section (любой не фразовый контент), а в кастомный элемент можно вложить все, что можно в его родителя.
Это кажется так. Их используют, просто об этом никто не знает.
Крупнейшие компании мира делают и поддерживают очень малый объём сайтов, их творения вполне можно считать редкостью.div-ы я использовал нарочито, специально. О том, что существуют семантические теги для соответствующих целей я знаю, но нужно же было дать понять всю глубину глубин.
Один из трёх популярнейших фреймворков, angular, это шутка такая для вас?
Angular работает как сторонняя библиотека, ей даже пользоваться надо уметь. Кастомные элементы работают из коробки, как и другие теги, и если не трогать API - даже изучать не надо.
Использовать веб-компоненты просто как замену div это глупая идея и плохой пример. Вы сравниваете нарочно плохую верстку с нарочно еще более плохой версткой. + Браузер и поисковик только теряют в семантике от того, что вы свои header и аналоги div придумываете и призываете их использовать ради красоты не используя js. + вам нужно свойство display как минимум прописать для корректного отображения.
Использовать веб-компоненты нужно обязательно вместе с их возможностями, а не просто ради именования тегов. Я тоже делал несколько статей про веб-компоненты
https://webislife.ru/strokoff/polnoe-pogruzhenie-v-veb-komponenty-v-2023-godu/ а также по крупицам собираю цикл статей про веб-компоненты https://webislife.ru/strokoff/czikl-statej-pro-veb-komponenty/ и на хабре еще публиковал пример веб-компонента на хабре Пишем собственный WYSIWYG редактор на основе веб-компонентов и textarea.
Использование веб-компонентов должно быть не для замены div-ов, а для замены их классов, в следствии чего улучшается читаемость и уменьшается объем кода, да и некоторые проблемы каскада от этого решаются. Это не только красиво, но и практично.
Вы сравниваете нарочно плохую верстку с нарочно еще более плохой версткой.
Специально сделал такой пример, что бы показать разницу наиболее наглядно. Я в курсе, что можно сделать лучше.
вам нужно свойство display как минимум прописать для корректного отображения.
И без него будет корректно отображаться, а про их изначальный стиль в статье упомянул:
Да да, все ваши кастомные элементы изначально строчные. Учитывайте это при стилизации.
И да, посмотрел вашу статью про веб-компоненты. Вам непременно нужны хотя бы два курса журналистского факультета, содержание нормальное, структуру нужно дорабатывать.
Это не только красиво, но и практично.
Верстка должна быть в первую очередь семантичной для поисковиков и машин которые ее будут обрабатывать. Вопросы красоты не должны стоять на первом месте при выборе HTML элементов для разных ситуаций. Практичность тоже очень субъективное понятие.
Специально сделал такой пример, что бы показать разницу наиболее наглядно.
Выходит вы показали разницу как делать не надо и как делать совсем не надо.
И без него будет корректно отображаться
Все будет инлайновыми элементами - это не нормально, разве что вы не пытаетесь верстать текст и выдумывать свои аналоги span\em\b\strong\mark etc..
Вам непременно нужны хотя бы два курса журналистского факультета, содержание нормальное, структуру нужно дорабатывать.
Всего лишь 2 курса? Переход на оценку личных качеств это грязный прием, когда по существую и содержанию сказать нечего, а по форме хочется докопаться.
Еще раз веб-компоненты это не замена для семантических тегов существующих, страница сверстанная красиво и практично по вашим понятиям, в выдаче поисковой проиграет странице сверстанной по канонам семантики и доступности. Веб-компоненты это история, когда вам мало 1 тега для вашего элемента или вашему элементу нужен интерактив в виде js. Яркими примерами веб-компонентов можно считать <audio> и <video> теги, там и стили внутри свои и shadow dom присутствует.
Верстка должна быть в первую очередь семантичной для поисковиков и машин которые ее будут обрабатывать
В таком случае, переход веба на машинный код или тотальное использование веб-фреймворков в вашей логике является совершенно практичным... О людях подумайте.
Практичность тоже очень субъективное понятие.
Принцип DRY, как и время - очень субъективная штука!
Выходит вы показали разницу как делать не надо и как делать совсем не надо.
Вы небось когда читали учебник физики, пребывали в ярости - ну к чему эти абстрактные примеры в вакууме!? Где искажение времени, вызванное гравитацией!?
Вам непременно нужны хотя бы два курса журналистского факультета
Всего лишь 2 курса?
АХАХАХА, вы умеете себя в грязь затаптывать. Да, журфак не повредит. Да что уж там, вам не повредит дополнительное образование в любом объёме и количестве.
Вы бы остановились, вас уже понесло
В таком случае, переход веба на машинный код или тотальное использование веб-фреймворков в вашей логике является совершенно практичным... О людях подумайте.
Веб давно на фреймворках сидит, на велосипедах сидят только их изобретатели. Все более менее серьезные проекты формируются с большим комьюнити. Мне бы не хотелось попасть после вас на проект, где в место css классов написаны веб-компоненты просто потому что автор так мог себе позволить.
Принцип DRY, как и время - очень субъективная штука!
Использование стандартных тегов и веб-компонентов не противоречит DRY в целом. Кажется что вам просто нечего было написать, а ответить хотелось.
Вы небось когда читали учебник физики, пребывали в ярости - ну к чему эти абстрактные примеры в вакууме!? Где искажение времени, вызванное гравитацией!?
И очередной переход на личности, от новорега с НЛО приглашением
АХАХАХА, вы умеете себя в грязь затаптывать.
Пожалуй эту ветку комментариев действительно стоит остановить, слишком много грязи которую в целом уже и комментировать противно.
вам нужно свойство display как минимум прописать для корректного отображения.
Я не вебдева, но вроде:
If no inner display type value is specified, the principal box’s inner display type defaults to flow. If no outer display type value is specified, the principal box’s outer display type defaults to block.
При этом: "Initial: inline". Но так как вы ниже пишите "Все будет инлайновыми элементами - это не нормально", то всё сходится? То есть, изначально inline, а вот если в стилях указан один из inner/outer, то второй применяется как из процитированного параграфа?
Статья отличная, не хватает только пары слов про CSS. А именно, для каждого такого тега в стилях обязательно нужно указать display (block, flex, inline, чё там у вас). Тогда это даже в IE 7 заработает.
Раньше, кстати, можно было расширять DTD. Что-нибудь типа <!ELEMENT widget (value|preset|default|state)*>
Покуда я именно на эту страницу засмотрелся, вот она: https://www.w3.org/TR/html4/intro/sgmltut.html#h-3.3.3
попробуйте узнать у бизнеса, готов ли он просто так выкинуть 2.7 процента аудитории. Особенно когда принимается ряд решений, типа тут пол процента, тут 2 процента, там 5 процентов, а потом люди удивляются, что это все ушли к конкуренту.
Несколько моментов из моего опыта с кастомными элементами:
к кастомным элементам часто называют веб-компонентами, но они являются только одной составляющей набора API веб-компонентов (другие вещи включают в себя shadow DOM, HTML templates и тд) - подробнее тут
с помощью
aria-аттрибутов кастомные элементы можно наделять семантикой, для лучшей SEO и accessibility (если вы уже активно используете их или другие аттрибуты, то кастомные компоненты могут помочь вам еще больше сократить объем кода и улучшить читаемость)среди важных проблем - server-side rendering. Кастомные элементы требуют исполнения JS кода на стороне клиента для рендера, соответственно их сложнее использовать в контексте SRR-приложений. Аспекты типа локализации, server-side авторизации, использования CMS могут усложняться, и вам придется придумать как это решать. Поэтому предпочтительно может быть использовать web-component библиотеки которые уже это делают, но в ущерб минимализма и нативности API :)
О кастомных HTML-тегах по-человечески и как их использовать