Поддерживаю. Пусть решение с iframe не всегда удобно использовать, т.к. оно наследует все сложности работы с ними (которые при желании решаемы), но оно позволяет инкапсулировать стили и DOM в рамках одного элемента уже сегодня.

Все правильно, их инициативу никто тогда не поддержал. Идея опережала свое время.

Вообще Microsoft поддерживала создание кастомных тэгов с начиная с Internet Explorer 5, хотя в 10 версии эта поддержка была удалена из браузера.

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

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

> Что вы имеете ввиду под стандартизацией кастомных тегов?
Представьте ситуацию когда любой уважающий себя разработчик будет создавать кастомный тэг для табов. Если брать HTML5, например, там есть спека в которой четко описано что делает тэг, какие у него могуть быть дочерние элементы и т.д. И это очень здорово, т.к. у нас есть набор тэгов которые все одинаково понимают. С кастомными тэгами такого не будет. По сути <my-tabs/> будет эквивалентен <ul class="my-tabs"/>. Поэтому в плане ускорения стандартизации никаких значительных плюсов у кастомных тэгов нет перед теперешним подходом создания виджетов.

> Содержимое тегов парсится браузером, но не вызывает выполнение скриптов

Вообще скрипты итак не выполняются при вставке с помощью innerHTML.

Web Components — интересная спецификация, но пока я вижу 3 проблемы:

1. отсутствие стандартизации у кастомных тегов
2. непонятно как будут обстоять дела у кастомных элементов с SEO
3. кроссбраузерная поддержка

Однако в некоторых случаях кастомные тэги — это то, что доктор прописал. Например, всякого рода кнопки like и +1 — очень хорошие кандидаты. Но повторяю — не везде их применение имеет смысл.

Не нужно продолжать, лучше перечитайте статью. Все ваши аргументы — это заблуждения, которые свидетельствуют, что вы не усвоили материал.

Еще раз повторю — better-dom не о кастомных тэгах, и в этом состоит основное различие подхода, который продвигается x-tags, polymer и т.д. Прочтите о декораторах (не custom tags) из Web Components по ссылке из статьи, они решают схожую проблему.

Я бы советовал вам получше посмотреть что такое mutation events и MutationObserver. Ни то, ни другое не позволяет эффективно отлавливать элементы по CSS селектору. Эти специификации не предназначены для этого.

Никто не любит хаков, и live extensions не занимаются продвижением уловки с @keyframes. Задача в том, чтобы начать использовать новую идею в реальных проектах, которая позволяет решать нетривиальные в прошлом задачи, и, соответвтвенно, мыслить другими категориями.

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

Live extensions работают с любыми элементами и поддерживают IE8+ и я уже сейчас многие проекты на его основе использую по принципу подключил и забыл (не надо ничего инициализировать).

добавив для лучшей производительности в селектор только определённые элементы и/или классы

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

Live extensions используют иной механизм навешивания событий. Если грубо, то можно воспринимать их как дешевый DOMNodeInserted. В отличие от live events селектор здесь влияет на количество происходящих событий. Поэтому они работают в тех случаях, когда live events использовать неэффективно.

По поводу SelectorListener: расширение прототипов нативных элементов браузеров — плохая практика.

better-dom не расширяет нативные прототипы (за исключением фиксов для старых IE).

Список, конечно, хороший, но начинать лучше с изучения существующих стандартов. Пункт 1, например, хорошо сделать для понимания как работает наследование в JavaScript. Но в ES6 появится стандартизированный синтаксис для объявления классов, поэтому через какое-то время «своя реализация классов» будет никому не нужной. Поэтому лучше инвестировать свое время на что-нибудь другое.

Изобретание велосипедов хорошо там, где пока еще нет стандартных решений либо они неудобные.

С пул реквестами не все так просто, потому что имеется уже много написанного кода.

Большинство проблем ниже не могут быть исправлены в jQuery без потери обратной совместимости.

Есть еще проблема конфликта имен. Например, в будущем в нативном DOM появятся find и findAll, т.е. это уже стандартизированные имена методов. В jQuery find по смыслу эквивалентен findAll. Стоит ли добавлять findFirst и тем самым запутывать людей еще больше? Много вопросов.