Как стать автором
Обновить

Комментарии 90

Я уже читал несколько статей про эти предлагаемые нововведения. Один момент мне непонятен, почему это называют веб-компонентами? Именно компонентами? С точки браузера это вроде бы не компоненты. Я в статьях не вижу такого, что бы компонент был создан один раз и использовался в нескольких местах. Там везде рисуют создание нового теневого дерева и его элементов при каждом использовании. То есть это теплейтинг поддерживаемый непосредственно в браузере. Правильно я понимаю или что-то упустил?
Могу только догадываться почему назвали именно так. В источниках эта информация не попадалась.

В примерах к этой статье, например здесь (код) и тут (код) я переиспользую самописный элемент <wc-example>, его код лежит здесь.

Получившийся TODO-виджет также можно переиспользовать. Импортим html-файл на страницу, и браузер будет рисовать виджет на месте <x-todo> элементов.

Тег <template> это не совсем темплейтинг. Скорее механизм отложить фрагмненты разметки, пока они не пригодятся. Подставлять данные в содержимое <template> нужно вручную, с помощью js.
Но он же не переиспользует общий компонент, а каждый раз создает новые фрагменты документа по указанному образцу. И когда создает фрагмент, получившийся фрагмент не как отдельная сущность, а как набор элементов в дереве элементов документа. Что именно в этом от понятия «компонент»? Мне кажется это типичный шаблон.
Я думаю, под компонентом здесь понимается часть общей системы web разработки на стороне клиента, а не то как вы этот компонент применяете. Если говорить с точки зрения повторяющейся логики, то это относится к возможности создания своих компонентов, а здесь описано именно их применение.

Простейший пример — тег template — это компонент для создания шаблонов, как если бы в каком-нибудь веб-фреймворке компонент system.template отвечал бы за базовый функционал создания template на стороне сервера / клиента.
Всё верно, он каждый раз создаёт новые фрагменты документа. Но в отличие от шаблона, shadow tree изолировано от остального DOM, то есть:

  • Добраться до содержимого shadow tree с помощью document.querySelector() и querySelectorAll() нельзя
  • Стили, определённые в документе не распространяются на содержимое (если applyAuthorStyles = false)
  • Стили, определённые в shadow tree не распространяются на документ.

Наружу у «кастомного элемента» торчит только JS API, определённое разработчиком.
Они дают возможность вставлять в документ фрагменты разметки из других файлов.

Импортируемый документ должен быть нормальным html-документом (доктайп, html, head, body и т. п.) или действительно фрагментом html, включая неразмеченный текст? И происходит ли реимпорт при изменении атрибута href из JS?

P.S. сейчас проверить нет возможности.
Импортируемый документ не должен быть полноценным. Это действительно фрагменты разметки. Импортируемый файл TODO-виджета, например, выглядит так.

Реимпорт не происходит. Полагаю, это один из багов. Импорты работают не так хорошо, как всё остальное.
Читая статьи про Web Components, ощущаю стойкое Déjà Vu. У Adobe Flex как раз очень стройная компонентная модель. Там можно создавать свои элементы UI, которые можно добавлять в приложение (через XML разметку или с помощью ActionScript кода) как обычные кнопки, табы, ссылки. При этом компонент во Flex-е может объявлять собственные XML атрибуты, CSS свойства и события. Доступно наследование таких виджетов. Есть механизм Skin-ов для отделения логики от внешних красивостей.
Эх, жаль, что Flash теряет популярность :(
Shadow DOM — это калька с микрософтовских HTML Components и behaviors (2001 год). Вот это дежавю всем дежавю дежавю.
Вообще Microsoft поддерживала создание кастомных тэгов с начиная с Internet Explorer 5, хотя в 10 версии эта поддержка была удалена из браузера.
Вот только эта поддержка — разная. IE требовал некоторой обязательной процедуры «регистрации» тега, а остальные браузеры — оборачивают неизвестные теги в HTMLUnknownElement и позволяют навешивать не наго любые стили безо всяких дополнительных настроек.
Все правильно, их инициативу никто тогда не поддержал. Идея опережала свое время.
Какие другие браузеры в 2001 году) Вы о чем?) Микрософт флегматично клал болт на W3C и другие браузеры, потому как в то время совокупная доля IE была под 96%.

Концепция HTML Components и behaviors, как и HTML Applications, была весьма актуальна и очень перспепктивна на то время. но Микрософт застопорил развитие IE6, увидев в развитии веба конкурента своим десктопным продуктам. Это отлично описано у Джоэла Спольски russian.joelonsoftware.com/Articles/HowMicrosoftLosttheWaronA.html, если кто не читал — крайне рекомендую.

Да. Это жопа конкретная

А я вот лично не вижу особенно смысла в Shadow DOM, custom tags и шаблоны:

1) Shadow DOM: это сознательное зарезание возможностей в угоду не совсем понятно чем — все равно каждый сайт сам стилизует свой плеер или выбирает из имеющихся. Ну и естественно постоянная проблема с кроссбразуерностью. Непонятно, что оно мне должно дать, кроме мобильников, где вся эта стилизация и не нужна.
2) Custom tags — их писать можно и ладно. Как именно их обрабатывать я могу реализовать и на JS
3) Не случайно шаблонизаторов так много — у всех разные предпочтени и разные возможности. И сейчас я могу использовать любой, не понятно чем мне поможет еще один на уровне браузера, который еще и наверняка работать будет по разному в разных браузерах.

Новое API в JS да, полезное.
По мне так SharowDOM это наоборот маст хев фича, с ее помощью, «без геморроя», можно будет кастомизировать стандартные представления. Зачем мне пилить свой плеер, если я могу подправить стили стандартного?
>Зачем мне пилить свой плеер, если я могу подправить стили стандартного?

Затем, что вы можете выбрать из миллиона уже существующих тот, который нравится именно вам.
Ага, только на практике иногда нужен свой, со своим дизайном. Да бог с ним с плеером, возьмем стандартные компоненты, чекбоксы, радиобаттоны и прочее.
Вот-вот, именно, даже они стилизуются, куда уж более сложным элементам.
  1. Не совсем понял мысль вашу мысль о Shadow DOM. Приведу ещё один пример его использования.

    Так выглядит разметка строки поиска google.com
    <fieldset class="gbqff gb_j" id="gbqff">
      <legend class="gbxx"></legend>
      <div id="gbfwa" class="gbqfwa ">
        <div id="gbqfqw" class="gbqfqw ">
          <div id="gbqfqwb" class="gbqfqwc">
            <table cellspacing="0" cellpadding="0" id="gs_id0" class="gstl_0 lst-t" style="height: 27px; padding: 0px;">
              <tbody>
                <tr>
                  <td id="gs_ttc0" style="white-space: nowrap;" dir="ltr"></td>
                  <td id="gs_tti0" class="gsib_a">
                    <div id="gs_lc0" style="position: relative;">
                      <input id="gbqfq" class="gbqfif" name="q" type="text" autocomplete="off" value="" style="border: none; padding: 0px; margin: -0.0625em 0px 0px; height: 1.25em; width: 100%; background-image: url(data:image/gif;base64,R0lGODlhAQABAID/AMDAwAAAACH5BAEAAAAALAAAAAABAAEAAAICRAEAOw%3D%3D); background-color: transparent; position: absolute; z-index: 6; left: 0px; outline: none; background-position: initial initial; background-repeat: initial initial;" dir="ltr" spellcheck="false">
                      <div class="gbqfif" id="gs_sc0" style="background-color: transparent; color: transparent; padding: 0px; position: absolute; z-index: 2; white-space: pre; visibility: hidden; background-position: initial initial; background-repeat: initial initial;"></div>
                      <input class="gbqfif" disabled="" autocomplete="off" aria-hidden="true" id="gs_taif0" dir="ltr" style="border: none; padding: 0px; margin: 0px; height: auto; width: 100%; position: absolute; z-index: 1; background-color: transparent; -webkit-text-fill-color: silver; color: silver; left: 0px; visibility: hidden;"><input class="gbqfif" disabled="" autocomplete="off" aria-hidden="true" id="gs_htif0" dir="ltr" style="border: none; padding: 0px; margin: 0px; height: auto; width: 100%; position: absolute; z-index: 1; background-color: transparent; -webkit-text-fill-color: silver; color: silver; transition: all 0.218s; -webkit-transition: all 0.218s; opacity: 0; left: 0px; text-align: left;">
                    </div>
                  </td>
                  <td class="gsib_b">
                    <div class="gsst_b" id="gs_st0" style="line-height: 27px;" dir="ltr">
                      <a class="gsst_a" href="javascript:void(0)" aria-label="Listening for "Ok Google"" style="display: none;"><span class="gsri_ha gsst_e" id="gsri_hok0"></span></a><a class="gsst_a" href="javascript:void(0)" aria-label="Search by voice"><span class="gsri_a gsst_e" id="gsri_ok0"></span></a>
                      <div id="chmo">
                        <div id="chm">
                          <div class="chmp">
                            <div class="chmpi chmp"></div>
                          </div>
                          <div style="display: none;">
                            <div class="chma"></div>
                            <div>Not listening. Something went wrong.</div>
                            <div><a>Restart listening</a><a style="padding-left: 10px;">Help</a></div>
                          </div>
                          <div style="display: none;">
                            Hotword detection is off.
                            <div><a>Start listening for "Ok Google"</a></div>
                          </div>
                        </div>
                      </div>
                    </div>
                  </td>
                </tr>
              </tbody>
            </table>
          </div>
        </div>
      </div>
    </fieldset>
    


    Очень много «низкоуровнего» кода. Shadow DOM позволяет скрыть детали реализации элемента и инкапсулировать его стили, чтобы они не конфликтовали с документом. Таким образом в документе строка поиска будет выглядеть как-то так:

      <div class="google-search"></div>
    


    Или так, с использованием custom elements:

      <google-search></google-search>
    


    Детали реализации будут изолированны и лежать где-то в другом месте. Это похоже на разделение интерфейс/реализация в объектно-ориентированных языках.

  2. Подобие custom elements можно написать самому, тут вы правы. Они уже есть в некоторых фреймворках. Ничего нового, только теперь браузер будет поддерживать это нативно.
  3. <template> это не совсем шаблонизатор. Его задача не в том, чтобы взять данные и подставить их в разметку. Это скорее «хранилище» html кода, который вы планируете использовать не сразу, как только документ загрузится, а позже.

    API у него сводится к одному свойству content. Сомневаюсь что браузеры тут могут накуролесить.

Согласен на счет template — очень полезный тег, который позволит хранит шаблон (например) скрытых форм обратной связи или всплывающих подсказок.
Вот пример pearlplaza.ru/virtual-plan/ — всплывающие подсказки при наведении. Было спроектировано как скрытый div в который подставляются данные из js объекта. По сути используется один и тот же элемент но с разными данными. Во время загрузки страницы браузер парсит div, а если все закрыть в template — парсить не будет.

Еще пример (более подходящий) — у нас есть страница с комментариями к статье на хабре. Вместо того чтобы изобретать велосипед или шаблон внутри js кода или делать скрытый div а потом копировать его, можно один раз создать template и вставлять его на страницу каждый раз с новыми данными по кнопке «Написать».

Потенциал Custom Elements и Shadow DOM, мне кажется, еще не раскрыт, однако у меня уже есть мысли как бы я мог применить их.

Спасибо за статью кстати!
Еще пример (более подходящий) — у нас есть страница с комментариями к статье на хабре. Вместо того чтобы изобретать велосипед или шаблон внутри js кода или делать скрытый div а потом копировать его, можно один раз создать template и вставлять его на страницу каждый раз с новыми данными по кнопке «Написать».
По сути точно так же оно происходит и сейчас, только не в template, а в div, js или через ajax. Если есть шаблон, то как вы его не назовите он шаблон и есть. И точно так же количество манипуляций не изменится. Мне кажется разница только в том, что раньше мы это делали разными способами, а сейчас эта практика унифицируется.
И унифицируется нативно для html — например, IDE будут лучше поддерживать, чем сборку в JS-скрипте из строк.
Этот html все-равно нужно где-то собирать. Не на клиенте, так на сервере или в прекомпиляции. И делает это не IDE.
Сейчас часто в js можно встретить что-то типа (утрирую)
var html = '<li><img src="'+ url1 +'"></li><li><img src="'+ url2 +'"></li>...'
. IDE с таким кодом работают плохо. Скрытые теги будут обрабатываться, да и могут нарушать валидность документа. Новый тег от этих проблем избавит.
Новый тег от этих проблем избавит.
Сэр, но как?
Куда оно денется? Даже если сделать автоматическую подстановку значений в код шаблона, большая часть таких алгоритмов все-равно работает с условиями, циклами и прочими сложностями. Ну то есть этот алгоритм никуда не исчезнет чудесным образом. Делать компонент для каждого LI тоже не вариант. Это явно проигрывает варианту с js библиотекой темплейтинга.
Что помешает сделать новую библиотеку темплейтинга — со всеми требуемыми условиями, циклами и прочими сложностями? Я вот, к примеру, уже предвкушаю, как красиво будет смотреться переделанный на новый лад AngularJS.

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

Одно расстраивает. На новую версию AngularJS мы будем десять лет смотреть и облизываться — но не будем его использовать. Потому что нужна совместимость с IE…
Для работы с условиями, циклами и прочим мы по-прежнему можем использовать любимые template-библиотеки, вроде Mustache. <template> просто держит ваш шаблон «на готове», как его заполнять данными — дело ваше.

Polymer используют Mustache совместно с <template> и Object.observe для подстановки данных в шаблоны: polymer data-bindings.
Хотя нет, я не прав. Действительно нужны будут новые библиотеки. Polymer просто одолжил синтаксис своей у Mustache.
Во первых, я лично считаю, что этот подход с шаблонами и data-биндингом крайне неэффективен. И точки зрения скорости разработки и с точки зрения производительности. Программировать необходимо на уровне компонентов, а биндинг данных должен осуществляться самым эффективным образом в коде компонента или вообще по возможности платформой и не манипулируя отдельными элементами и атрибутами DOM. И соответственно реализовал этот подход в своей библиотеке controls.js
Но мы не об этом, а о том что
var html = '...'
сам по себе с введением обсуждаемых подходов не исчезнет. Он может перекочевать частично в dom template, но только частично, логика останется в коде. И в итоге получится возможно сложнее если делать с использованием dom template. А эффективности работы с DOM сами понимаете.
В то время как сейчас можно совершенно спокойно выбросить такой код в компоненты уже существующих JS библиотек и избавиться и от этой лапши, и от затрат на DOM. Уже сейчас все это лаконично и шустро работает, даже без shadow dom.
Я думаю, создавать сотню скрытых DOM элементов не правильно (особенно с картинками). Компоненты, перечисленные в статье в большей степени помогут в фронтенд разработке. Например тот же Meteor.js уже использует template во всю.

Мне, почему-то вспомнились слайдеры, которые сегодня используются повсеместно, одна лишь возможность делать слайдер с помощью template уже греет душу.

Мое мнение таково:
— Меньше костылей в коде.
— Легче делать отзывчивые асинхронные приложения.
— И как сказано ниже в комментариях «У кастомных тэгов можно задавать свой прототип для объектов DOM — вот это реально крутая вещь»
Мне, почему-то вспомнились слайдеры, которые сегодня используются повсеместно, одна лишь возможность делать слайдер с помощью template уже греет душу.
Какое именно предполагается в этом преимущество? Вы хотите вставить слайдер именно в DOM и редактировать его DOM дереве? Если вставить в основную страницу, то это очень плохая идея. Если шаблон в отдельном html файле, то это будет менее эффективно, чем компонентная система на JS. Если вы хотите редактирвать в IDE, то это не проблема и задача shadow DOM. Это можно сделать и сейчас существующими средствами и эффективнее.
У меня есть простой пример компонента carousel, он конечно не редактируется сейчас в IDE, но мог бы, если бы IDE этого захотело.

— И как сказано ниже в комментариях «У кастомных тэгов можно задавать свой прототип для объектов DOM — вот это реально крутая вещь»
Не могли бы вы пояснить зачем вообще это нужно? Зачем нам прототипы в DOM? Нужно наоборот избегать манипуляции элементами DOM.
Карусель, которую Вы привели в пример, не семантична изначально ну и ID в веб инспекторе смотрится страшно.

Когда я говорил про слайдер, я имел ввиду ситуацию с предзагрузкой изображений.
Карусель, которую Вы привели в пример, не семантична изначально ну и ID в веб инспекторе смотрится страшно.
Вас напугали картинки закодированные в коде страницы? Ну так это не элемент семантики. Замените в уме эти картинки привычными вам img src="". Это же просто страничка так сделана, что бы без внешних файлов можно было скопировать.

Когда я говорил про слайдер, я имел ввиду ситуацию с предзагрузкой изображений.
Не совсем понимаю связь template с предзагрузкой изображений. Не могли бы вы пояснить, как сделать предзагрузку картинок с помощью template? И вопрос про прототипы остается.
Не совсем понимаю связь template с предзагрузкой изображений. Не могли бы вы пояснить, как сделать предзагрузку картинок с помощью template?

Как раз таки предзагрузки картинок не будет пока слайдер не дойдет до нужного слайда. Просто на событие onslide вешается код вставки слайда (с картинками) с использованием template.

И вопрос про прототипы остается.

Кастомные элементы способны хранить в себе методы и вести себя так как необходимо разработчику. Элемент div это лишь контейнер который не несет в себе никакой нагрузки, в то время как тот же audio подгружает целый скин плеера. Таким образом мы можем создавать на странице элементы типа audio и прочее со своей логикой. В примере выше приводился код гугл-поиска и кнопки лайков. Думаю это самые яркие примеры.
По поводу ID, это не обязательный элемент технологии, шаблон для любого элемента можно сделать без ID. Поэтому не пугайтесь, это тоже особенность реализации этих конкретных шаблонов. Но вообще в этой теме мы обсуждаем очень сильное усложнение дерева DOM и потенциально все это приведет к закрытости части публичных «компонентов», их обфускации, привыкайте и готовьтесь.
с выключеным JS я увижу что то вроде этого?
[carousel parameters]
[slide active] slide content [/slide]
[slide] slide content [/slide]
[/carousel]

по моему это не семантично
Нет, вы увидите статичный html. Что он будет отображать, статичный кадр страницы, JS-less версию страницы или сообщение о неработоспособности без JS, это как веб-мастер решит. Мне не очень хотелось включать компиляцию внутренних страниц сайта в html, поэтому у меня там только сообщение.
На мой взгляд, создавать велосипеды шаблонизации не стоит, так как лучшие практики уже получили место в стандартах и называется это template. А код с квадратными скобками это затычка, которая была необходима, до появления нативной поддержки. В HTML должны быть теги для разметки, атрибуты к тегам и ничего более.

Точно так же вымерли текстуры закругления углов, двойные рамки, градиенты и так далее. Скоро текстуры из Web совсем вымрут и останутся только иконки и изображения есущие смысловую нагрузку. По сути бэкграунд изображением для отображения градиента — скорее временная мера которая вышла сейчас из моды чем нечто более удобное чем линейный градиент в CSS.

Я тут подумал сегодня и прикинул как бы смотрелись новые jQuery плагины которые вызываются кастомными тегами, а вся разметка уходит в shadow DOM
Это было бы здорово, если бы консорциум w3 не ошибался, но к сожалению это не так. У них есть совершенно лажовые и не используемые разделы стандарта. Язык JS имеет серьезные огрехи проектирования и значительная часть кода библиотек направлена только на обход этих недостатков. Это все дает веские основания не верить вашему мнению о том, что стандарт вбирает лучшие практики. Компоненты в веб появились кучу лет назад, но w3 их только сейчас начинает внедрять, да и то под напором ребят из гугла. А вместо этого они шли по совершенно тупиковому пути вводя узкоспециализированные теги. Есть такие тэги о которых вы скорее всего даже и не знаете.
За критику, упоминания про велосипед и затычку, да, спасибо. Почему-то, мой велосипед работает быстрее чем фреймворки и решает дополнительный круг задач. Разметка проще чем в википедии и имеет больше возможностей. Я с его помощью могу писать приложения на node-webkit и делать многие вещи, которые вы с template не сможете. Без квадратных скобок обойтись не представляется возможным.
Для использования обсуждаемых новых возможностей в моей библиотеке скорее всего не потребуется ничего менять, архитектура полностью совместима, я могу использовать в своих компонентах template&shadow DOM.
Поэтому нет, не велосипед и нет, не затычки.
Про квадратные скобки тут немного другая история. Просто это не совсем те скобки, что вы привыкли видеть. Да, это bbCode, но тут текст внутри квадратных скобок может иметь другую, несовместимую с html разметку. Html имеет на это ограничения. Поэтому все-таки квадратные скобки остаются.
Я не вижу смысла спорить. Каждый останется при своем мнении в любом случае. У меня в голове долго складывались принципы создания качественных веб приложений, У Вас они свои.

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

У меня как то тоже недавно была идея добавить библиотеку в PHP которая позволяла бы простые типы хранить в объектах, а вместо функций использовать методы этих объектов (под впечатлением от Python и JS), однако я отказался от этой идеи, после долгих анализов ситуации, так как пришел к выводу что данная библиотека будет являться костылем для PHP и лучше в таком случае использовать другой язык, с нативной поддержкой.

Аналогично Вашему случаю — появилась нативная поддержка, следовательно можно облегчить код и клиент-сайд для ускорения работы приложения.
У меня как то тоже недавно была идея добавить библиотеку в PHP которая позволяла бы простые типы хранить в объектах, а вместо функций использовать методы этих объектов (под впечатлением от Python и JS)


Сразу вспомнилось вот это творение Антона Шевчука.
Дата-биндинг отдельная тема, тут я согласен.

Я понимаю, о чём вы. Да, уже существует множество решений проблем шаблонов. На любой вкус и цвет, и работают они довольно быстро.

По поводу подхода var html = '<img src="' + image +'>"'. Он может быть только временным решением. Библиотеки шаблонов, по сути, делают тоже самое, только эскейпят данные. Вариант сносный, но выглядит скорее как хак.

От работы с DOM в любом случае не уйти. Даже если мы собрали строку с данными, её нужно вставить в DOM. Давайте сравним два подхода пошагово.

Строки
  1. Получить строку шаблон.

    a). Загрузить AJAX-ом
    б). Найти в DOM элемент, содержащий шаблон, извлечь шаблон оттуда.

  2. Провернуть множество операций со строками. Эскейпить данные вручную.

  3. Вставить получившуюся строку в DOM. Браузер парсит строку, рендерит содержимое.


<template>
  1. Получить содержимое <template>.

    Найти в DOM тег <template> с нужным шаблоном. Его содержимое уже распаршено, с ним можно работать как с любым элементов в DOM.

  2. Подставить данные, используя DOM API. Нет необходимости заботится о вредоностности данных.

  3. Вставить элемент DOM в… DOM. Браузеру не нужно ничего парсить, он сразу рендерит содержимое.

Сложно сказать, какой подход будет быстрее, пока нет бенчмарков. Но вариант с <template> определённо однородней и «чище».

Да, скорость работы DOM пока ещё проблема. Но мы, в случае с <template> работаем на очень ограниченном его «участке».

Уже сейчас все это лаконично и шустро работает, даже без shadow dom.

Shadow DOM не влияет на работу шаблонов.
Еще раз повторяю, вот этого " Подставить данные, используя DOM API. Нет необходимости заботится о вредоностности данных." не будет. Это фантастика. Это вы так предположили, но это не так. Никто такого еще не придумал, хотя пытались. Логика интепретации шаблона или слишком проста и не удовлетворяет, или построена на сложных правилах, или требует языка программирования. Где-то требует яп, где-то нет, но подход должен быть общим, поэтому в общем случае требует. Поэтому в общем случае с шаблонами в DOM решение будет и сложнее, и медленнее. Единственное кажущееся преимущество, это возможность с помощью IDE редактировать шаблон в виде какого-то визуального редактора. Но опять же, это ошибочное предположение. Это можно сделать и сейчас без всяких шаблонов в DOM и лучше будет если без них.
Да почему вдруг — фантастика, никто не придумал и этого не будет? Это, между прочим, уже есть. И этим пользуются.
Вы сами себе противоречите, Angular делает это через JS, это не соответствует вашему п.2.
Вы о чем?
2. Подставить данные, используя DOM API. Нет необходимости заботится о вредоностности данных.
Где тут написано, что это должно делаться без js?
DOM API это и есть JS… Это интерфейсы вроде HTMLElement, методы вроде appendChild() и cloneNode(), атрибуты вроде innerHTML. Вы что-то другое имеете ввиду под DOM API?
Я не могу понять вот этого:
2. Провернуть множество операций со строками. Эскейпить данные вручную.
и
2. Подставить данные, используя DOM API. Нет необходимости заботится о вредоностности данных.
Почему во втором случае у вас получается без кода логики и не нужно эскейпить.
Я не говорил, что без кода логики. Логика на JS, с использованием DOM. Не нужно эскейпить, потому что setAttribute(), textContent и им подобные сделают это за вас.
a). Загрузить AJAX-ом
б). Найти в DOM элемент, содержащий шаблон, извлечь шаблон оттуда.

Найти в DOM тег <template> с нужным шаблоном. Его содержимое уже распаршено, с ним можно работать как с любым элементов в DOM.

А куда делся аякс во втором варианте? Если вы заранее подгружаете шаблон в виде <template>, то вы точно также можете его без аякса подгрузить сразу и сейчас. А если вы подгрузили шаблон за ранее и он представляет из себя просто HTML без специальной разметки под вставку данных (как я вижу из примеров <template> предоставляет именно такое), то вы можете сразу создать из этого documentFragment и не вставлять его в DOM. А, когда нужно, взять его и
Подставить данные, используя DOM API. Нет необходимости заботится о вредоностности данных.

Тогда в чем отличие? В том, что documentFragment нужно где-то хранить и он занимает память? Если вам это так критично, то не создавайте его заранее, а просто вместо
Провернуть множество операций со строками. Эскейпить данные вручную.
Вставить получившуюся строку в DOM. Браузер парсит строку, рендерит содержимое.

создавайте documentFragment и работайте с ним через DOM API. Потом его вставляйте.

Собственно виджеты, которые есть в крупных фреймворках давным-давно, например, в Dojo, так и делают. Есть template: размеченный HTML. Есть JS: логика этого виджета. Внутри логики шаблон виджета доступен через свойство domNode в котором лежит documentFragment, который потом можно вставить в нужное место. Shadow же позволяет просто отображать эту domNode в веб-инспекторе в виде одного тэга. И то пока не поставлена галочка показывать призраков.

Сейчас страницы стали сложными и все фреймворки так или иначе приходят к идеям виджетов. Ребята в W3C это поняли и решили тоже запилить. Вероятно, иметь это нативно в браузере это хорошо, но это явно не стоит всех тех восторгов, которые по этому поводу высказываются. Плюс, судя по всему ребята решили сами пройти весь путь и поэтому, пока они соберут все грабли и сделают механизм сравнимый по удобству с тем, что сейчас предоставляют фреймворки, пройдет порядочно времени.
Сэр, но как?
Куда оно денется?

Просто в html-коде будет что-то вроде
<template>
  <li></li>
  <li></li>
</template>

которое нормально распарсится IDE.
Такой пример распарсится. Это logic-less шаблон. Большинство шаблонов у компонентов не такие. Поэтому логика останется в коде. Я же спрашиваю вас про шаблоны с логикой. html он без логики, что бы добавить в него шаблоны нужно добавить и логику.
Каждый уважающий себя разработчик должен написать свой шаблонизатор, ребята этим и занимаются. Это обычные ребята, есть примеры в w3 стандартах совершенно не применимых в реальной жизни вещей. Помня примеры той лажи я не предполагаю по дефолту, что ребята очень продуманные. Они что-то внедряют, но будет ли это применимо время покажет.
Вы сейачс с кем спорите-то? Кто-то утверждает, что с новым тегом больше не нужна логика?
Нет, я больше спрашиваю. Спрашиваю, зачем вообще нужен этот тэг. Мне отвечают что-то вроде «создаешь шаблон, данные сами туда фьюить, и готово, и не надо ничего эскейпить, оно само! И это будет крута!». А я не могу понять в чем крутизна, и почему не нужно эскейпить, и как оно туда само залезет.
Ну да ладно, будет больше рабочих примеров, там и увидим.
оздаешь шаблон, данные сами туда фьюить, и готово

Кто и где такое говорит? Лично я только о том, что предложенные шаблоны органичнее вписываются в html и в процесс разработки вообще, чем сборка их в JS из строк.
и не надо ничего эскейпить
Да, я именно так и говорил. Где вы тут нашили «и не надо никакого js»?
> Содержимое тегов парсится браузером, но не вызывает выполнение скриптов

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

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

Однако в некоторых случаях кастомные тэги — это то, что доктор прописал. Например, всякого рода кнопки like и +1 — очень хорошие кандидаты. Но повторяю — не везде их применение имеет смысл.
По поводу проблем 2 и 3 согласен. Да, кнопки like и +1 действительно показательный кейс. Что вы имеете ввиду под стандартизацией кастомных тегов?

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

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

Я имел ввиду, если браузер загружает документ, в котором есть такой код:

  <template>
    <script>alert(1);</script>
  </template>

alert(1); не выполнится до тех пор, пока мы не сделаем импорт содержимого шаблона:

  var tmpl = document.querySelector('template');
  var tmplBody = document.importNode(tmpl.content);

  document.body.appendChild(tmplBody);
> Что вы имеете ввиду под стандартизацией кастомных тегов?
Представьте ситуацию когда любой уважающий себя разработчик будет создавать кастомный тэг для табов. Если брать HTML5, например, там есть спека в которой четко описано что делает тэг, какие у него могуть быть дочерние элементы и т.д. И это очень здорово, т.к. у нас есть набор тэгов которые все одинаково понимают. С кастомными тэгами такого не будет. По сути <my-tabs/> будет эквивалентен <ul class="my-tabs"/>. Поэтому в плане ускорения стандартизации никаких значительных плюсов у кастомных тэгов нет перед теперешним подходом создания виджетов.
У кастомных тэгов можно задавать свой прототип для объектов DOM — вот это реально крутая вещь. А использование их исключительно в разметке — действительно, ничем от подхода с классами не отличается.
Такого рода стандартизация по-моему будет скорее мешать. Умный ход — выпустить API которое позволяет программистам делать всё что они хотят, а потом взять лучшие практики и сделать их стандартом. Поступать наоборот — риск.

Я надеюсь, если web components пойдут в народ, появятся библиотеки элементов, вроде bootstrap, yui и т.д. У них будут свои, внутренние, стандарты и лучшие практики.
Вот тут с вами не соглашусь. Стандарты нужны иначе будет анархия, когда под одним и тем же понятием каждый человек будет понимать что-то свое.

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

Об остальном сложно спорить. Поживём — увидим…
Вы извините, что немного не по теме, но возник вопрос:
 <img src="bad-url"></img> <!-- почему так-то? -->
 <img src="bad-url" />     <!-- а не так? -->
Привычка… В html5 и так можно:

  <img src="bad-url">
Не только можно, но и нужно. Самозакрывающие теги (или как они там правильно называются) вообще не поддерживаются в html. Попробуйте написать
<script src="..." />
и поймете, почему этот слэш в конце тэга — суть самообман.
Понял, спасибо за ответ, просто не сталкивался с таким.
Я уже больше года с большой надеждой наблюдаю за развитием этого стандарта. По-моему, только web components смогут наконец положить конец леденящему душу ужасу, что творят сейчас разработчики, пытаясь разобраться, как работать с повторным использованием кода, сфокусированного на элементах страницы, а не на внутреннем устройстве собственно кода. Текущий предел инженерной мысли – календарик и пара плагинов от гигантов.

Подскажите, может уже появился какой-нибудь достойный внимания репозиторий для web components? Я ни одного еще найти не смог.

PS. Надеюсь, remote modules не выпилят из js harmony. Этой фиче тут самое место.
Что вы имеете ввиду, говоря о «репозитории для web components»? Polymer разрабатывает элементы на основе web components. Та же команда, занимается написанием полифилов, которые имитируют части стандарта: custom elements, shadow dom и т.д.
Я имею в виду что-нибудь наподобие npm – ресурса, где можно:
* искать по названию/описанию компонентов
* фильтровать по тегам
* сортировать компоненты по количеству пользователей/зависимых компонент
* изучать дерево зависимостей
Для этого вполне подойдёт bower или component. Не думаю что есть смысл делать специализированный репозиторий только для кода на Web Components.
О, это в точности то, что я искал! Спасибо.
Составляющие стандарта Web Components описаны неплохо, но в чем, собственно, суть заголовка «Web Components — будущее Web»? Да и многое из того, что мы используем сейчас можно переиспользовать…
Новый стандарт возможно изменит подходы к написанию web-приложений на клиенте. Это основная мысль статьи, отсюда заголовок.

Переиспользовать вёрстку полноценно не можем. Нет механизмов инкапсуляции, ни стилей, ни фрагментов вёрстки.

Шаблоны, в том виде в котором они есть, это хак. Представьте, что в JS вы вместо того, чтобы использовать функции, вставляете их содержимое везде, где должны быть вызовы функций. Это примерно то что происходит сейчас с HTML и CSS.
Когда-нибудь мечтали о том, чтобы в HTML был тег <menu>

Зачем об этом мечтать, если он ещё со времён HTML 3.2 есть, а может и раньше был…
А в HTML 5 ещё и nav добавили…
Тут ещё и кастомные будут уже явным перебором.
Ну что ж вы так сразу с места в карьер… Тактичнее надо. :)
Про <menu> буду знать, спасибо. Хотя он кажется не особо используется.
Автор, скажите, как произошел термин «проекции»? В оригинале это «insertion points» — дословный перевод «точки вставки», «курсор». Я не спорю, перевод этого термина как «проекции» довольно точно отображает суть, но все же, это лично ваш вариант перевода или это подчерпнуто в каких-то документах?
Термин «проекция» используется в статьях о shadow dom, здесь например. Так называют процесс, который происходит при использовании insertion points.

Тег <content> создаёт insertion point, куда проецируется содержимое хоста.

Кое-где в W3C драфте также есть упоминания.
Ок, действительно процесс — это проецирование, проекция. Как по вашему мнению точнее перевести «insertion points»? «Точки проекции»?
Думаю, «точки вставки» точнее. Если бы они имели ввиду «точки проекции», было бы «projection points».
distribution — это процесс распределения содержимого хоста между insetion points. Распределение происходит с помощью атрибута select тега <content>. Как в этом примере (для просмотра нужен Chrome Canary со включенными флагами).

Допустим хост выглядит так:

  <article>bla bla</article>
  <div class="picture"></div>


Тогда мы можем проецировать не весь контент, а его части, в разные insertion points, например:

  <content select="article"></content>
  <figure>
    <content select=".picture"></content>
  </figure>
importNode() клонирует и «выполняет» разметку (начинает загружать картинки итд).
cloneNode() только клонирует, «выполнение» происходит при вставке клона в документ.

Когда что использовать зависит от ситуации. При прочих равных, я считаю, importNode() использовать логичнее.
Флаг chrome://flags/#enable-html-imports нынче отсутствует вовсе.

filipovskii.github.io/web-components-demo/wc-templates не завёлся
filipovskii.github.io/web-components-demo/wc-todo-demo не работает тоже

а за статью спасибо. крутые штуки
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации