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

Суровая реальность такова - не существует людей которые не "косячат". Ошибки допускают все, особенно хорошо это заметно, когда разговор уходит от "сферического вакуума" и переходит к реальным примерам. Теневой DOM, custom elements и прочие танцы с утятами - заметно усложняют поддержку и сопровождение продукта. Повышают требования к специалисту. Увеличивают процент "эпик фейла".

Если это требует заказчик - вопросов нет. Если без этого нельзя обойтись - вопросов нет. Если это личный проект или тренировка на хомячках - вопросов нет.

Если заказчик этого не просил и это не обсуждалось, если необходимости в такой структуре нет и можно реализовать и без этого, если это клиентский проект и нужно учитывать что он будет потом как то "жить" после сдачи текущим специалистом - вопросы есть.

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

Стандартные теги HTML - это теги, определённые стандартами HTML, поведение которых определено этими стандартами, документировано и известно специалистам. А пользовательские теги - нестандартные, поведение которых задаётся костылями через JavaScript.

Использовать тогда, когда есть необходимость. А не так, как Вы и верстальщик из стартпоста: я не знаю, как это решить стандартными методами, поэтому давай-ка я понаделаю своих собственных тегов.

Ещё раз:  я об этой технологии давно знаю, но необходимости в её применении до сих пор не возникало.

Для того, чтобы решить задачи, которые сложно решить с применением стандартных тегов. Диагност Вы наш доморощенный.

И костыль можно переделать так, что искалкам виден "текст" в них или не виден, если не нужен.

Для ответа на вопрос ТС не хватает данных.

Любой косяк всегда можно исправить, а для этого нужно изучать технологии или находить хорошего специалиста. Конечно можно делать старыми способами, но отказов и косяков при этом будет больше. Современные технологии для того и придуманы чтобы улучшить работу проектов.

Если реализовать не используя новые технологии, то в скором времени появятся проблемы, кто не развивается тот умирает.

Пользовательские теги это такой же стандарт т.к. эти технологии уже признаны многими разработчиками браузеров и сайтов.

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

Да потому что не понимаете для чего это применяется и как этим можно облегчить себе жизнь.

Не правильный ответ. Диагноз:  у вас нет знаний современных веб-технологий.

Правильный ответ: чтобы делать свои веб-компоненты.

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

<good-card foto="img/testgood.jpg" price="100">
 Тестовый товар
</good-card>

На странице же будет красиво оформленный блок карточки товара.

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

Судя по этой фразе, Вы просто не понимаете значения термина "стандарт".

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

И усложнить жизнь другим.

Ответ правильный. И краткий, вместо того размазывания, которое у Вас. Диагност Вы наш доморощенный.

Бездарь 😀

Я, в отличие от Вас, умею делать блоки стандартными средствами.

И ничего не поняли, поэтому решили городить свой собственный "фремворк".

Нужно понимать, где и для чего применять технологию, а не просто городить пользовательские теги, потому что это круто.

Хам. Всё сказали? Идите, изучайте стандарты HTML и CSS.
Одарённый Вы наш.

Сейчас все усложняется. А "специалист" должен обладать определенной квалификацией.

А если она есть, customElements наоборот, упрощает многие вещи. Ну вот, пример. У меня, достаточно продолжительное  время экслуатировался собственный фреймворк, который в числе прочего,  на определенные элементы (data-url) вешает функционал валидации и отправки запроса на сервер.

<input type="text" data-url="/api/search" data-min="3" data-max="128">


let a = document.querySelectorAll('[data-url]');
a.forEach(el=>{        
  axhr.init(el);
});

Что то около 2000 строк кода. Правда там еще модальное окно и уведомление noty. Если xhr запрос возвращает  какой то элемент с data-url,  который тоже должен при определенных условиях отправлять запрос на сервер, то его надо определить и повесить обработчик - лишние телодвижения.

Сейчас перепиливаю на

<xhr-input type="text" data-url="/api/search" data-min="3" data-max="128"></xhr-input>

import { appModal } from "./appmodal.js";
import { appNoty } from "./appnoty.js";
import { xhrInput } from "./xhrinput.js";
import { xhrSelect } from "./xhrselect.js";
import { xhrForm } from "./xhrform.js";

customElements.define('xhr-input', xhrInput);

Четко, прозрачно и просто.  Достаточно посмотреть xhrInput в 70 строк и все  предельно ясно, чем ковырять в 2000 строк кода. Любой новый элемент вставленный в документ, уже имеет все нужные обработчики.

А дальше вебпак и

code generated modules 213 KiB (javascript) 24.1 KiB (css/mini-extract) [code generated]
  modules by path ./src/css/*.css 250 bytes (javascript) 24.1 KiB (css/mini-extract)
    cacheable modules 250 bytes 5 modules
    css modules 24.1 KiB
      css ./node_modules/css-loader/dist/cjs.js!./src/css/index.css 1.54 KiB [code generated]
      css ./node_modules/css-loader/dist/cjs.js!./src/css/sprite.css 868 bytes [code generated]
      css ./node_modules/css-loader/dist/cjs.js!./src/css/panels.css 7.38 KiB [code generated]
      css ./node_modules/css-loader/dist/cjs.js!./src/css/form.css 13.9 KiB [code generated]
      css ./node_modules/css-loader/dist/cjs.js!./src/css/media.css 480 bytes [code generated]
  ./src/index.js + 28 modules 134 KiB [built] [code generated]
  ./src/logined.js 23 bytes [built] [code generated]
  ./src/slider.js + 1 modules 78.9 KiB [built] [code generated]
webpack 5.37.0 compiled successfully in 1735 ms

Вероятно это сделано для lazy load чтобы фоновая картинка не сразу грузилась, а отложено. Это обычное решение для lazy load, просто в данном случае баг.  

Про custom elements в моем случае они там по делу используются для удобства разработки, в одном блоке как бы логично всё. Вот боюсь как поисковики будут воспринимать, если проблем не будет то все ок.