Что такое web components
Web Components — будущее Web
Спустя какое время стало ясно, что основная идея Prototype вошла в противоречие с миром. Создатели браузеров ответили на возрождение Javascript добавлением новых API, многие из которых конфликтовали с реализацией Prototype.
Код на стороне клиента становится сложнее и объёмнее. Появляются многочисленные фреймворки, которые помогают держать этот хаос под контролем. Backbone, ember, angular и другие создали, чтобы помочь писать чистый, модульный код. Фреймворки уровня приложения — это тренд. Его дух присутствует в JS среде уже какое-то время. Не удивительно, что создатели браузеров решили обратить на него внимание.
Web Components — это черновик набора стандартов. Его предложили и активно продвигают ребята из Google, но инициативу уже поддержали в Mozilla. И Microsoft. Шучу, Microsoft вообще не при делах. Мнения в комьюнити противоречивые (судя по комментариям, статьям и т.д.).
Основная идея в том, чтобы позволить программистам создавать “виджеты”. Фрагменты приложения, которые изолированы от документа, в который они встраиваются. Использовать виджет возможно как с помощью HTML, так и с помощью JS API.
Я пару недель игрался с новыми API и уверен, что в каком-то виде, рано или поздно эти возможности будут в браузерах. Хотя их реализация в Chrome Canary иногда ставила меня в тупик (меня, и сам Chrome Canary), Web Components кажется тем инструментом, которого мне не хватало.
Стандарт Web Components состоит из следующих частей:
Фрагменты HTML, которые программист собирается использовать в будущем.
Содержимое тегов парсится браузером, но не вызывает выполнение скриптов и загрузку дополнительных ресурсов (изображений, аудио…) пока мы не вставим его в документ.
Инструмент инкапсуляции HTML.
Импорт фрагментов разметки из других файлов.
В Web Components больше частей и маленьких деталей. Некоторые я ещё буду упоминать, до каких-то пока не добрался.
Templates
Концепция шаблонов проста. Хотя под этим словом в стандарте подразумевается не то, к чему мы привыкли.
В современных web-фреймворках шаблоны — это строки или фрагменты DOM, в которые мы подставляем данные перед тем как показать пользователю.
В web components шаблоны — это фрагменты DOM. Браузер парсит их содержимое, но не выполняет до тех пор, пока мы не вставим его в документ. То есть браузер не будет загружать картинки, аудио и видео, не будет выполнять скрипты.
К примеру, такой фрагмент разметки в документе не вызовет загрузку изображения.
Пример работы шаблонов можно посмотреть здесь.
Все примеры в статье следует смотреть в Chrome Canary со включенными флагами:
Для Чего?
На данный момент существует три способа работы с шаблонами:
Минусы такого подхода в том, что браузер попытается “выполнить” код шаблона. То есть загрузить картинки, выполнить код скриптов и т.д.
Минус в том, что приходится работать со строками. Это создаёт угрозу XSS, нужно уделять дополнительное внимание экранированию.
У нет этих недостатков. Мы работаем с DOM, не со строками. Когда выполнять код, также решать нам.
Shadow DOM
Инкапсуляция. Этого в работе с разметкой мне не хватало больше всего. Что такое Shadow DOM и как он работает проще понять на примере.
Когда мы используем html5 элемент код выглядит примерно так:
Но на странице это выглядит так:
Мы видим множество контролов, прогресбар, индикатор длины аудио. Откуда эти элементы и как до них добраться? Ответ — они находятся в Shadow Tree элемента. Мы можем даже увидеть их в DevTools, если захотим.
Чтобы Chrome в DevTools отображал содержимое Shadow DOM, в настройках DevTools, вкладка General, раздел Elements ставим галочку Show Shadow DOM.
Содержимое Shadow DOM тега в DevTools:
Теория Shadow DOM
Shadow Tree — это поддерево, которое прикреплено к элементу в документе. Элемент в этом случае называется shadow host, на его месте браузер показывает содержимое shadow tree, игнорируя содержимое самого элемента.
Фишка shadow dom в том, что стили, определённые в нём с помощью
Зелёный фон в примере получит только `
` внутри shadow tree. То
есть стили «не вытекут» в основной документ.
Наследуемые стили
Авторские стили
Селекторы ^ и ^^
Инкапсуляция это здорово, но если мы всё таки хотим добраться до shadow tree и изменить его представление из стилей документа, нам понадобится молоток. И кувалда.
Селектор div ^ p аналогичен div p с тем исключением, что он пересекает одну теневую границу (Shadow Boundary).
Селектор div ^^ p аналогичен предыдущему, но пересекает ЛЮБОЕ количество теневых границ.
Зачем нужен Shadow DOM?
Shadow DOM позволяет изменять внутреннее представление HTML элементов, оставляя внешнее представление неизменным.
Custom Elements
API кастомного элемента
Прототип должен наследовать HTMLElement или его наследника,
например HTMLButtonElement :
Зачем нужны Custom Elements?
или
- хорошо подходят для низкоуровневой вёрстки, тогда как Custom Elements позволят писать модульный, удобочитаемый код на высоком уровне.
Shadow DOM и Custom Elements дают возможность создавать независимые от контекста виджеты, с удобным API и инкапсулированным внутренним представлением.
HTML Imports
Импорты — простое API, которому давно место в браузерах. Они дают возможность вставлять в документ фрагменты разметки из других файлов.
Object.observe()
Этот метод доступен в Chrome, если включить флаг Experimental Web Platform features.
TODO widget
Согласно древней традиции, вооружившись этими знаниями, я решил сделать простой TODO-виджет. В нём используются части Web Components, о которых я рассказывал в статье.
Добавление виджета на страницу сводится к одному импорту и одному тегу в теле документа.
Заключение
На мой взгляд, Web Components — это следующий шаг. Разработчики смогут создавать интерактивные виджеты. Их легко поддерживать, переиспользовать, интегрировать.
Код страницы не будет выглядеть как набор “блоков”, “параграфов” и “списков”. Мы сможем использовать элементы вроде “меню”, “новостная лента”, “чат”.
Конечно, стандарт сыроват. К примеру, импорты работают не так хорошо, как шаблоны. Их использование рушило Chrome время от времени. Но объём нововведений поражает. Даже часть этих возможностей способна облегчить жизнь web-разработчикам. А некоторые заметно ускорят работу существующих фреймворков.
Некоторые части Web Components можно использовать уже сейчас с помощью полифилов. Polymer Project — это полноценный фреймворк уровня приложения, который использует Web Components.
Ссылки
Eric Bidelman, серия статей и видео о Web Components:
Веб-компоненты: обзор и использование в продакшне
Привет! Я использую веб-компоненты в разработке фронтэнда. В данной статье я опишу все возможности веб-компонентов, а также то, как их можно использовать сегодня с учётом пока ещё не высокой поддержки.
Кратко про веб-компоненты: это набор технологий, которые позволяют использовать компонентный подход с инкапсуляцией стилей и скриптов в вебе нативно, без подключения каких-либо библиотек или фейрмворков. Если вам интересно, что предлагают стандарты вместо привычных уже React или Angular, и как это использовать при разработке под старые браузеры, прошу под кат.
Список материалов для детального изучения — в конце статьи.
Вступление
Я работаю фронтэнд-разработчиком сервисов в одной из крупных международных кампаний и в настоящий момент второй раз переписываю фронтэнд проекта.
В первой версии, написанной согласно канонам 1C-Bitrix, меня ожидало мясо из скриптов и стилей во множестве шаблонов. Скрипты, конечно, были на jQuery, а стили, разумеется, были абсолютно хаотичны, без какой-либо структуры или порядка. В связи с переездом на новую платформу выпал шанс полностью переписать проект. Для наведения порядка была разработана своя компонентная система с использованием БЭМ-методологии. На каждый экземпляр БЭМ-блока в разметке после загрузки страницы создаётся один объект соответствующего класса, который начинает управлять логикой. Таким образом, всё довольно строго систематизировано — блоки (логика и стили) реиспользуемы и изолированы друг от друга.
По прошествии года поддержки и доработки проекта обнаружился ряд недостатков такой системы. Разметка, на основе которой работают мои псевдокомпоненты, держится на внимательности и «честном слове» разработчика: JS надеется, что верстальщик правильно расставил все нужные элементы и прописал к ним классы. Если компонент модифицирует свой DOM, который содержит другие БЭМ-блоки, либо же разметка подгружается через ajax, компоненты этой разметки приходится инициализировать вручную. Это всё казалось простым при ежедневной работе до тех пор, пока на проекте не появился второй человек. Документация, к сожалению, хоть и была довольно объёмной, но охватывала только базовые принципы (объём в данном случае стал минусом). В жизни же шаг влево или шаг вправо ломал установленные «принципы», а чтение готовых компонентов только вносили сумбур, так как они были написаны по разному и в разное время.
Всё это, а также потенциальное увеличение количества проблем в разработке при запланированном переходе к SPA/PWA подтолкнули к очередной переработке фронта. Велосипеды, которым, в том числе, является моя компонентная система, очень полезны во время обучения чему-либо (в моём случае — JS), но в качественном проекте с несколькими разработчиками необходимо что-то более надёжное и структурированное. В настоящее время (впрочем, уже давно) в вебе мы имеем массу фреймворков, среди которых есть, что выбрать: Preact предлагает маленький размер и максимальное сходство в разработке с уже знакомым мне React-ом, Angular манит встроенным прелестным TypeScript-ом, Vue выглядывает из-за угла и хвастается своей простотой, и много другого. Особняком держится стандарт: оказывается, можно писать реиспользуемые веб-компоненты, с зашитой внутри логикой и стилями, которые не надо будет искусственно (за счёт БЭМ и дополнительного JS-а) связывать с уже написанной разметкой. И всё это должно работать из коробки. Чудо, не правда ли?
Из-за моей дикой любви к стандартам и вере в светлое будущее, а также схожести имеющейся системы компонентов с веб-компонентами (один JS-класс на один «компонент» с изолированной логикой), решено было попробовать использовать именно веб-компоненты. Больше всего напрягала поддержка этого дела в браузерах: веб-компоненты слишком молоды, чтобы охватывать сколько-нибудь широкий круг браузеров, а уж тем более охватывать браузеры, которые необходимо поддерживать коммерческому продукту (например, Android 4.4 stock browser и Internet Explorer 11). Мысленно был принят некоторый уровень боли и ограничений, который могли меня ожидать, и рамок, в которые я согласен вписываться при разработке, и я погрузился в изучение теории и практические эксперименты: как писать фронт на веб-компонентах и выкатывать это в продакшн так, чтобы оно работало.
Необходимый теоретический минимум для чтения статьи: чистый JavaScript на уровне базовых манипуляций с DOM-деревом, понимание синтаксиса классов в ES2015, плюсом будет знакомство с каким-либо из фреймворков из разряда React.js/Angular/Vue.js.
Теория
Обзор
Веб-компоненты — это совокупность стандартов, которые позволяют делать декларативно описываемые, реиспользуемые «виджеты» с изолированными стилями и скриптами в виде собственных тегов. Стандарты развиваются независимо, и связываются в веб-компоненты довольно условно — в принципе, можно использовать каждую из используемых технологий отдельно. Но именно вместе они максимально эффективны.
Обычно все четыре стандарта — пользовательские элементы (Custom Elements), теневой DOM (Shadow DOM), шаблоны (HTML Templates) и HTML-импорты (HTML Imports) — рассматриваются отдельно, а уже потом соединяются вместе. Так как по отдельности они слабо полезны, мы рассмотрим все возможности стандартов кумулятивно, прибавляя их к уже изученному ранее.
Пользовательские элементы (Custom Elements)
Регистрация пользовательского элемента
Конечно, мы и так можем «создать» собственный теги (например, браузеры вполне корректно обработают тег ), но при этом в DOM-дереве элемент регистрируется как объект класса HTMLUnknownElement и не имеет никакого поведения по умолчанию. «Оживлять» каждый такой элемент придётся вручную.
Если попытаться зарегистрировать элемент с уже зарегистрированным именем или на основе уже зарегистрированного класса, мы получим исключение.
Имя тега и имя класса совсем не обязательно должны совпадать. Поэтому мы можем при необходимости зарегистрировать два пользовательских элемента с одинаковым именем класса под разными тегами.
Теперь пользовательский элемент, конечно, зарегистрирован, но ничего полезного он не делает. Чтобы действительно оживить наш пользовательский элемент, рассмотрим его жизненный цикл.
Жизненный цикл пользовательского элемента
Мы можем добавить методы-коллбэки на создание элемента, добавление его в DOM, на изменение атрибутов, на удаление элемента из DOM и на изменение родительского документа. Мы воспользуемся этим, чтобы реализовать логику работы спойлера: компонент будет содержать кнопку с текстом «Свернуть»/«Развернуть» и секцию с изначальным содержимым тега. Видимость секции будет управляться кликом по кнопке или значением атрибута. Текст кнопок также можно будет настроить через атрибуты.
Подробно разберём каждую часть конструктора.
this.text — так как this это объект, мы можем добавить и свои свойства. В данном случае я буду хранить в объекте text вспомогательные тексты, которые выводятся на кнопке.
this.innerHTML установит разметку нашего DOM-элемента. При этом мы используем текст, заданный чуть выше.
Для строковых свойств (как для встроенных id у любых элементов и href у ссылок) геттер и сеттер будут выглядеть немного проще, но идея сохраняется.
Можно ещё добавить, что такое «отражение» может быть не всегда полезным с точки зрения производительности. Например, у элементов формы атрибут value работает иначе.
Теперь у нас есть атрибут, он может менять свое значение при клике по кнопке, но больше никакого полезного действия не происходит. Мы могли бы добавить полезный код по скрытию и отображению элемента прямо в обработчик клика, но тогда было бы очень проблемно изменить видимость элемента, например, другим, внешним JS-кодом.
Метод применяет три параметра: имя атрибута, старое значение, новое значение. Так как вызывать этот метод на изменение абсолютно ВСЕХ атрибутов было бы нерационально с точки зрения производительности, срабатывает он только при изменении свойств, которые перечислены в статическом массиве observedAttributes текущего класса.
Основной функционал готов, это самые часто используемые возможности пользовательских элементов. Теперь рассмотрим те коллбэки, которые используются реже.
Взаимодействие с пользовательским элементом
Теперь мы можем прослушивать интересующие нас события, чтобы узнавать об изменении состояния спойлера.
Ещё немного о customElements
Расширение пользовательских элементов
Расширение стандартных элементов
Во-вторых, при регистрации элемента третьим параметром необходимо передать объект опций, в котором указывается, какой именно тег вы хотите расширить (нескольким тегам может соответствовать один и тот же класс).
Выглядеть это будет так:
Стилизация элементов до регистрации
Итого
Теневой DOM (Shadow DOM)
Спецификация теневого DOM позволит решить проблемы с изоляцией стилей и разметки от окружения и внутреннего содержимого.
Инкапсуляция DOM
До момента регистрации элемента пользователь будет видеть обычный DOM, т.е. в нашем случае текст «Привет!». Но как только элемент будет зарегистрирован, текст пропадёт, вместо него появится фраза «Привет из тени. ».
Теперь мы можем безопасно менять текст спойлера, например, через textContent пользовательского элемента. Наша разметка инкапсулирована и никак не мешает работать с содержимым элемента. Разработчику не нужно знать, как устроен элемент изнутри, чтобы работать с ним. Демо.
Рассмотрим пример посложнее: это будет искусственный пример, который будет раскидывать по четырём цветным «коробкам» разных цветов DOM-элементы из Light DOM. Можете попробовать поменять содержимое тега, чтобы посмотреть, как оно работает: демо.
Инкапсуляция стилей
С изоляцией DOM и соотношением Light DOM / Shadow DOM вроде разобрались, теперь поговорим об изоляции стилей.
В последнем примере я уже начал использовать изоляцию стилей. Если в Shadow DOM находится тег
Вероятно, вам нужно предоставить какую-то возможность по стилизации вашего пользовательского элемента снаружи, помимо предустановленных через :host и :host-context стилей.
Для управления элементами в Shadow DOM можно использовать пользовательские свойства CSS, если, конечно, вы поддерживаете только те браузеры, которые позволяют использовать пользовательские свойства.
Взаимодействие с теневым DOM
Доступ к теневому DOM открыт любому JavaScript-коду при условии, что теневой DOM был добавлен с опцией
Что ещё?
Шаблоны (HTML Templates)
Наш компонент спойлера уже сейчас довольно хорош, но его можно улучшить с помощью спецификации шаблонов HTML.
В текущий момент разметка Shadow DOM хранится прямо в конструкторе. Веб-компоненты не приветствуют такой путь, в частности потому что установка innerHTML для каждого компонента является довольно трудозатратной операцией, а также из-за принципа разделения сущностей.
Выглядит довольно громоздко, но — работает. Самый главный минус — мы вынуждены подключать ещё один файл даже тогда, когда он нам не нужен. Ещё один минус — файл всё равно будет скачиваться, даже если он не исполняется в итоге.
Итого: в текущий момент решение с удалением из DOM ES5-адаптера, если он не нужен, будет для нас самым приемлемым. Со временем мы его улучшим, а пока — будем использовать в таком виде.
Ограничения полифила теневого DOM
Перед использованием же шаблона необходимо также вызвать дополнительный код: ShadyCSS.styleElement(this) ;
Есть ограничения на уровень вложенности селекторов со скобками при использовании вместе с :host() : :host(.zot) и :host(.zot:not(.bar)) будут работать, а :host(.zot:not(.bar:nth-child(2))) — уже нет.
Ограничения полифила шаблонов
Чтобы полифил и теневого DOM корректно отработал, на нас накладывается ещё одно ограничение: все теги уже должны быть в DOM-дереве на момент инициализации пользовательских элементов. Помогать нам с этим будет система сборки.
Шаблоны не могут быть вложенными и не должны содержать теги
Введение в веб-компоненты. Часть 1
От переводчика: Представляю вашему вниманию перевод многообещающего стандарта Веб-компонентов от Google, который может стать трендом в ближайшие несколько лет. В данный момент, знание этого стандарта не несёт практического применения, поэтому, если вы не фанат всего нового и интересного, вам возможно будет скучно читать данный перевод.
Перевод выложен на github, поэтому, если вы хотите помочь с переводом или исправить ошибку сделайте pull request, ну или пишите в личку.
Статус: Эксперементальный драфт
Введение
Компонентная модель для Web’а (или Web Components) состоит из четырёх модулей, которые, будучи использованными вместе, позволят разработчикам web-приложений создавать виджеты с богатыми визуальными возможностями, легкие в разработке и повторном использовании, что в данный момент невозможно с использованием только CSS и JS-библиотек.
Вместе декораторы и пользовательские элементы называются компонентами
Шаблоны
Содержимое элемента анализируется парсером, но оно неактивно: скрипты не запускаются, изображения не загружаются и т. д. Элемент не выводится.
В скрипте такой элемент имеет специальное свойство content, которое содержит статическую DOM-структуру определённую в шаблоне.
Например, разработчику может понадобиться определить DOM-структуру, которая создается несколько раз в документе, а затем создать его экземпляр, когда это будет необходимо.
Добавление статического DOM-узла в документ делает его «живым», как если бы этот DOM-узел был получен через свойство innerHTML.
Декораторы
Декоратор это нечто, что улучшает или переопределяет представление существующего элемента. Как и все аспекты представлений, поведение декораторов контролируется с помощью CSS. Однако, возможность определять дополнительные аспекты представления, используя разметку — уникальная черта декораторов.
Элемент указывает на место, куда декоратор (точнее, его содержимое) должен быть вставлен.
Декоратор применяется, используя CSS-свойство decorator:
Декоратор и CSS описанные выше заставят данную разметку:
+Но её рендер будет как у этой разметки (стили user agent опущены для краткости):
Если документ изменился так, что CSS-селектор, где был объявлен декоратор, более не действителен — обычно, когда селектор со свойством decorator более не применяется к элементу или правило с декоратором было изменено в атрибуте style, декоратор более не применяется, возвращая рендеринг элемента в первоначальное состояние..
Даже несмотря на то, что CSS-свойство decorator может указывать на любой ресурс в сети, декоратор не будет применяться, пока его определение загружается в текущий документ.
Разметка, которая генерируется представлениями, ограничивается чисто презентационным применением: она никогда не может запустить скрипт (в том числе встроенные обработчики событий), и она не может быть доступна для редактирования.
События в декораторах
Декораторы также могут навешивать обработчики событий для реализации интерактивности. Поскольку декораторы преходящи, не эффективно навешивать обработчики событий на ноды в шаблоне или полагаться на любое состояние шаблона, так как ноды в шаблоне пересобираются каждый раз как декоратор применяется или снимается с элемента.
Вместо этого, декораторы регистрируют обработчики событий у контроллера событий. Чтобы зарегистрировать обработчик событий, шаблон включает в себя элемент Bar
Вызов функции lisnen означает, что когда кнопка будет нажата, сработает обработчик события.
Контроллер событий перенаправит событие, наступившее в на любой ноде, на которой декоратор был применён, в обработчик события.
Рис. Обработка и переназначение событий
Когда слушатель событий вызывается, значением target события является нода, на которую декоратор был применен, а не содержимое его шаблона. Например, если декоратор, указанный выше, такого содержания:
Переопределение свойства target необходимо, тк декоратор определяет отображение; он не влияет на структуру документа. Пока декоратор применён, свойство target переопределяется на ноду, на которую он применён.
Также, если скрипт меняет контент шаблона, изменения игнорируются, точно также, как установка textContent элемента > V
Для этого понадобилось два декоратора. Один представляет detail элемент в закрытом виде, другой в открытом. Каждый декоратор использует обработчик события клика мыши, для изменения состояния открыт/закрыт. Атрибут select элемента будет рассмотрен подробнее ниже.
Пользовательские элементы
Пользовательские элементы — новый тип DOM-элементов, которые могут быть определены автором.
Пользовательские элементы могут определять вид отображения через декораторы. В отличии от декораторов, которые могут быть применены или сняты на нужный элемент, тип пользовательского элемента фиксирован. Но пользовательские элементы могут определять совершенно новое отображение и поведение, которые нельзя определить через декораторы, из-за элементарной природы последних.
Элемент определяет пользовательский элемент.
Атрибут extends определяется элемент, функционал которого мы хотим расширить. Каждый экземпляр пользовательского элемента будет иметь tagName определённый в атрибуте extends.
Атрибут name определяет пользовательский элемент, который будет связан с этой разметкой. Пространство имён у атрибута name такое же, как у имён тэгов стандартных элементов, поэтому для устранения коллизий, используется префикс x-.
Разные браузеры, определяют HTML элементы по-разному, однако все их интерпретации руководствуются семантикой HTML.
Тк не все браузеры поддерживают пользовательские элементы, авторы должны расширять HTML элементы, которые имеют наиболее близкое значение для нового пользовательского элемента. Например, если мы определяем пользовательский элемент, который является интерактивным и реагирует на клики, выполняя некоторые действия, мы должны расширять кнопку ( ).
Представление
Пользовательский элемент может содержать шаблон:
Если пользовательский элемент содержит шаблон, копия этого шаблона будет вставлена в теневой DOM элемента конструктором пользовательских элементов.
Теневой DOM будет описан ниже.
Использование пользовательских элементов в разметке
Т.к. пользовательские элементы использую существующие HTML тэги (div, button, option и тд), нам нужен атрибут для определения когда мы хотим использовать пользовательский элемент. Таким атрибутом является is, а значением его является название пользовательского элемента. Например:
Использование пользовательских элементов в скриптах
Вы можете создать пользовательский элемент из скрипта, используя стандартный метод document.createElement:
Пользовательский элемент может объявлять методы API добавляя их в свой prototype, в элементе …
Для того, чтобы обеспечить простую деградацию, this внутри элемента
Технически, скрипт внутри элемента
Нельзя создать пользовательский элемент указывая is атрибут у существующего DOM-элемента. Выполнение следующего кода ничего не даст:
Обновление элемента
Когда объявление пользовательского элемента будет загружено, каждый элемент с атрибутом is установленном в имя пользовательского элемента будет обновлён до пользовательского элемента. Обновление должно быть идентично удалению элемента и замене его на пользовательский элемент.
Когда каждый элемент заменяется, не всплывающее (non-bubbling), неотменяемое (non-cancellable) событие возникает на удаляющемся элементе. Скрипт, который хочет задержать взаимодействие с остальной часть документа до тех пор, пока пользовательский элемент не загрузиться может подписаться на специальное событие:
Авторы, которые хотят избежать показа нестилизованного контента, могут использовать CSS для изменения отображения не заменённого, обычного элемента, пока пользовательский элемент не загрузиться.
Методы жизненного цикла
Пользовательский элемент может подписаться на четыре метода жизненного цикла:
Обработчики inserted и removed могут быть вызваны несколько раз, каждый раз, когда пользовательский элемент вставляется и удаляется.
Подписаться на эти обработчики можно вызвав метод HTMLElementElement.lifecycle:
Расширение пользовательских элементов
В дополнении к HTML-элементам, можно расширить пользовательский элемент указанием имени пользовательского элемента в атрибуте extends элемента :
Обработка ошибок
Есть несколько возможностей для обработки ошибок при рендеринге пользовательских элементов:
От переводчика: в следующей части мы рассмотрим применение shadow DOM в Веб-компонентах, про внешние пользовательские элементы и декораторы, и про изоляцию, ограничение и инкапсуляцию Веб-компонентов