Комментарии 33
Я правильно понял, что это опять разметка, стили и код в одну кучу?
Во всех примерах на странице стандарта, html/css/js в одной куче, но я не вижу принципиальных проблем при вынесении ресурсов во внешние файлы. Стандартом это явно не запрещается.
Например, в рассылке w3c приводили такой пример эмуляции
Возможность сделать так, это основная причина не вводить атрибут scoped для
Нужно дождаться реализации в Google Chrome и тогда уже можно говорить что-то конкретное.
Например, в рассылке w3c приводили такой пример эмуляции
<style scoped> для <link rel="stylesheet" />:<style scoped>
@import url('/css/styles.css');
</style>
Возможность сделать так, это основная причина не вводить атрибут scoped для
<link rel="stylesheet" />.Нужно дождаться реализации в Google Chrome и тогда уже можно говорить что-то конкретное.
Не могли бы вы посвятить пару абзацев объяснению, что это и зачем? Это убийца HTML? Почему оно должно стать трендом?
Это ни в коей мере не убийца HTML. Возможно я напишу статью про то зачем нужны веб-компоненты.
Но, как минимум, вам никогда не хотелось сделать
Сейчас я могу порекомендовать посмотреть видео Google I/O 2012 — The Web Platform's Cutting Edge.
Но, как минимум, вам никогда не хотелось сделать
<input type=calendar>? Или свой собственный <select>? Причём с fallback'ом для старых браузеровСейчас я могу порекомендовать посмотреть видео Google I/O 2012 — The Web Platform's Cutting Edge.
Хотелось и делал как на чистом JS, так и jQuery-плагином. И многие делали.
Это плохой пример, подавайте другой!
Это плохой пример, подавайте другой!
Мы все люди занятые, а сегодня вообще выходной и честно, у меня нету сейчас времени придумывать и описывать пример, который для вас покажется «хорошим». На вскидку это: виджеты — Google+ Галерея, shared-файлы dropbox, Google Talk Chat на любом сайте; элементы —
В данном случае, я сделал перевод стандарта, который лично меня заинтересовал. Это и так была тяжелая работа, я ещё в комментариях доказывать, что парни из Google не недальновидны — это уж слишком.
<input type=calendar>, <input type=barcode>; и т.д.В данном случае, я сделал перевод стандарта, который лично меня заинтересовал. Это и так была тяжелая работа, я ещё в комментариях доказывать, что парни из Google не недальновидны — это уж слишком.
Во-первых, это перевод драфта, который просто драфт.
И лейбл «Я из Google» не делает каких-то двоих чуваков гениями, но многие начинают их такими считать.
И лейбл «Я из Google» не делает каких-то двоих чуваков гениями, но многие начинают их такими считать.
Это драфт, который презентовали на Google I/O 2012, а я презентовал его хабрасообществу. В чем вы видите проблему?
Проблема в понимании, точнее в его отсутствии. Если Вы просто увидели что-то новое «от гугла» и, не пытаясь понять что это и зачем, перевели на русский — спасибо за перевод и больше вопросов к Вам нет. Но я предполагаю, что если кто-то, не являющийся профессиональным переводчиком, берётся что-то переводить, тем более что-то новое и не тривиальное, то это вызвано тем, что он понимает то, что переводит, и ему оно нравится.
Поскольку после прочтения Вашего перевода у меня не появилось понимания что это и зачем (как и у многих других комментирующих Ваш перевод), то возникает вполне логичное желание попросить автора перевода это объяснить — опять же, предполагая что он сам это уже понимает.
Какую проблему решает этот стандарт? Реальная это проблема, или надуманная? Есть ли другие подходы к решению этой проблемы? Чем этот стандарт от них отличается (плюсы и минусы)? — Если Вы можете ответить на эти вопросы, то это стоило сделать, вероятно, в начале статьи. Иногда эти ответы очевидны, но, судя по текущим комментариям — это не тот случай.
Поскольку после прочтения Вашего перевода у меня не появилось понимания что это и зачем (как и у многих других комментирующих Ваш перевод), то возникает вполне логичное желание попросить автора перевода это объяснить — опять же, предполагая что он сам это уже понимает.
Какую проблему решает этот стандарт? Реальная это проблема, или надуманная? Есть ли другие подходы к решению этой проблемы? Чем этот стандарт от них отличается (плюсы и минусы)? — Если Вы можете ответить на эти вопросы, то это стоило сделать, вероятно, в начале статьи. Иногда эти ответы очевидны, но, судя по текущим комментариям — это не тот случай.
Проблема есть. Она заключается в необходимости модульного описания определённого элемента веб-интерфейса. Чтобы для него был механизм описания разметки, стилей и логики.
И тут начинаются нюансы. С одной стороны хочется чтобы оно было «в одном месте», с другой стороны когда оно в одном месте, не так уж и радует потому что «как-то в кучу».
Это «новое от гугла» похоже одна из попыток решить проблему. У меня в процессе чтения возникло как-раз ощущение «как-то в кучу всё».
И тут начинаются нюансы. С одной стороны хочется чтобы оно было «в одном месте», с другой стороны когда оно в одном месте, не так уж и радует потому что «как-то в кучу».
Это «новое от гугла» похоже одна из попыток решить проблему. У меня в процессе чтения возникло как-раз ощущение «как-то в кучу всё».
Я слежу за этой технологией уже почти год и понимаю зачем и для чего она нужна. После презентации Гуглом, я решил поделится я сообществом.
Примеры использования данной технологии достойны отдельной статьи, которую я возможно напишу в ближайшее время, после того, как закончу с переводом и узнаю ответы на некоторые вопросы озвученные тут в обсуждении у разработчиков стандарта.
Поймите меня правильно, пока данный стандарт не реализован в Хроме, я не могу отвечать на вопросы в реал-тайме, а вопросы будут.
Примеры использования данной технологии достойны отдельной статьи, которую я возможно напишу в ближайшее время, после того, как закончу с переводом и узнаю ответы на некоторые вопросы озвученные тут в обсуждении у разработчиков стандарта.
Поймите меня правильно, пока данный стандарт не реализован в Хроме, я не могу отвечать на вопросы в реал-тайме, а вопросы будут.
… пока данный стандарт не реализован в Хроме…
Этот момент не очень понятен. У Вас по этому поводу какая информация есть?
Просто до какого-то уровня стандарт там уже, похоже, рализован, т.к. есть dart-web-components.
Или Вы ждете реализации хотя бы в dev-канале?
Я этого тоже не понял. Пока это выглядит как попытка запихнуть что-то подобное XML + XSLT в один файл и сверху приправить JS для наглядности. Смысла не вижу.
это попытка XBL (http://www.w3.org/TR/xbl/), который реализован и обкатан в мозилле, но никто не собирается его поддерживать, переложить на html5. получилась хрень, потому как:
1. нет возможности плавной деградации для не поддерживающих эту технологию браузеров, а также нет возможности сделать js-эмуляцию оной (xbl можно транслировать в htc и сделать эмуляцию на js, но с некоторыми ограничениями)
2. описание компонент идёт прямо в html, а не выносится в отдельные подключаемые кэширующиеся ресурсы (в xbl это выносится by design)
3. крайний примитивизм шаблонов (в xbl не сильно лучше)
4. пихание разных языков (js, css, html) в одну кучу без возможности разнести их по отдельным файлам (в xbl даже хуже — необходимо амперсанды в js экранировать).
5. сволочи, они украли у меня название мета-фреймворка)
зато очень в тренде «html5» который стал символом велосипеда. или наоборот о0
1. нет возможности плавной деградации для не поддерживающих эту технологию браузеров, а также нет возможности сделать js-эмуляцию оной (xbl можно транслировать в htc и сделать эмуляцию на js, но с некоторыми ограничениями)
2. описание компонент идёт прямо в html, а не выносится в отдельные подключаемые кэширующиеся ресурсы (в xbl это выносится by design)
3. крайний примитивизм шаблонов (в xbl не сильно лучше)
4. пихание разных языков (js, css, html) в одну кучу без возможности разнести их по отдельным файлам (в xbl даже хуже — необходимо амперсанды в js экранировать).
5. сволочи, они украли у меня название мета-фреймворка)
зато очень в тренде «html5» который стал символом велосипеда. или наоборот о0
1. Эта тема для progressive enhancement, то есть все должно работать изначально без этого, а эта тема добавляет плюшки.
2. Выносится и подключается через <link rel=«components» href=«enhancements.html»>
3. Видимо это потому что эти шаблоны оборачивают существующий markup или его части.
4. Все то же самое что и html
Мне кажется у данной идеи другие проблемы, основная — слишком запутанно и сложно. В примерах все замечательно, но если представить что таким образом будет собран большой проект… В любом случае, сейчас это на уровне идеи — поглядим к чему это придет.
2. Выносится и подключается через <link rel=«components» href=«enhancements.html»>
3. Видимо это потому что эти шаблоны оборачивают существующий markup или его части.
4. Все то же самое что и html
Мне кажется у данной идеи другие проблемы, основная — слишком запутанно и сложно. В примерах все замечательно, но если представить что таким образом будет собран большой проект… В любом случае, сейчас это на уровне идеи — поглядим к чему это придет.
1. да как ни обзывай — там этого нет. по стандарту содержимое template не должно рендериться, но текущие браузеры ничего про template не знают и рендерить будут. аналогично со style scoped — стили будут применяться ко всему документу. и тому подобные несоместимости. а раз уж мы делаем несоместимо, то можно сделать и по уму, а не притягивать за уши префикс «x-» или дважды указывать, что x-fancybutton является расширением button и кидать ошибку, если разработчик это недокопипастил.
2. тогда возникает вопрос: чем эта поделка лучше xbl или htc? потому что они обладают всем известным «фатальным недостатком»? ещё опере надо реализовать свои «компоненты» и тогда у каждого движка будет своя их реализация)
3. ну да, и из-за этого приходится городить кучу костылей — сначала рендерим шаблон, а потом скриптом его перефигачиваем.
2. тогда возникает вопрос: чем эта поделка лучше xbl или htc? потому что они обладают всем известным «фатальным недостатком»? ещё опере надо реализовать свои «компоненты» и тогда у каждого движка будет своя их реализация)
3. ну да, и из-за этого приходится городить кучу костылей — сначала рендерим шаблон, а потом скриптом его перефигачиваем.
Суперская вещь.
Это очень похоже на wpf/xaml подход. Это наверное лучшее решение в плане работы с разметкой на текущий момент.
Там элементы несут на себе только одну ответственность: логический элемент в разметке. То есть мы знаем что кнопка ведет себя как кнопка: ее можно кликнуть, но визуально она может выглядеть как угодно: например как дроп даун. Там есть понятие style — которое примерно соответствует css в html. И понятие template — которое соответствует декоратору из статьи и позволяет определить визуальное отображение любого элемента. Также можно определять свои смысловые элементы с собственным поведением.
То есть в html мы сможем абстрагироваться от того как выглядят те или иные элементы и только думать о том, какой по смыслу элемент выбрать в рамках данной разметки. Дальше передаем дизайнеру и он сможет превратить этот смысловой элемент во что хочет. Решение позволит реально отделить труд дизайнера и верстальщика/веб программиста.
И позволит создавать элементы с кастомным поведением, что облегчит архитектуру любого web проекта.
Единственное — в данный момент предложенное решение выглядит не очень опрятно из-за ограничений текущего примитивного html подхода к верстке. Жаль что декораторы не смогут запускать скрипты и определять редактирование элемента.
Но вообще я уверен, что примерно так и будет выглядеть html в будущем.
Это очень похоже на wpf/xaml подход. Это наверное лучшее решение в плане работы с разметкой на текущий момент.
Там элементы несут на себе только одну ответственность: логический элемент в разметке. То есть мы знаем что кнопка ведет себя как кнопка: ее можно кликнуть, но визуально она может выглядеть как угодно: например как дроп даун. Там есть понятие style — которое примерно соответствует css в html. И понятие template — которое соответствует декоратору из статьи и позволяет определить визуальное отображение любого элемента. Также можно определять свои смысловые элементы с собственным поведением.
То есть в html мы сможем абстрагироваться от того как выглядят те или иные элементы и только думать о том, какой по смыслу элемент выбрать в рамках данной разметки. Дальше передаем дизайнеру и он сможет превратить этот смысловой элемент во что хочет. Решение позволит реально отделить труд дизайнера и верстальщика/веб программиста.
И позволит создавать элементы с кастомным поведением, что облегчит архитектуру любого web проекта.
Единственное — в данный момент предложенное решение выглядит не очень опрятно из-за ограничений текущего примитивного html подхода к верстке. Жаль что декораторы не смогут запускать скрипты и определять редактирование элемента.
Но вообще я уверен, что примерно так и будет выглядеть html в будущем.
А как же первое правило разработки интерфейсов — интуитивность? Кнопка должна выглядеть как кнопка.
Ну самый простой пример: кнопка которая выглядит как ссылка. Это часто может быть адекватно в рамках определенного стиля. Другой пример: чек бокс в виде текста или картинки. То есть кликаете на зеленую картинку — скажем какой то процесс запустился и картинка сменилась на красную, кликаете еще раз — процесс остановился и картинка сменилась на зеленую.
В принципе правило будет работать — вопрос лишь в том, что такое интуитивный интерфейс. Например интерфейс ribbon в msoffice сильно отличается от интерфейсов предыдущего поколения. Но прошло время, люди привыкли и теперь он уже интуитивен. Многие офисные приложения даже в вебе используют этот стиль.
Я себе так все вижу что крупные игроки в вебе будут диктовать такие «интуитивные» стили. И они будут разными по крайней мере для разных сфер деятельности веб сервисов.
Главное чтобы они вообще могли эволюционировать хоть как то. В данный момент html загоняет в очень узкие рамки.
В принципе правило будет работать — вопрос лишь в том, что такое интуитивный интерфейс. Например интерфейс ribbon в msoffice сильно отличается от интерфейсов предыдущего поколения. Но прошло время, люди привыкли и теперь он уже интуитивен. Многие офисные приложения даже в вебе используют этот стиль.
Я себе так все вижу что крупные игроки в вебе будут диктовать такие «интуитивные» стили. И они будут разными по крайней мере для разных сфер деятельности веб сервисов.
Главное чтобы они вообще могли эволюционировать хоть как то. В данный момент html загоняет в очень узкие рамки.
Чё-то разработчикам Google совсем там скучно и клонит придумать какой-нить mess.
Половина примеров кода в драфте выглядит абсурдно и даже поясняется не менее абсурдными комментариями.
Я пытался понять всё это, но, пожалуй, я продолжу работать по уютной старинке :-)
Половина примеров кода в драфте выглядит абсурдно и даже поясняется не менее абсурдными комментариями.
Я пытался понять всё это, но, пожалуй, я продолжу работать по уютной старинке :-)
Не хочется дублировать текст, ответил выше.
habrahabr.ru/post/152001/#comment_5161636
habrahabr.ru/post/152001/#comment_5161636
Я там тоже ответил.
Егор, а какой Ваш основной профиль?
На чём писали последние пару-тройку лет?
Егор, а какой Ваш основной профиль?
На чём писали последние пару-тройку лет?
Такие вопросы в личку
Также всю нужную информацию вы можете узнать из моих профилей на хабре и github
Да, я уже изучил код на Гитхабе.
И желания что-то обсуждать у меня больше не осталось :))
И желания что-то обсуждать у меня больше не осталось :))
Очень интересная штука, натыкался пару месяцев назад на демо с подключением индикатора загрузки таким образом, надеюсь что идея приживется.
Здорово, конечно. Но маловероятно, что это:
а) есть стандарт и он будет реализован во всех броузерах
а) «может стать трендом в ближайшие несколько лет»
Ни HTC (Internet Explorer <9.0), ни XBL (Gecko <1.9), ни XBL2 (тоже стандарт! и тоже от Google) трендами не стали, выглядили тем не менее более красиво.
Да, похожий велосипед, но работающий во всех броузерах: Ample SDK
а) есть стандарт и он будет реализован во всех броузерах
а) «может стать трендом в ближайшие несколько лет»
Ни HTC (Internet Explorer <9.0), ни XBL (Gecko <1.9), ни XBL2 (тоже стандарт! и тоже от Google) трендами не стали, выглядили тем не менее более красиво.
Да, похожий велосипед, но работающий во всех броузерах: Ample SDK
www.youtube.com/watch?v=JNjnv-Gcpnw
github.com/dglazkov/Web-Components-Polyfill/
Везде, где будет реализован ShadowDOM, возможна реализация Web-Components на js
github.com/dglazkov/Web-Components-Polyfill/
Везде, где будет реализован ShadowDOM, возможна реализация Web-Components на js
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Введение в веб-компоненты. Часть 1