Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 73
У меня есть на примете более подробная заметка на эту тему. Если тема пойдет хорошо, могу её перевести.
Шляпа какая-то. Изобрели AJAX, который мало того, что не менее «утомительный», так еще и работает чуть менее, чем нигде.
Как мы только раньше жили?
Также, при помощи этого же тега, мы можем подключать CSS и JavaScript. (Жить стало намного лучше.)
Как мы только раньше жили?
Вы существенно ошибаетесь. Такие импорты широко используются с веб-компонентами (Polymer в частности), которые позволяют поместить отдельный компонент с полностью изолированной разметкой, обработчиками и стилями в отдельный файл. А потом вставить одним тегом готовый элемент на страницу.
Это будущее веба, рекомендую ознакомиться. Возможно, этот пример не так нагляден — но на практике это и правда удобно, и нативная поддержка браузерами появляется, а с полифилами веб-компоненты уже можно использовать во всех современных браузерах, даже в IE.
Говорю как человек, который уже это использует некоторое время.
Это будущее веба, рекомендую ознакомиться. Возможно, этот пример не так нагляден — но на практике это и правда удобно, и нативная поддержка браузерами появляется, а с полифилами веб-компоненты уже можно использовать во всех современных браузерах, даже в IE.
Говорю как человек, который уже это использует некоторое время.
Я помню еще лет 10 назад нам этот рай обещали это все в Java Server Faces.
По каким-то причинам, это будущее имеет свои ограничения в реальных проектах — например — желание некой консистентности UI внутри сайта.
Но затея хороша, хотя и не обязательно должна реализовываться отдельными, динамически подгружаемыми css на каждый кусок.
По каким-то причинам, это будущее имеет свои ограничения в реальных проектах — например — желание некой консистентности UI внутри сайта.
Но затея хороша, хотя и не обязательно должна реализовываться отдельными, динамически подгружаемыми css на каждый кусок.
Так вся красота в том, что потом можно сделать рестайлинг элементов. Эти кастомные элементы — как нативные элементы браузера. Они имеют предопределенный внешний вид, свои события, и всё это можно контролировать. С другой стороны, то что внутри элемента наружу не вылазит. Уже сейчас в Chromium/Chrome стандартные элементы сделаны так же как и кастомные — можно посмотреть их ShadowDOM и как они устроены, теперь всё подчиняется стандартным правилам, не зависимо от происхождения элемента.
Для начала поясню, что мое мнение, как и вопросы, основаны исключительно на данном посте.
Что подразумевается под полной изоляцией? Пока что я не вижу различий между описанной технологией и давно обкатанным AJAX. Есть два документа. В один мы можем вставить другой (или часть его). С помощью все того же JS. С теми же кросс-доменными ограничениями. Какие конкретно преимущества предоставляет описанный HTML-импорт?
Что подразумевается под полной изоляцией? Пока что я не вижу различий между описанной технологией и давно обкатанным AJAX. Есть два документа. В один мы можем вставить другой (или часть его). С помощью все того же JS. С теми же кросс-доменными ограничениями. Какие конкретно преимущества предоставляет описанный HTML-импорт?
Переходим на следующий уровень
Например, вы стилизируете все списки внутри импортируемой разметки, но это не влияет на остальные списки, которые есть на странице.
Такая инкапсуляция упрощает контроль над версткой, позволяет легко избегать конфликтов.
И да, импорт браузер делает сам, нативно, это не AJAX. И не грузит, например, картинки пока они не отображаются в основном DOM.
Мне кажется, или сейчас речь об атрибуте scope тега style, и он не имеет прямого отношения к HTML-импорту?
Да, но вы понимаете, что стилей может быть несколько, скриптов тоже, и для того чтобы подключить всю эту каше достаточно сделать один импорт?
Вам не нужно думать как бы правльно его загрузить, чтобы выполнить JS только раз, где всё это хранить.
А тут у вас нативный DOM, который быстрый, и делает многое за вас.
Вам не нужно думать как бы правльно его загрузить, чтобы выполнить JS только раз, где всё это хранить.
А тут у вас нативный DOM, который быстрый, и делает многое за вас.
Может ошибаюсь, но, по-моему, в Яндексе для этого БЭМ придумали. Он немного ломает голову в плане разработки элементов, но, на мой взгляд, это лучше, чем писать scope стили в разметку. К тому же после сборки все элементы сразу оказываются в готовой странице и не надо их тянуть магическими линками, что явно будет медленнее. Это что до инкапсулированных элементов управления.
А для асинхронной погрузки кусков действительно существует AJAX.
А для асинхронной погрузки кусков действительно существует AJAX.
Да, но вы понимаете, что стилей может быть несколько, скриптов тоже, и для того чтобы подключить всю эту каше достаточно сделать
iframe, правда? На пустом месте городить новый инструмент там, где с задачей отлично справлялись два других (для разных целей — разный инструмент). Нет, ну правда, ни в статье ни в комментариях нет ни малейшего бонуса от предлагаемого способа по сравнению с ajax/iframe.
Не правда если вы понимаете ограниченность и неудобство iframe (например, стилизация и обработка событий). В статье это не раскрыто полностью так как используется только один аспект — импорты. Если добавить второй — Web Components, то становится возможно легко и непринужденно заменить <input> на <paper-input>, который очень похож по свойствам и поведению на родной элемент браузера. Просто изменив тэг вы получите вот такие текстовые поля:
www.polymer-project.org/components/paper-elements/demo.html#paper-input
Для подключения нужно лишь добавить в коде:
Все зависимости компонента будут загружены автоматически (с помощью тех же самых импортов внутри него).
www.polymer-project.org/components/paper-elements/demo.html#paper-input
Для подключения нужно лишь добавить в коде:
<link href="paper-input.html" rel="import">
Все зависимости компонента будут загружены автоматически (с помощью тех же самых импортов внутри него).
Да, я не понимаю «ограниченность и неудобство iframe» — чего там за проблемы со стилизацией и обработкой событий? Никаких нерешаемых не видел — можете описать подробно?
Очень странно вы рассуждаете)) Вы видемо действительно не понимаете суть Веб компонентов, потому как для меня ваши доводы сравнимы с: «Мы итак неплохо забиваем гвозди камнем! Зачем нам еще молоток придумали?»))))
А если серьезно, то говорить об импорте отдельно от самих Веб компонентов только людей путать.
А если серьезно, то говорить об импорте отдельно от самих Веб компонентов только людей путать.
ps/ так и не дал ответа на ваш впорос )))
Сравнивать Web components, iframe и ajax вместе просто не этично, ведь и функционально и по смыслу они совершенно разные. Ajax — просто асинхронные запросы из браузера (причем преимущественно к своему же домену, отсюда и Cross-domain policy, хоть от нее и начинают отходить), iframe — дает возможность помещать полностью независимые документы как часть родительского(в первую очередь внешние к данному ресурсу, отсюда и слабости в возможностях взаимодействия с ним, согласитесь postMessage не слишком удобен), а Web components — это просто песня!))))
Но раз уж сравнение произошло, то попробую описать разницу.
1) Если мы говорим об ajax-запросе, который получает кусок html разметки для вставки в DOM текущего документа, то особенности этого очевидны. Этот кусок разметки не имеет ни малейшей инкапсуляции и является просто новой частью документа. Все новые стили и скрипты воздействуют на него, а его собственные стили и скрипты — на весь документ.
2) iframe — это супер инкапсуляция, а точнее вообще отдельный документ, со своим DOM, скриптами, стилями вообще всем. Но и грузите вы туда всегда лишнего, например базовые стили вашего дизайна. Управлять этой штукой также не очень то удобно, да и представить себе страницу полностью состоящую из iframe'ов можно только в далеких 90-х — начала 2000. Сейчас вряд ли.
3) web component — функционально это смесь первых двух подходов, т.е. с одной стороны компонент инкапсулирует в себя стили, скрипты и разметку, с другой стороны является полноценной частью текущего документа, т.е. встроена в текущий DOM, но имеет свой собственный ShadowDOM (примеры audio и video теги html5).
Надеюсь понятно объяснил))))
Сравнивать Web components, iframe и ajax вместе просто не этично, ведь и функционально и по смыслу они совершенно разные. Ajax — просто асинхронные запросы из браузера (причем преимущественно к своему же домену, отсюда и Cross-domain policy, хоть от нее и начинают отходить), iframe — дает возможность помещать полностью независимые документы как часть родительского(в первую очередь внешние к данному ресурсу, отсюда и слабости в возможностях взаимодействия с ним, согласитесь postMessage не слишком удобен), а Web components — это просто песня!))))
Но раз уж сравнение произошло, то попробую описать разницу.
1) Если мы говорим об ajax-запросе, который получает кусок html разметки для вставки в DOM текущего документа, то особенности этого очевидны. Этот кусок разметки не имеет ни малейшей инкапсуляции и является просто новой частью документа. Все новые стили и скрипты воздействуют на него, а его собственные стили и скрипты — на весь документ.
2) iframe — это супер инкапсуляция, а точнее вообще отдельный документ, со своим DOM, скриптами, стилями вообще всем. Но и грузите вы туда всегда лишнего, например базовые стили вашего дизайна. Управлять этой штукой также не очень то удобно, да и представить себе страницу полностью состоящую из iframe'ов можно только в далеких 90-х — начала 2000. Сейчас вряд ли.
3) web component — функционально это смесь первых двух подходов, т.е. с одной стороны компонент инкапсулирует в себя стили, скрипты и разметку, с другой стороны является полноценной частью текущего документа, т.е. встроена в текущий DOM, но имеет свой собственный ShadowDOM (примеры audio и video теги html5).
Надеюсь понятно объяснил))))
Я рассуждаю не странно: что было в статье обдумал и пришёл к выводу, что бенифита мне не показали. О нём и спрашивал.
Не использую edge-технологии в вебе, не могли бы вы пояснить бонусы от инкапсуляции стилей и скриптов в мелкие элементы? Пока не сталкивался со случаем, когда это действительно требовалось.
Не использую edge-технологии в вебе, не могли бы вы пояснить бонусы от инкапсуляции стилей и скриптов в мелкие элементы? Пока не сталкивался со случаем, когда это действительно требовалось.
Ну так вы изучите сперва вопрос, прежде чем комментарии писать.))) Считаю что статьи на Хабре это как сигналы к действию. Они позволяют поспевать за технологиями, хотя бы относительно. Например эта статья не содержит информации более полезной, чем просто сообщить о существовании подобных стандартов, далее каждый сообразно своей любознательности может раскопать нужную информацию. Кстати на хабре про компоненты были очень даже неплохие стати уже.
Хочу уточнить, вы когда-нибудь разрабатывали толстые javascript клиенты, типа SPA?
Не использую edge-технологии в вебе, не могли бы вы пояснить бонусы от инкапсуляции стилей и скриптов в мелкие элементы? Пока не сталкивался со случаем, когда это действительно требовалось.
Хочу уточнить, вы когда-нибудь разрабатывали толстые javascript клиенты, типа SPA?
Что из этих SPA вы имели в виду?.. Или вы имеете в виду SinglePageApplication?
А вообще про толстые клиенты на js (если я правильно понимаю, что вы под этим подразумеваете) — сейчас как раз делаю одну программку: шаблонизаторы (handlebars) + языки стилей (stylus) + модульное написание js — наше всё.
Результат, как мне кажется — более предсказуемый, нежели использование WebComponents (по крайней мере в том виде, который я смог почерпнуть в этой статье). Хотя да, чужие компоненты использовать сложнее.
А вообще про толстые клиенты на js (если я правильно понимаю, что вы под этим подразумеваете) — сейчас как раз делаю одну программку: шаблонизаторы (handlebars) + языки стилей (stylus) + модульное написание js — наше всё.
Результат, как мне кажется — более предсказуемый, нежели использование WebComponents (по крайней мере в том виде, который я смог почерпнуть в этой статье). Хотя да, чужие компоненты использовать сложнее.
Да, именно Single Page Application, конечно) Обычно еще используется один из MV* фреймверков (BackboneJS, AngularJS etc). Так вот чем толще становится такой клиент, тем больше возникает желание использовать WebComponent'ы. Лично я буду юзать Polymer в следующем своем проекте. Ну и конечно история веб компонентов это история создания переиспользуемых компонент для разных проектов.
Ну в целом в такой ситуации вполне логично (я всё-таки бекэндщик, FE для меня больше хобби), что для меня edge таких технологий не очень известен. Потому и спрашиваю много, чтобы лучше понимать юз-кейс технологии. Потому и удивляюсь её полезности, что модульность в java/… языках бекэнда — хлеб и кровь. Но всё же это выглядит как обычный js-оформленный инклюд :)
Для подключения нужно лишь добавить в кодеНо ведь не правда же! У вас помимо этого «нужно лишь» будет еще дополнительный код, который подцепит результат импорта в нужное место. И если это делать как в статье выше — никаких дополнительных фич по сравнению с обычным AJAX вы не получите.
А как же WebComponents? Собственно говоря то же самое, да ещё и под ShadowRoot'ом и точками входа для кастомизации.
HTML-файлы или файлы HTMLТак это пишется по-русски.
HTML-импорт, HTML-документы
CSS- и JavaScript-файлы
10 лет назад было
jQuery('<div></div>').load('/intro.html#intro-dm').appendTo('body');
jquery был, если не изменяет память, 7-8 лет назад, но не 10.
Хотя то же самое руками сделать было, естественно, возможно.
Хотя то же самое руками сделать было, естественно, возможно.
[ЗанудаMode=On]
jQuery('<div />')
Я учился верстать в монастыр с XHTML, а не в борде с HTML5, потому не поставить закрывающий слэш для одинарного тега или поставить его без пробела — это святотатство, и никакая экономия злосчастного байта не отмоет потом мою карму :)
php include вроде был же
То есть без JS сие работать не будет? Печально.
Реализовал платформу, которая как раз использует последовательную подгрузку пользовательского интерфейса из «экранов» — пакета, содержащего html, js и css и представляющего некоторую часть интерфейса, большую чем просто виджет, но меньшую чем полноценная вьюха. Реализовывал на базе Yahoo UI 3 и вполне доволен. Это хорошая техника, но кроссбраузерность за горами.
Реализовал платформу, которая как раз использует последовательную подгрузку пользовательского интерфейса из «экранов» — пакета, содержащего html, js и css и представляющего некоторую часть интерфейса, большую чем просто виджет, но меньшую чем полноценная вьюха. Реализовывал на базе Yahoo UI 3 и вполне доволен. Это хорошая техника, но кроссбраузерность за горами.
Кроссбраузерные HTML инклуды: habrahabr.ru/post/90373/
поддержка браузерами?
когда дочитал о необходимости js, то сразу погрустнел
когда дочитал о необходимости js, то сразу погрустнел
Поддержка стремится к "нулю".
Интересно что о таком импорте думают поисковые роботы
Не по теме. В который раз поражаюсь, как всё-таки дико читаются переведённые тексты. Возможно, они верны с точки зрения русского языка, но мысли в них излагаемые выглядят чужеродно. Может быть, действительно иностранцы как-то иначе думают, чем русские?
Это проблема не иностранных текстов, а переводчиков. Строго дословные переводы, как у автора, действительно часто тяжело воспринимать. Оригинал воспринимается проще.
Вы прочитайте оригинал, а потом судите о дослованости перевода. Я перевел совсем не дословно, но попытался сохранить стиль. Оригинал написан с довольно странными выражениями. Если бы пост изначально был написан на русском, то все бы понимали, что автор хотел украсить свой текст необычными предложениями.
Для примера:
iFrames can be fascinatingly frustrating to work with.
iFram'ы могут быть удивительно разочаровывающими, когда с ними приходится работать.
Дословно было бы: iFram'ы могут быть очаровывающе разочаровывающими для работы.
Для примера:
iFrames can be fascinatingly frustrating to work with.
iFram'ы могут быть удивительно разочаровывающими, когда с ними приходится работать.
Дословно было бы: iFram'ы могут быть очаровывающе разочаровывающими для работы.
Оба варианта — так называемый «дословный» перевод.
Литературный (в зависимости от контекста) вариант — При работе с ифреймами вы можете быть весьма разочарованы. Но это в отрыве от конкретной статьи.
В целом же абзац при литературном переводе может быть переведён как:
Литературный (в зависимости от контекста) вариант — При работе с ифреймами вы можете быть весьма разочарованы. Но это в отрыве от конкретной статьи.
В целом же абзац при литературном переводе может быть переведён как:
Старые трюки
IFrame — один из старых способов включения. К сожалению он реализован как отдельное тяжеловесное окно с собственным контекстом. Это приводит к проблема при попытках манипуляций с его контентом и его отображением. Это разочаровывает.
Второй популярный способ — AJAX. В этом случае включение производится с помощью JS — контент подгружается и вставляется скриптом. Не очень удобный и часто утомительный способ.
С оригиналом данного поста не знаком, сужу по предыдущим, которые читал в оригинале до появления перевода и после имел возможность сравнить.
«Очаровывающе разочаровывающие для работы» — это уже больше похоже на не совсем корректный перевод, чем на дословный, ибо без обратного перевода, хотя бы подсознательного, становится трудно понять, о чем вообще речь.
Чтобы текст был более живым, иногда приходится вносить куда большие коррективы, включая полное синтаксическое перестроение предложений или изменение их порядка. Не говорю уже о значительно более вольных вариантах перевода, чем обычно грешу я.
Не подумайте, не со злым умыслом это пишу. Живые и «близкие по духу» тексты людям читать гораздо приятнее. А вы же пишете для людей?
«Очаровывающе разочаровывающие для работы» — это уже больше похоже на не совсем корректный перевод, чем на дословный, ибо без обратного перевода, хотя бы подсознательного, становится трудно понять, о чем вообще речь.
Чтобы текст был более живым, иногда приходится вносить куда большие коррективы, включая полное синтаксическое перестроение предложений или изменение их порядка. Не говорю уже о значительно более вольных вариантах перевода, чем обычно грешу я.
Не подумайте, не со злым умыслом это пишу. Живые и «близкие по духу» тексты людям читать гораздо приятнее. А вы же пишете для людей?
В час ночи, больше стараешься донести основной смысл, а не красоту текста) Но все равно, спасибо за подсказку, буду пытаться улучшить стиль переводов
Во-первых, никто ж не торопит и не заставляет. Во-вторых, донести сам смысл — это и самое главное в переводе, и самое простое для формирования нестрогих переводов. Прочитали абзац в оригинале — переключились на редактор и передали смысл. Так и вероятность использования несвойственных языку конструкций уменьшается, и приходит осознание непонимания какого-то момента в тексте после первого прочтения (если это непонимание имеет место).
Когда-то вел собственный сайт-блог с уроками для начинающих веб-мастеров. И тоже подумывал о необходимости подобной технологии, я представлял что-то в виде песочницы, где собственные стили и элементы и весь этот колхоз выводится на целевой странице. Т.к., например, описывал я методы работы с таблицами в HTML, описал голую таблицу и хотел показать на странице своего сайта, как должна выглядеть таблица в браузере пользователя так, если бы она была на пустой странице, но на таблицу упорно накладывались некоторые CSS-селекторы стилей сайта. Приходилось извращаться лишними классами.
подобные механизмы есть уже в нескольких реализациях:
github.com/component/component/wiki/F.A.Q
и
webpack.github.io/
подход component мне нравится больше. И не нужно под это тянуть целый БЭМ и даже его придумывать.
github.com/component/component/wiki/F.A.Q
и
webpack.github.io/
подход component мне нравится больше. И не нужно под это тянуть целый БЭМ и даже его придумывать.
Эти инструменты — упаковщики ассетов. Они никак не решают проблемы общих стилей между всеми компонентами страницы.
Что нужно, чтобы веб-компоненты по-настоящему взлетели — это поддержка shadow dom во всех целевых браузерах. И даже не вся спецификация, а поддержка независимых стилей в shadowRoot.
АНБ — идея, которая лежит в основе БЭМ как раз эту проблему пытается решить в полевых условиях, так что тулзы типа component / webpack и АНБ — это инструменты, которые в связке прямо сейчас могут решать задачу создания веб-компонентов.
Что нужно, чтобы веб-компоненты по-настоящему взлетели — это поддержка shadow dom во всех целевых браузерах. И даже не вся спецификация, а поддержка независимых стилей в shadowRoot.
АНБ — идея, которая лежит в основе БЭМ как раз эту проблему пытается решить в полевых условиях, так что тулзы типа component / webpack и АНБ — это инструменты, которые в связке прямо сейчас могут решать задачу создания веб-компонентов.
А когда происходит такой импорт — происходит дополнительный запрос к серверу, как я полагаю. Для оптимизации все скрипты, стили картинки сжимаются в один файл, а тут как-то наоборот получается…
Честно говоря не понял, почему не дошли до логически завершенного варианта: где импорт происходит, там этот импорт сам и отображается по-дефолту, если в каком-то его параметре нет запрета автоматической отрисовки.
Не вижу большой разницы с тем, чтобы (раз всё равно потребуется js) получить содержимое любым иным способом и опять-таки тем же body.appendChild вставлять куда хочется.
Можно даже написать универсальный простейший скрипт, который обходит теги определённого класса, и из дата-атрибута подгружает содержимое. С теми же ограниченными стилями и прочим.
Я не понимаю отличий и выгоды. В чем они? Из статьи очевидности простоты не следует. На самом очевидном месте, вдруг потребовался javascript. Если уж делать импорт, то пусть он работает так же как и в случаях с внешними js и css линками, и даже картинками — т.е. подгрузил и использовал в том же самом месте.
Вобщем я коцепцию не уловил, если кто мне объяснит — буду благодарен.
Не вижу большой разницы с тем, чтобы (раз всё равно потребуется js) получить содержимое любым иным способом и опять-таки тем же body.appendChild вставлять куда хочется.
Можно даже написать универсальный простейший скрипт, который обходит теги определённого класса, и из дата-атрибута подгружает содержимое. С теми же ограниченными стилями и прочим.
Я не понимаю отличий и выгоды. В чем они? Из статьи очевидности простоты не следует. На самом очевидном месте, вдруг потребовался javascript. Если уж делать импорт, то пусть он работает так же как и в случаях с внешними js и css линками, и даже картинками — т.е. подгрузил и использовал в том же самом месте.
Вобщем я коцепцию не уловил, если кто мне объяснит — буду благодарен.
Перевод ужасный, запятые не на месте, читать невозможно.
Садитесь, два.
Садитесь, два.
Пишу из 2018, html import до сих пор не работает в доброй половине браузеров
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Что такое HTML импорт и как это работает?