Элемент <template> и его перспективы
Тред из четвёртого дня моей недели в @jsunderhood.
Сегодня начнем с треда про элемент <template>. Раньше он считался частью веб-компонентов, хотя сейчас о нем вспоминают реже.
— jsunderhood (@jsunderhood) November 12, 2020
Содержимое <template> является инертным: элементы не попадают в DOM, скрипты не выполняются, стили не применяются. По сути это декларативный способ создания DocumentFragment.https://t.co/o20ldEuosu
— jsunderhood (@jsunderhood) November 12, 2020
Получить содержимое <template> можно с помощью свойства content, используя один из двух методов: content.cloneNode(true) или document.importNode. На практике разница обычно несущественна.https://t.co/vDann1gHsG
— jsunderhood (@jsunderhood) November 12, 2020
На первый взгляд этот элемент прост, и появился он в браузерах намного раньше Custom Elements и Shadow DOM. Тем не менее, его внедрение потребовало изменений HTML-парсера.https://t.co/GfxKckMNe2
— jsunderhood (@jsunderhood) November 12, 2020
Для IE11 есть полифилл, который имеет ограничения. Например, нельзя использовать <template> внутри элементов <table> и <select>: в обоих случаях IE удаляет незнакомый ему тег.https://t.co/8pHblGu9Qu
— jsunderhood (@jsunderhood) November 12, 2020
Темплейты в Polymer использовались с кастомным синтаксисом для data binding. Вместе с HTML Imports это позволяло писать в HTML вообще все. Про типизацию шаблонов тогда никто не думал.
— jsunderhood (@jsunderhood) November 12, 2020
Впрочем, создавать <template> можно и в JavaScript. Это полезно для ванильных кастомных элементов: по сравнению с использованием innerHTML темплейты быстрее (нет лишних затрат на парсинг).
— jsunderhood (@jsunderhood) November 12, 2020
Именно этот способ использует библиотека lit-html от команды Polymer, синтаксис которой основан на tagged template literals. Подробнее о принципах ее работы можно почитать в ее wiki.https://t.co/Sga4pRHdAF
— jsunderhood (@jsunderhood) November 12, 2020
Замечу, что lit-html в этом плане не уникальна. Более того, Andrea Giammarchi утверждает, что в hyperHTML он реализовал этот подход раньше, а разработчики из Google позаимствовали его идею.https://t.co/R9Dukpxkff
— jsunderhood (@jsunderhood) November 12, 2020
Теперь о перспективах <template>. Недостаток этого элемента в том, что он не предоставляет API для интерполяции значений. В качестве возможного решения предложен черновик Template instantiation.https://t.co/1vRXffReNB
— jsunderhood (@jsunderhood) November 12, 2020
Наряду с AOM, это один из примеров инициативы со стороны WebKit. Из моих предыдущих твитов могло сложиться впечатление, что все инновации двигает Chrome, но чаще это плод совместных усилий.
— jsunderhood (@jsunderhood) November 12, 2020
Развитием идеи Template instantiation является новый черновик DOM Parts за общим авторством разработчиков WebKit и Chrome. Это API на первый взгляд имеет много общего с устройством lit-html.https://t.co/PjCM12wKyk
— jsunderhood (@jsunderhood) November 12, 2020
В перспективе DOM Parts могут сделать манипуляции с DOM более эффективными и упростить написание библиотек вроде lit-html. Но пока эта идея в стадии обсуждения и к ней есть ряд вопросов.https://t.co/pYWu2YjVkM
— jsunderhood (@jsunderhood) November 12, 2020
Напоследок упомяну еще один черновик, предложенный после удаления HTML Imports. Он называется HTML modules и в теории придаст новую жизнь декларативному применению <template>.https://t.co/Qhxd4gRVIu
— jsunderhood (@jsunderhood) November 12, 2020
Как и CSS-модули, которые я упоминал вчера, этот черновик долгое время был заблокирован, но теперь возобновление работы над ним стало возможным благодаря переходу Import Assertions на Stage 3.https://t.co/77oA8Zkn0i
— jsunderhood (@jsunderhood) November 12, 2020
Возможно, в будущем <template> станет опорой для неких новых конструкций, меняющих наши представления об HTML. Но полезен он и сейчас, что подтверждает статистика Chrome Platform Status.https://t.co/H8jotaKIBj
— jsunderhood (@jsunderhood) November 12, 2020