Кастомные теги лишены должной семантики изначально, по сравнению со стандартными тегами, если их создавать с нуля, поэтому за такое спасибо не скажут и различные плагины, и скринридеры, и приложения (например преобразующие страницу в удобно-читаемый вид без лишнего контента). Семантику, конечно, можно будет прикрутить, но это придется править для каждого кастомного тега ручками. НО лучше всего просто создавать теги за счет расширения существующих экземпляров класса (например, HTMLButtonElement) и тогда семантика подтянется соответствующая. Здесь вопрос скорее в другом, зачем плодить такие элементы для решения заданного автором статьи вопроса? Мало того, что создаются какие-то дубликаты существующего инструментария, так эти кастомные теги еще не так просты, как кажутся на первый взгляд, и требуют должного внимания к ним. На мой взгляд автор предлагает решить одну маленькую проблему путем, на котором встретятся множество других проблем, которые могут оказаться посерьезнее. При прочтении заголовка статьи я ожидал увидеть CSSinJS подход. При прочтении статьи на середине я ожидал увидеть упоминания css переменных. Вместо этого я увидел хардкор-код с бойлерплейтами и жалобой, дескать не хочу добавлять лишнего инструментария (но, например, полифилл для кастом стейт в конце добавить почему-то предложил), поэтому давайте плодить множество data-атрибутов и кастомных тегов. О возможных подводных камнях, которые имеются, не написал ничего. При том решил ли автор поставленного им же вопроса? Большая часть опции в виде close/open, loading/loaded и прочие обычно управляются переменными состояния и, если они неправильно перетирают друг-друга, то решать вопрос нужно совершенно иначе и в самом коде логики. Остальная малая часть опции, если правится руками, требует банальной проверки результата (в идеале скриншоты тесты, конечно), причем это потребуется даже в случае с предложенным автором решениями, поскольку и в атрибутах, и в тегах, можно также легко накосячить.
Вы слишком многое ожидаете от автора статьи. Человек ткнул в известный факт и сделал из этого целую статью, но не объяснил в чем конкретно присутствуют проблемы и как мы в этом оказались. Не объяснил про трекеры, рекламу, аналитику, лишние библиотеки, стили в js и медленное перетекание логики сервера на фронт, а также многое другое. Исходя из этого можно сделать вывод, что автор возможно сам не имеет представления о происходящем и в оптимизации особых знаний не имеет.
Кастомные теги лишены должной семантики изначально, по сравнению со стандартными тегами, если их создавать с нуля, поэтому за такое спасибо не скажут и различные плагины, и скринридеры, и приложения (например преобразующие страницу в удобно-читаемый вид без лишнего контента). Семантику, конечно, можно будет прикрутить, но это придется править для каждого кастомного тега ручками. НО лучше всего просто создавать теги за счет расширения существующих экземпляров класса (например, HTMLButtonElement) и тогда семантика подтянется соответствующая. Здесь вопрос скорее в другом, зачем плодить такие элементы для решения заданного автором статьи вопроса? Мало того, что создаются какие-то дубликаты существующего инструментария, так эти кастомные теги еще не так просты, как кажутся на первый взгляд, и требуют должного внимания к ним. На мой взгляд автор предлагает решить одну маленькую проблему путем, на котором встретятся множество других проблем, которые могут оказаться посерьезнее.
При прочтении заголовка статьи я ожидал увидеть CSSinJS подход. При прочтении статьи на середине я ожидал увидеть упоминания css переменных. Вместо этого я увидел хардкор-код с бойлерплейтами и жалобой, дескать не хочу добавлять лишнего инструментария (но, например, полифилл для кастом стейт в конце добавить почему-то предложил), поэтому давайте плодить множество data-атрибутов и кастомных тегов. О возможных подводных камнях, которые имеются, не написал ничего. При том решил ли автор поставленного им же вопроса? Большая часть опции в виде close/open, loading/loaded и прочие обычно управляются переменными состояния и, если они неправильно перетирают друг-друга, то решать вопрос нужно совершенно иначе и в самом коде логики. Остальная малая часть опции, если правится руками, требует банальной проверки результата (в идеале скриншоты тесты, конечно), причем это потребуется даже в случае с предложенным автором решениями, поскольку и в атрибутах, и в тегах, можно также легко накосячить.
Затрется, а если затрется как раз правильный атрибут?
Вы слишком многое ожидаете от автора статьи. Человек ткнул в известный факт и сделал из этого целую статью, но не объяснил в чем конкретно присутствуют проблемы и как мы в этом оказались. Не объяснил про трекеры, рекламу, аналитику, лишние библиотеки, стили в js и медленное перетекание логики сервера на фронт, а также многое другое. Исходя из этого можно сделать вывод, что автор возможно сам не имеет представления о происходящем и в оптимизации особых знаний не имеет.