Верстальщик использует кастомные теги например это влияет как-то на SEO?

Проблем не будет, не переживайте.

Для СЕО используются тайтол страницы, заголовки H1-H6, мета-теги... с ключевыми словами, и по ключевым словам выбирается текст со страницы. Потом по этим данным поисковик выдаёт результаты поиска.

custom elements тоже есть в стандарте, просто я не знал о них до этого. и не знаю как это влияет на поисковики. Может есть опыт? как я понял никак не влияет, то ок.

Наоборот он с точки зрения разработчика, сделал правильно, красиво, лаконично и поддерживается проще за счёт даже просто правильных имён. Но у нас же seo, можно красиво на реакте / аяксе сайт сделать, а потом будут проблемы с индексированием в поисковиках. Поэтому спрашиваю про custom elements , нет с ними проблем в поисковиках с индексированием, весами и т п?

Ну это как глянуть.. Вот напр возьмём код Тса.

судя по названиям там наверняка кнопки и чекбоксы-селекты. Ессно, всё это жирно смазано жабаскриптными свистоперделками. Так вот это не будет работать/поломает вёрстку в устаревших браузерах. А даже там, где будет работать - не факт что не будет тормозов и глюков. Про стоимость, тестирование и поддержку всего этого барахла даже не заикаюсь.

И вот ради чего всё это? Неужели нельзя было сделать "по-простому"? Я почти уверен что можно, но, да, для окончательных выводов надо знать больше, чем рассказал ТС.

А если это сделал действительно верстальщик, а не кодер, реализующий необходимый функционал, то вообще.. просто выёживание. А может даже и копипаст чужого кода без понимания, необходимости/целесообразности.

Они есть в стандарте, но не являются стандартными. Поясняю: стандартные - это те, которые описаны в стандарте. А для пользовательских элементов стандарт лишь оговаривает возможность их применения, но не даёт описания, потому что они неизвестно какие, на совести разработчика.
Опыта нет, потому что у меня не было ситуации, когда они понадобились бы. Я не разрабатываю собственных фреймворков, я использую стандартные возможности.

Ну вот опыт с красивыми разработчиками у меня как раз есть. Они делают всё так красиво, сдают заказчику, а потом через некоторое время сайт по разным причинам попадает ко мне на поддержку. И начинается:
- а почему у меня в Edge  слайдер криво работает?
- а почему на смартфонах форма обратной связи не работает?
- а почему Мазила картинки в ряд не выстраивает?
- а почему на макбуке шапка уехала?

А потому что красиво было только при тех условиях, которые были изначально при сдаче сайта. А потом, когда стали загружать свои данные и реальные пользователи стали работать на реальных устройствах, всё сломалось. И мне с этим разбираться. Поэтому, если у Вас есть уверенность, что Вы постоянно будете работать с этим разработчиком, несколько лет хотя бы, - то пожалуйста, пусть делает, как ему удобно. Если же разработали - и пока-пока, то надо подумать.

Элементы разные бывают. С теми кнопками, что в стартпосте - едва ли будут проблемы с индексированием.

1. В самих кастомных элементах нет "жабаскриптных свистоперделок". Это почти обычные теги которые размещаются в теге <template>
2. Все современные браузеры эту технологию поддерживают, особенно это актуально для мобильных устройств, а если вы всё ещё пользуетесь IE 2000г. флаг вам в руки..
3. JS код нужен как и на обычных страницах только для модификации элементов их регистрации customElements.define
4. Стоимость разработки тут намного меньше, если кто-то завышает сумму, то они просто хотят на халяву взять больше

Тот кто так сделал разбирается в современных возможностях браузеров и использует это.

Вот как раз когда делается без применения новых возможностей flex,grid, кастомных элементов и др. то сайт нагружается свистопеределками под разные браузеры и тд. Когда ТСу сделают по современному, то при поиске другого разработчика будет требование чтобы тот знал технологию кастомных тегов и неумехи/бездари отметутся, работа будет сделана более качественно.

Работа - да, качественно будет сделана. Только работать нифига не будет. Ну да о чём с Вами разговаривать, если Вы не работаете с реальными сайтами и реальными заказчиками... Теоретик... Идите свой "фремворк" доделайте уже, а то за три года разработки его уже перерабатывать пора.

Вот у вас естественно конечно перестаёт работать, а у людей если сделано правильно, всё прекрасно работает. Что мне делать сам решу, а вот вы воспользуйтесь своими же советами, подучите JS, CSS, новые возможности браузеров и тогда не придётся вам тут всё объяснять... не будете надеюсь тогда писать тупых комментов..

Это по Вашей теории. А в реальной действительности ко мне обращаются именно тогда, когда что-то перестаёт работать. Это существенная часть моего заработка.

Ага. И в который раз, вместо того, чтобы заняться своим делом, Вы советуете мне что-то там изучать. Занятно.

Мне кажется это я объясняю, разве не так? И у кого после этого тупые комменты? "Фремворк" когда уже доделаете, теоретик Вы наш форумный?

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

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

Использовать новые технологии - приемлемо. Когда заказчик поставлен в известность и когда это оправдано. Любой нормальный проект живёт не в сферическом вакууме(я не говорю про Ваш фреймворк, он как раз из этого вакуума так и не вылез), а значит нужно учитывать не только "здесь и сейчас" а ещё и "потом и тогда".

Лично я практически не сталкивался с кастомными css свойствами. У меня тут мало опыта, мне не стыдно это признать :) Но опыт работы(в моей нише, так сказать) подсказывает что эти "модные фишки" не особо нужны.

Может со временем я и приду к осознанию необходимости этих инструментов, кто знает. Загадывать не буду.

Важное я выделил цветом.

Я нигде не призывал вернуться к CSS 1. Но к использованию ненужных наворотов в клиентских проектах я отношусь резко негативно.

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

Да вполне может быть что проблема в lazy load. Однако это баг, да и вообще глупое решение. Зачем на фоновые элементы дизайна ставить lazyload? Ладно там на картинки в постах\сущностях. Даже если что-то не подгрузилось - не велика беда. Но без элементов дизайна сайт выглядит откровенно коряво. И как показал этот баг, работает такой подход "как бог на душу положит"...сейчас работаю, через пол часа - нет) Если стоит задача уменьшить вес страницы - можно просто уменьшить размер файла изображения. Методов - хватает, как на мой взгляд.

Вы заказчик, раз вам всё нравится - значит всё гуд) Проблем с ПС по идее быть не должно. Но это по идее и основываясь на моём опыте, у меня он в применении custom elements не особо велик. В любом случае я даже при чтении статей не натыкался на посты о том, что ПСки плохо индексируют такие блоки. Но опять же - это ничего не гарантирует :)

Я в курсе. Это просто пример не нужного наворота, который вызвал проблему. Не более.

Деталей действительно маловато.

Может быть - такая реализация там действительно нужна и без неё всё будет гораздо сложнее. Но лично я в этом сомневаюсь.

В любом случае да - ТСа ждёт масса "счастья и любви" когда в будущем ему понадобиться внести какие то правки в этот код) А так как в любой живой проект правки вносятся постоянно...

Зыбко всё это.  Без реального кода, без реальной вёрстки совершенно не понятно, оправдано ли применение этих наворотов или нет.