Внедрение компонентого подхода в вебе: обзор веб-компонентов

Четыре из пяти самых запрашиваемых новых платформенных возможностей Edge на User Voice (Shadow DOM, Template, Custom Elements, HTML Imports) относятся к семейству API, называемых веб-компонентами (Web Components). В этой статье мы хотим рассказать о веб-компонентах и нашем взгляде на них, некоторой внутренней кухне, для тех, кто еще с ними не знаком, а также порассуждать на тему того, куда все это может эволюционировать в будущем. Это довольно-таки длинный рассказ, поэтому откиньтесь назад, возьмите кофе (или не кофеиновый напиток) и начинайте читать.

Содержание:

• Внедрение компонентов: старая практика проектирования, ставшая новой для веба
• Как разбивать на компоненты
• Это все не в первый раз: предыдущие подходы к внедрению компонентов
• Современные веб-компоненты
• Веб-компоненты: следующее поколение

Внедрение компонентов: старая практика проектирования, ставшая новой для веба

Современные веб-приложения столь же сложны, как и любые другие программные приложения, и зачастую создаются несколькими людьми, объединяющими усилия для создания финального продукта. В таких условиях, чтобы повысить эффективность, естественно искать правильные способы разделения работы на участки с минимальными пересечениями между людьми и подсистемами. Внедрение компонентного подхода (в целом) — это то, как обычно решается такая задача. Любая компонентная система должна уменьшать общую сложность через предоставление изоляции, или естественных барьеров, скрывающих сложность одних систем от других. Хорошая изоляция также облегчает повторное использование и внедрение сервисных парадигм.

Изначально сложность веб-приложений в основном регулировалась со стороны сервера за счет разделения приложения на отдельные страницы, что требовало от пользователя соответствующим образом переходить в браузере с одной страницы на другую. С внедрением AJAX и связанных технологий разработчики смогли отказаться от потребности делать «переходы» между разными страницами веб-приложения. Для типичных сценариев вроде чтения почты или новостей ожидания пользователей изменились. К примеру, после логина в почту, вы можете «пользоваться почтовым приложением» с одного и того же адреса (URL) и находится на этой странице целый день (т.н. Single-Page Applications, SPA). Логика клиентских веб-приложений в таких ситуациях существенно усложняется, иногда она даже становится сложнее, чем на серверной стороне. Возможным разрешением данной сложности может являться дальнейшее разделение на компоненты и изоляция логики внутри одной страницы или документа.

Цель веб-компонентов в уменьшении сложности за счет изоляции связанных групп кода на HTML, CSS и JavaScript для выполнения общей функциональности в пределах контекста одной страницы.

Как разбивать на компоненты?

Так как веб-компоненты должны связать воедино HTML, CSS и JavaScript, необходимо учитывать существующие модели изоляции, присущие каждой из технологий, так как они влияют на сценарии и целостность веб-компонентов. Эти независимые модели изоляции включают:

• Изоляция стилей в CSS
• JavaScript и области видимости (замыкания)
• Изоляция глобального объекта
• Инкапсуляция элементов (iframe)

Изоляция стилей в CSS

В рамках сегодняшней платформы не существует идеального и естественного способа разбить CSS на компоненты (хотя инструменты вроде Sass могут существенно помочь). Компонентная модель должна предлагать механизм для изоляции одного подмножества CSS от другого так, что правила не будут влиять друг на друга. К тому же, стили компонента должны применяться только к непосредственным частям компонента и более ни к чему другому. Легче сказать, чем сделать!

Внутри таблиц стилей CSS-правила применяются к документу, используя селекторы. Селекторы всегда рассматриваются как потенциально применимые ко всему документу, поэтому их область применения, в сущности, глобальная. Глобальное применение приводит к реальным конфликтам, когда несколько человек, работающих над проектом, смешивают вместе свои CSS-файлы. C пересечениями и повторениями селекторов можно бороться в четком порядке (например, каскады, специфичность, порядок следования исходников) для разрешения конфликтов, однако, такие действия, вполне вероятно, — совсем не то, чего хотели разработчики. Есть много потенциальных способов решения этой проблемы. Простое решение — перенести элементы и связанные стили, участвующие в формировании компонента из основного документа в другой документ (теневой документ) так, что они больше не будут «реагировать» на чужие селекторы. Это приводит ко второй проблеме: теперь, когда мы их разграничили, как некоторый стиль может пересечь границу (для управления снаружи компонента)? Очевидное возможное решение — это явно использовать JavaScript, но это выглядит как-то ужасно: полагаться на JavaScript для передачи стилей через границу, что кажется скорее пробелом в CSS.

Чтобы передать стили через границу компонента эффективным образом и при этом защитить структуру компонента (например, разрешить свободу изменения структуры без влияния стилей), существует два общих подхода, к которым многие склоняются: «частичная» стилизация с использованием псевдо-элементов и кастомные свойства (ранее известные как «переменные» CSS). Какое-то время также рассматривался супер-мощный кросс-граничный селектор '>>>' (определен в CSS Scoping), но сегодня он общепризнан не самой удачной идеей, так как легко нарушает изоляцию компонентов.

Частичная стилизация позволит авторам компонента создавать собственные псевдо-элементы для стилизации, таким образом, выставляя наружу внешнему миру только часть своей внутренней структуры. Это похоже на модель, которую браузеры используют для выставления «частей» нативных элементов управления. Для целостности данного сценария авторам также понадобится некоторый способ ограничения набора стилей, которые могут применять к псевдо-элементу. Дополнительное исследование этой «частичной модели», базирующейся на пcевдо-элементах, может привести к появлению удобных стилистических примитивов, хотя проработка деталей еще потребует усилий. Дальнейшая работа над частичной моделью также должна рационализировать стилизацию родных элементов управления в браузерах (область, которая явно нуждается во внимании).

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

Из всех рассматриваемых на сегодня подходов для стилизации будущая «частичная» модель и текущая спецификация кастомных свойств, кажется, имеют наибольшие шансы реализации. Мы рассматриваем кастомные свойства в качестве нового ключевого члена семейства спецификаций веб-компонентов.

Другие подходы к изоляции CSS стилей

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

CSS предлагает некоторые ограниченные формы изоляции селекторов в специфичных сценариях. Например, правило @‍media группирует набор селекторов вместе и применяет их при наступлении условий, соответствующих медиа-контексту (например, размер или разрешение вьюпорта, или медиа-тип — печать и т.п.); правило @‍page определяет некоторые стили, которые применимы только в контексте печати; правило @‍supports объединяет вместе селекторы для применения только, когда реализована поддержка специфичной CSS-функциональности — новая форма определения наличия функциональности в CSS); предложенное правило @‍document группирует селекторы для применения только тогда, когда документ, в котором загружены стили, соответствует условиям.

Области видимости в CSS (изначально написанные как часть работы над веб-компонентами) предлагают способ ограничивать применимость CSS-селекторов внутри одного HTML-документа. Спецификация вводит новое правило @‍scope, которое позволяет селектору определить корень(и) области применения и далее приводит к тому, что применение всех селекторов внутри правила @‍scope будет работать только в поддереве этого корны (а не на всем документе). Спецификация позволяет указывать корень области декларативно в HTML (например, предложен <style scoped> атрибут, пока реализованный только в Firefox; эта функциональность ранее была доступна в Chrome в качестве экспериментальной, но после была целиком удалена). Некоторые аспекты этой функциональности (к примеру, :scope, определенный в Selectors L4) также могут применяться для относительной оценки селекторов в новом API запросов в спецификации DOM.

Тут важно отметить, что @‍scope устанавливает только одно-направленную изоляцию границ: селекторы, содержащиеся внутри @‍scope, ограничены этой областью, в то время как любые другие селекторы (вне @‍scope) могут спокойной проникать внутри @‍scope (хотя они могут быть по-разному упорядоченным каскадом стилей). Это несколько неудачный дизайн, так как он не предоставляет ограничения области и изоляции от любых стилей, которые не находятся в подмножестве @‍scope — весь CSS должен по-прежнему «хорошо стыковаться», чтобы избежать стилизации внутри чужого правила @‍scope. См. также набросок @‍in-shafow-of от Таба, который лучше согласован с моделью защиты изоляции компонентов.

Другое предложение ограничения видимости — это сдерживания в CSS. Сдерживание области видимости — это в меньшей степени про изоляцию стилей и селекторов и в большей про изоляцию «композиции». Внутри свойства «contain» поведение некоторых возможностей CSS, которые имеют естественное наследование (в смысле применимости от родительского к дочернему элементу в документе, например, счетчики) будет блокировано. Основное применение этого для разработчиков состоит в том, чтобы указать, что некоторые элементы предполагают строгое «сдерживание», так что композиция, применимая к этому элементу и его поддереву никогда не будет затрагивать композицию других элементов документа. Эти обещания сдерживания (указываемые применением свойства «contain») позволяют браузерам оптимизировать композицию и отрисовку так, что «новая» композиция удерживаемого поддерева потребует только обновления этого поддерева, а не всего документа.

По мере того, как реализации технологий для веб-компонентов взрослеют среди браузеров и находят все больше публичного применения, дополнительные паттерны стилизации и проблемы могут появиться; мы ожидаем дальнейших инвестиций и последующего прогресса в различных предложениях в CSS для улучшения стилизации веб-компонентов.

JavaScript и области видимости

Весь JavaScript-код, который включен на страницу, имеет доступ к одному и тому же глобальному объекту. Как и другие языки программирования, JavaScript имеет области видимости, которые предоставляют некоторый уровень «приватности» для кода функции. Эти лексические области видимости используются для изоляции переменных и функций от остального глобального окружения. «Модульный шаблон» в JavaScript, популярный сегодня (использующий лексические области видимости), эволюционировал из потребности множества фреймворков на JavaScript «сосуществовать» в едином глобальном окружении без того, чтобы «наступать на пятки» друг другу (завися при этом от порядка загрузки).

Лексические области видимости в JavaScript – это однонаправленная изоляция границ: код внутри области может иметь доступ как ко внутреннему содержимому, так и к содержимому любой родительской области вплоть до глобальной, в то время как код снаружи области не имеет доступа к ее содержимому. Важным принципом является то, что однонаправленный способ изоляции отдает предпочтение коду внутри области, то есть защищает его. Код внутри лексической области имеет возможность защищать/прятать себя от остального окружения (или не делать этого).

Вклад, который лексические области видимости JavaScript вносят в реализацию веб-компонента, соответствует требованию иметь способ «закрытия» компонента так, что ее содержимое может быть разумно приватным.

Изоляция глобального объекта

Для некоторого кода может быть нежелательным, чтобы он имел общий доступ к глобальному окружению, как это было описано выше. К примеру, разработчик приложения может не доверять какому-то коду на JavaScript, хотя он и предоставляет существенную ценность. Характерный случай – реклама и рекламные фреймворки. Из соображений безопасности, необходимо, чтобы не доверенный код выполнялся в отдельном чистом скриптовом окружении (со своим собственным глобальным объектом). Чтобы достичь такого поведения сегодня (без включения в игру iframe элементов), разработчики могут использовать воркеры. Впрочем, недостаток этого решения в том, что воркеры не имеют доступа к элементам, то есть UI.

Есть ряд соображений, которые нужно учитывать при проектировании компонентов с поддержкой изоляции глобального объекта – особенно если изоляция будет подразумевать защищенные границы (подробнее ниже). На сегодня мы ожидаем, что изолированные компоненты не будут полностью доступны до тех пор, пока базовый набор спецификаций веб-компонентов не будет зафиксирован (то есть, это «отложено до следующей версии»). Однако, если мы потратим некоторое время на исследование того, как изолированные компоненты могут выглядеть, это может направить в правильное русло текущую работу. На некоторые предложения действительно стоит обратить внимание.

Изоляция глобального объекта – это важный нереализованный сценарий для веб-компонентов. А пока мы работаем над реализацией, можно, например, полагаться на самый успешный и распространенный на сегодня способ привнесения компонентности в веб: iframe-элемент.

Инкапсуляция элементов (iframe)

Iframe-элементы и их близкие родственники: элементы object, frameset и императивный API windows.open() – уже предоставляют возможность работать в изолированным поддеревом элементов. Однако, если компоненты подразумевают работу внутри одного документа, iframe включает внутри себя целый HTML-документ; как если бы два отдельных веб-приложения были размещены совместно, просто одно внутри другого. У каждого уникальные адрес документа, глобальное окружение для скриптов и область видимости CSS; каждый документ полностью отделен от другого.

Iframe – это на сегодня самая успешная (и единственная широко внедренная) форма компонентизации в вебе. Iframe позволяет осуществлять взаимодействие различных веб-приложений. Например, многие сайты используют iframe именно как форму компонента для всевозможных сценариев от рекламы до логина пользователей. Однако iframe столкнулся с рядом вызовов и появились некоторые способы с этими вызовами бороться:

• JavaScript-код внутри одно HTML документа может потенциально вторгнуться в границы изоляции другого документы (например, через свойство contentWindows у iframe элемента). Такая возможность нарушения границы может быть необходимой потребностью, но она также представляет собой риск с точки зрения безопасности, когда содержимое iframe содержит чувствительную информацию, которой не хотелось бы делиться. Сегодня нежелательные нарушения могут регулироваться политиками общего источника: документы с URL из одного источника могут нарушать границы по умолчанию, в то время, как документы из разных источников имеют ограниченные возможности взаимодействия друг с другом.
• Нарушение границы – это не единственный риск безопасности. Использование атрибута <iframe sandbox> накладывает дальнейшие ограничения на iframe из других источников с тем, чтобы защитить хост-окружение от нежелательных скриптов, всплывающих окон, изменения навигации и других возможностей, доступных в iframe.
• CSS-стили внешнего документы не могут применяться к внутреннему документу. Такое архитектурное решение следует принципу изоляции. Однако изоляция стилей создает существенный пробел в интеграции iframe в качестве компонента (в рамках общего источника происхождения). HTML адресует эту проблему с помощью предложенного атрибута <iframe seamless> для iframe с общим источником. Такой атрибут «бесшовности» удаляет изоляцию стилей контента фрейма; бесшовно включенные документы берут копию стилей хостового документа и отображаются, как если бы их ограничений iframe-элемента, в который они включены, не было.

С хорошими политиками безопасности и возможность вставлять фрейм бесшовно, использование iframe в качестве модели для компонентов кажется весьма привлекательным решением. Однако нескольких свойств желательных в модели веб-компонентов все же не хватает:

• Глубокая интеграция. Iframe ограничивает (и в основном полностью отключает) интеграцию и взаимодействие моделей между хостом и фреймовым документом. К примеру, относительно хоста: фокус и модель выделения независима, а передача событий изолирована одним или другим документом. Для компонентов, которые предполагают более близкую интеграцию, поддержка такого поведения не возможная без внедрения некоторого «агента» в хостовом документе, который бы пробрасывал сведения через границу.
• Размножение глобальных объектов. Для каждой сущности iframe, созданной на странице, будет присутствовать уникальный глобальный объект. Глобальный объект и связанная с ним полная система типов не дешева в создании и может привести к потреблению большого количества памяти и чрезмерной нагрузки на браузер. Множественные копии одного и того же компонента, используемые на одной странице, не обязательно должны быть изолированы друг от друга, на практике наличие общего глобального объекта может быть желательно, особенно, если они должны поддерживать некоторое общее состояние.
• Модель использования контента хоста. Iframe не позволяет повторного использования контентной модели хост-элемента внутри фреймового документа. (Для простоты: контентная модель элемента – это его поддерживаемое поддерево элементов и текста.) К примеру, select-элементы имеет контентную модель, включающую option-элементы. Select-элемент, реализованный в виде компонента, захочет некоторым образом взаимодействовать с дочерними элементами.
• Выборочная стилизация. Бесшовный iframe не работает с документами из разных источников. Есть явные риски безопасности, если бы это было разрешено. Основная проблема в том, что «бесшовность» контролируется хостом, а не фреймовым документом (фреймовый документ чащей является жертвой атак). Для компонента двузначная возможность включения «бесшовности» (есть или нет) может быть слишком дорогостоящей; компоненты скорее хотели бы выборочно принимать решение, какие стили от хоста применимы к их содержимому (вместо автоматического наследования всех стилей, то есть это то, как работает бесшовность). В целом, вопрос, что должно стилизоваться, должен разрешаться самим компонентом.
• Выставление API. Многие сценарии для веб-компонентов подразумевают создание полноценных кастомных элементов с собственными выставленным набором API, семантикой отображения и управлением жизненным циклом. Использование iframe ограничивает разработчика до работы в рамках API iframe, со всем его особенностями. К примеру, вы не можете влиять на параметры самого iframe и его жизненный цикл.

Это все не в первый раз

Не можем не отметить, что в прошлом несколько технологий уже было предложено и даже внедрено в попытке улучшить работе iframe в HTML и связанные возможности инкапсуляции. Впрочем, ни одна из них не прижилась в значительной степени в современном вебе:

• HTML Компоненты (1998) были предложены и внедрены Microsoft, начиная с IE5.5 (устарели в IE10). Предполагалось использование декларативной модели для добавления событий и API к хост-элементу (с учетом изоляции) и парсинга компонентов в некоторый “viewlink” (как “теневой DOM”). Были доступны два типа поведения компонентов: одно временно присоединялось к элементу, другое динамично привязывалось через CSS-свойство “behavior”.
• XBL (2001) и его наследник XBL2 (2007) были предложены Mozilla как дополнение к из языку XUL для описания интерфейсов. Это декларативный язык с двумя возможностями связывания (похоже на HTML Компоненты от Microsoft), XBL также поддерживал дополнительные возможности доступа к контентной модели хоста и генерации контента.

Современные веб-компоненты

После провала первых двух попыток, пришло время попробовать запустить игру в компоненты снова, на этот раз делом занялся Google. Используя концепции, описанные в XBL в качестве стартовой точки, монолитная компонентная система была разбита на коллекцию строительных блоков для компонентов. Эти строительные блоки позволили веб-разработчикам экспериментировать с отдельными полезными возможностями до того, как общее видение для веб-компоненты будет полностью определено. Компонентность самого подхода и разработка отдельных полезных возможностей позволили продвинуться ближе к успеху. Практически каждый может найти в веб-компонентах что-то полезное для своего приложения!

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

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

Первое поколение веб-компонентов включает:

• Кастомные элементы (Custom Elements). Кастомные элементы определяют точку расширения HTML-парсера, чтобы он мог распознавать имена новых «кастомных элементов» и предоставить им автоматически необходимую объектную модель на JavaScript. Кастомные элементы не создают границ компонентов, но зато предоставляют браузеру способ присоединять API и поведения к авторским элементам. Браузеры, не поддерживающие кастомные элементы, могут их симулировать (через полифилы) с некоторой точностью, используя события и наблюдатели за изменениями и подстраивая прототип. Правильное планирование и понимание последствий – это ключевой элемент наших предстоящих встреч.
• • Аттрибут “is”. Он спрятан внутри спецификации кастомных элементов, но предоставляет критичную функциональность – возможность указать, что встроенный элемент должен получить имя кастомного элементы и новые API. В обычном случае кастомный элемент имеет в основе некий общий элемент; с помощью “is” за основу может быть взять нативный элемент (например, <input is=”custom-input”>). Хотя эта функциональность представляет отличный способ унаследовать преимущества от встроенного рендеринга, доступности, парсинга и т.п., синтаксис этой функциональности воспринимается скорее как хак, и есть мнение, что, возможно, примитивы для доступности и стилазация нативных элементов – это более подходящий в долгосрочном плане путь стандартизации.
• Теневой DOM (Shadow DOM). Предоставляет императивный API для создания отдельного дерева элемента, которое может быть подсоединено (одноразово) к хост-элементу. Такие «теневые» потомки заменяют «реальных» потомков при отображении документа. Теневой DOM также предоставляет механизм использования контентной модели хост-элементы, используя новые slot-элементы (предложенные недавно), решает задачу с целевым элементом у событий и добавляет открытые/закрытые режимы операций (также недавно добавленные). Эта относительно тривиальная идея имеет удивительно большое количество сторонних эффектов во всем, начиная с модели фокуса и выделения и заканчивая композицией и распространения (для теневого DOM внутри теневых DOM).
• • Области видимости CSS определяют различные псевдо-элементы, релевантные стилизации теневого DOM, включая :host, ::content (скоро, возможно, станет ::slot), и бывший “>>>” (пронизывающий комбинатор теневого DOM), который теперь официально дезавуирован.
• Template элемент. Он включен для полноты картины, эта функциональность ранее была частью веб-компонентов, а сейчас является частью рекомендации HTML5. Шаблонный элемент вносит концепцию инертности (дочерние элементы шаблона не приводят к загрузке ресурсов, не реагируют на пользовательский ввод и т.п.). Это способ декларативно создать в HTML несвязаннное поддерево элемента. Шаблон может использоваться для разных задач: от собственно образцов шаблонов и связывания данных до предоставления контента для теневого DOM.
• HTML Imports. Определяет декларативный синтаксис для «импорта» (запрос, загрузка или парсинг) HTML в документ. Запросы на импорт (используя link-элемент с rel=”import”) выполняют скрипты импортируемого документа в контексте хостовой страницы (таким образом, имея доступ к тому же глобальному объекту и состоянию). HTML, JavaScript и CSS части веб-компонента могут, соответственно, быть загружены одним использованием импорта.
• Кастомные свойства. Как описано детальнее выше, кастомные свойства, описанные вне компонента и доступные для использования внутри компонента – это простая и удобная модель для стилизации компонентов сегодня. Учитывая это, мы включили кастомные свойства в первое поколение технологий для веб-компонентов.

Веб-компоненты: следующее поколение

Как мы отметили в начале данной статьи, построить полнофункциональные веб-компоненты – это большое приключение. Несколько идей для развития и заполнения пробелов в текущем поколении возможностей уже начало циркулировать среди разработчиков (это не полный список!):

• Декларативный теневой DOM. Он становится важным, когда вы задумываетесь, как передавать компоненты в сериализованном виде. Без декларативной формы, техники вроде innerHTML или XMLSerializer не смогут построить строкового представления DOM, включающего любой теневой контент. Другими словами, теневой DOM сегодня не может конвертироваться в строку и обратно без помощи скрипта. Anne из Mozilla предложил <shadowdom> элемент в качестве темы для обсуждения. Аналогично template-элемент уже является декларативным способом построения «теневой» разметки и методы сериализации в браузере уже подстроились под учет этой возможности и, соответственно, сериализуют «теневой» контент шаблона правильным образом.
• Полностью изолированные компоненты. Три производителя браузеров сделали три разные предложения в этой области. Эти предложения уже достаточно хорошо согласованы, что является хорошей новостью с точки зрения достижения консенсуса. Как упоминалось ранее, изолированные компоненты будут использовать новые глобальные объекты и смогут быть импортированы из других источников. Они также будут иметь разумную модель для выставления API и связанных поведений через свою границу изоляции.
• Примитивы доступности. Многие сообщества обеспечения доступности симпатизируют идее “is” (из кастомных элементов) в качестве способа расширения существующих нативных элементов, так как они уже содержат механизмы обеспечения доступности, не всегда доступные JavaScript-разработчикам. В идеале, обычные веб-компоненты (без использования “is”) могли бы включать аспекты доступности практически также, как и нативные элементы, среди прочего, включая отправку форм и возможность фокусировки. Такие точки расширения не возможны сегодня, но должны быть проработаны и определены.
• Единая стилизация нативных элементов управления. Пробел в наличии модели стилизации элементов управления консистентной между браузерами является проблемой интероперабельности, мешающей, например, распространению простых расширений «изменения темы». Это приводит к тому, что разработчики зачастую рассматривают теневой DOM как альтернативное решение (хотя создание разметки в теневом DOM с поведением аналогичным таковому у нативных элементов, может быть нетривиальным). Некоторые идеи стилизации элементов управления гуляют в CSS-сообществе, хотя без большого спроса они не имеют нужной скорости в проработке.
• Частичная стилизация CSS. Хотя кастомные свойства CSS могут предоставить широкий набор опций для стилизации веб-компонентов, существуют дополнительные сценарии, в которых выставление для стилизации некоторых блоков, зашитых внутри компонентов, должно быть более прямым и сделано более подходящим способом. Это будет особенно удобно, если также рационализирует подход, которые существующие браузеры используют для выставления частичной стилизации нативных элементов управления.
• Кастомизация парсера. Когда кастомные элементы используются, только стандартные теги открытия и закрытия могут использоваться для парсинга таких элементов. В некоторых сценариях может быть желательным разрешить дополнительные опции для парсера веб-компонентов.

Наконец, хотя это и не считается официально частью веб-компонентов, старый добрый iframe не должен списываться со счетов. Как обсуждалось, iframe – это все еще очень часто используемая функциональность веб-платформы, подходящая для создания сущностей, похожих на компоненты. Было бы полезным понять и потенциально улучшить «компонентную» историю iframe. К примеру, дальнейшее изучение и адресация проблем с <iframe seamless> кажется хорошей темой для начала дискуссии.

Веб-компоненты – это поворотный моменты для веба. Мы рады продолжать поддерживать и вносить свой вклад в это приключение. Делитесь вашим мнением с нами в твиттере @msedgedev.