эээ, оно работает
там 14 элементов, это не попадает под условие «кратно трем» и не попадает под условие «не кратно трем и нечетное».
Если хотите — я сделал другой пример, с ним тоже можно поиграться.
Три элемента в колонке, первая колонка состоит из 1, 2 или 3 элементов в зависимости от количества элементов в блоке
Нет, это такое же обращение как и любой другой nth-child.
в примере с блоками мы используем логику:
-если количество блоков кратно трем то…
-если количество блоков не кратно трем и нечетное то…
Соответственно, мы можем обратиться к любому количеству элементов, которое удовлетворяет условию an+b(т.е. фиксированная база + кратность)
Пример с ~ более читаем, так как мы сразу видим, например:
:nth-last-child(3n):first-child(если элемент, кратный трем, если считать с конца, является первым, то есть количество элементов кратно трем), ~ :nth-child(3n — 1) (обратиться к каждому третьему элементу начиная с второго)
Я долго искал что-либо подобное, и не смог найти. Да и никто из верстальщиков и фронтэнд-разработчиков, кого я знаю, не слышал о таком решении — специально уточнял, чтобы не повторяться.
Возможно, дело в том, что то решение подавалось как узкоспециализированное. В данном же случае идет указание на целевой элемент с условием определенного количества детей, а не просто как решение для автоматического задания ширины для определенного количества элементов в списке.
Мне просто любопытно — а чем это лучше copiny, например?
Я могу вспомнить еще штуки три подобных сервисов, к копини отношения не имею, если что, просто первый пример, который пришел в голову.
Нужно стараться привязывать обработчики к контейнеру, в котором происходит подмена контента.
Не могу не удержаться еще раз попиарить библиотеку cornerJS, которая занимается именно этим. Точнее, все даже лучше — она привыязывается к подменяемому контенту.
Собственно, для решения этой проблемы я ее и пилил.
Кстати, как альтернатива — есть Mozilla x-tags (IE9+) и Google Polymer (IE10+), реализающие привязку к элементам — правда, не в формате директив, а в формате custom elements/web components.
Еще есть jQuery MX(про него, правда, только слышал), который предлагает помимо всего прочего регистрацию событий в формате
'.parent .container click', отвязывающийся от текущей структуры, и реализующий делегирование событий от body с удобным синтаксисом.
Кстати, последняя — 16-я уже, так что last-1 критерий соблюдается — с 15-й версии опера на вебките работает, где оба варианта поддерживаются.
Ну да это уже скорее придирки.
Первое — работает почти везде, но с изображениями меньше размера контейнера, в противном случае начинается сдвиг вправо, по вертикали продолжает центроваться.
Второе — ie9+, все хочу про эту пепяку написать, собственная разработка. Из минусов — сложно дергать анимации.
Третье — да, собственно, что вам нужно.
больший параметр картинки занимает 100% параметра блока, а второй параметр сохраняет пропорциональное отношение, как и в оригинальной картинке.
Теоретически взрывная волна может быть абстрагирована как временная область аномальной гравитации тогда уж сама по себе — и вакуумные бомбы тогда делать можно те самые, и обычные взрывы будут наносить зональный урон + придавать импульс телу.
А по-хорошему тогда уж надо сводить все не к гравитации, а к передаче импульса за промежуток времени, правда, когда я пытался что-то подобное реализовать — запутался в абстракциях, так что меня не факт что стоит слушать :)
Относительно three.js — я больше имел ввиду взглянуть на структуру, а не на сам движок, так как там структура работы с данными очень похожа — объекты, камера, сцена… Возможно, что-то пересмотрите у себя, если наткнетесь на интересные решения в аналогичном по структуре проекте.
Присоединяюсь к вопросу. Как лучше в таком контексте реализовывать шлейфы? особенно постепенно гаснущие/уходящие в прозрачность. Все реализации, что я могу придумать, сводятся к большому количеству элементов.
Кстати. Порекомендовал бы взглянуть на структуру three.js, пока читал — была стойкая ассоциация с ним, уж очень много тех же терминов. Может быть, найдете пару идей, которые пригодятся.
Да, если бы это был файл — было бы все просто, но разворачивается все в Blob/ binary string, и впихнуть это в pdf.js было весьма сложно. Ну, судя по тому, что мы видели.
Видимо, я плохой автор, раз не смог объяснить.
Это работает не как jQuery. Это не альтернатива jQuery. Этот код работает через MutationObserver, который вызывает колбэки на каждое изменение DOM-дерева. И каждый раз, когда целевой элемент добавляется, отрабатывает целевой колбэк.
Я не представляю, как на jQuery можно красиво и быстро реализовать что-то подобное:
При том что внутри одних шаблонов легко и непринужденно могут оказаться другие, иногда — даже не один раз.
А вообще статья базируется на постулате о том, что ПРЕДПОЛАГАТЬ появление новых элементов и вызывать инициализацию элементов по смене вьюхи или чего угодно еще это плохо.
Как угодно еще — это, например(реальный код, который я видел):
При этом человек не первый день в вебе, далеко не первый, много запущенных и работающих сайтов.
То есть человек реально делает предположение, что через .5 секунды после смены текущего анкора вызовется смена вьюхи(которая делается тоже асинхронно в силу того что слушает то же самое событие), которая успеет обновить дом-дерево.
Что страшнее всего — сами вьюхи подгружаются через $.get.
В действительности же все скроллбоксы — сущности автономные, и держать их внутри основного кода — смысла нет. Соответственно — Corner это возможность вынести абсолютно весь код, который не относится к mainflow, в отдельные изолированные блоки.
А вот это
$('input').keyup
будет работать только с теми элементами, которые в данный момент есть на странице. Если вы добавите еще один />, то он уже не будет обрабатываться.
Хотя да, без Corner заработал бы такой код. Не стану спорить.
вам было бы комфрортнее принять общий this? Потому что jQuery предлагает именно такой синтаксис. Я просто пришел к тому, что цепочка вызовов, в каждом из которых this ссылается на ноду — не так удобна для декларирования, чем общая конфигурация сразу же.
Да, более того — в Corner используется полифилл для mutationObserver от полимера, и я сам пытаюсь отслеживать изменения обеих проектов.
brick указан зря — это комплект элементов на базе x-tags, в действительности существует всего 2 реализации web Components.
Я периодически использую в качестве эксперимента(например, там, где однозначно не будет поддерживаться ie) Polymer, однако он сам по себе несколько монструозен и тяжеловесен. В любом случае даже x-tags более тяжеловесное решение, в которое входят полифиллы для HTML imports, Custom Elements, входит достаточно больше количество кода, которое позволяет обсчитывать жизненный цикл компонента.
Если лезть глубже — то директивы Corner-а это что-то среднее между директивами ангуляра и компонентами.
С одной стороны — они навешиваются на элемент (не создают новый элемент, а базируются на старых), их может быть несколько, они могут появляться в любой момент жизненного цикла элемента и так же исчезать. С другой — их события действительно похожи на те, которые используются в web Components — решениях: создание, исчезновение, изменение атрибута.
В пользу директив говорит простота при почти том же функционале, в пользу веб-компонентов — переносимость(вы ведь в курсе, что и полимер, и x-tags способны использовать компоненты друг друга?). Однако далеко не в пользу компонентов говорит то, что они опираются на:
-WeakMap полифилл, при этом они используют решение, которое в в пользу скорости(прирост в сравнении с «правильной» реализацией огромный, в некоторых случаях — в сотни и тысячи раз в силу того что сложность официального решения O(n), сложность их — O(1)) несколько не соответствует стандарту и способно в некоторых случаях банально падать.
-MutationObserver полифилл, не способный отлавливать удаление атрибута(все остальное на самом деле полностью соответствует стандарту)
-HTML imports полифилл, который в силу своей природы выполняет синхронный XHR-запрос, что крайне негативно сказывается на времени загрузки страницы, и поэтому я бы рекомендовал использовать его только в разработке
-Shadow DOM полифилл. Его я не использовал, поэтому не могу по своему опыту ничего сказать, но то, что я видел в исходниках, наводит меня на мысль на то, что опять же быстродействие ощутимо проседает.
Полимер в действительности это огромный прыжок в будущее, и я нисколько не умаляю его роли, более того — я все собираюсь с духом написать про него большую и интересную статью, но все же… даже сами разработчики не рекомендуют использовать его в продакшне.
В любом случае, компоненты не позволяют расширять текущие элементы. А в случае же с Сorner-ом можно спокойно написать что-нибудь вроде
Ого. Да, это мой баг — добавлял красивые эффекты к директиве для публикации, самое интересное — что у меня работало во всех браузерах.
Сейчас обновил фиддл, можно поиграться.
А что вы имеете ввиду под «вынуждена либо ждать полной загрузки предка, либо многократно пересчитываться по ее ходу»?
там 14 элементов, это не попадает под условие «кратно трем» и не попадает под условие «не кратно трем и нечетное».
Если хотите — я сделал другой пример, с ним тоже можно поиграться.
Три элемента в колонке, первая колонка состоит из 1, 2 или 3 элементов в зависимости от количества элементов в блоке
codepen.io/Jabher/pen/atkwe
в примере с блоками мы используем логику:
-если количество блоков кратно трем то…
-если количество блоков не кратно трем и нечетное то…
Соответственно, мы можем обратиться к любому количеству элементов, которое удовлетворяет условию an+b(т.е. фиксированная база + кратность)
Пример с ~ более читаем, так как мы сразу видим, например:
:nth-last-child(3n):first-child(если элемент, кратный трем, если считать с конца, является первым, то есть количество элементов кратно трем), ~ :nth-child(3n — 1) (обратиться к каждому третьему элементу начиная с второго)
Возможно, дело в том, что то решение подавалось как узкоспециализированное. В данном же случае идет указание на целевой элемент с условием определенного количества детей, а не просто как решение для автоматического задания ширины для определенного количества элементов в списке.
Я могу вспомнить еще штуки три подобных сервисов, к копини отношения не имею, если что, просто первый пример, который пришел в голову.
почему-то подумал, что будет рассказ о том, что на самом деле возможно сделать что-то вроде
А мысль, собственно, хорошая. Вы не знаете, работает ли это? И если да — позволяет ли это сэкономить трафик, реально ли это будет условная загрузка?
Не могу не удержаться еще раз попиарить библиотеку cornerJS, которая занимается именно этим. Точнее, все даже лучше — она привыязывается к подменяемому контенту.
Собственно, для решения этой проблемы я ее и пилил.
Кстати, как альтернатива — есть Mozilla x-tags (IE9+) и Google Polymer (IE10+), реализающие привязку к элементам — правда, не в формате директив, а в формате custom elements/web components.
Еще есть jQuery MX(про него, правда, только слышал), который предлагает помимо всего прочего регистрацию событий в формате
'.parent .container click', отвязывающийся от текущей структуры, и реализующий делегирование событий от body с удобным синтаксисом.
Ну да это уже скорее придирки.
jsfiddle.net/eqJnK/
Первое — работает почти везде, но с изображениями меньше размера контейнера, в противном случае начинается сдвиг вправо, по вертикали продолжает центроваться.
Второе — ie9+, все хочу про эту пепяку написать, собственная разработка. Из минусов — сложно дергать анимации.
Третье — да, собственно, что вам нужно.
это просто background-size: cover
А по-хорошему тогда уж надо сводить все не к гравитации, а к передаче импульса за промежуток времени, правда, когда я пытался что-то подобное реализовать — запутался в абстракциях, так что меня не факт что стоит слушать :)
Относительно three.js — я больше имел ввиду взглянуть на структуру, а не на сам движок, так как там структура работы с данными очень похожа — объекты, камера, сцена… Возможно, что-то пересмотрите у себя, если наткнетесь на интересные решения в аналогичном по структуре проекте.
Кстати. Порекомендовал бы взглянуть на структуру three.js, пока читал — была стойкая ассоциация с ним, уж очень много тех же терминов. Может быть, найдете пару идей, которые пригодятся.
с jquery — без проблем, только нужно оборачивать в $(node), передается родная нода, не жкверишная.
Это работает не как jQuery. Это не альтернатива jQuery. Этот код работает через MutationObserver, который вызывает колбэки на каждое изменение DOM-дерева. И каждый раз, когда целевой элемент добавляется, отрабатывает целевой колбэк.
Я не представляю, как на jQuery можно красиво и быстро реализовать что-то подобное:
При том что внутри одних шаблонов легко и непринужденно могут оказаться другие, иногда — даже не один раз.
А вообще статья базируется на постулате о том, что ПРЕДПОЛАГАТЬ появление новых элементов и вызывать инициализацию элементов по смене вьюхи или чего угодно еще это плохо.
Как угодно еще — это, например(реальный код, который я видел):
При этом человек не первый день в вебе, далеко не первый, много запущенных и работающих сайтов.
То есть человек реально делает предположение, что через .5 секунды после смены текущего анкора вызовется смена вьюхи(которая делается тоже асинхронно в силу того что слушает то же самое событие), которая успеет обновить дом-дерево.
Что страшнее всего — сами вьюхи подгружаются через $.get.
В действительности же все скроллбоксы — сущности автономные, и держать их внутри основного кода — смысла нет. Соответственно — Corner это возможность вынести абсолютно весь код, который не относится к mainflow, в отдельные изолированные блоки.
А вот это
будет работать только с теми элементами, которые в данный момент есть на странице. Если вы добавите еще один />, то он уже не будет обрабатываться.
Хотя да, без Corner заработал бы такой код. Не стану спорить.
Относительно общего this.
Если бы я предложил синтаксис
вам было бы комфрортнее принять общий this? Потому что jQuery предлагает именно такой синтаксис. Я просто пришел к тому, что цепочка вызовов, в каждом из которых this ссылается на ноду — не так удобна для декларирования, чем общая конфигурация сразу же.
brick указан зря — это комплект элементов на базе x-tags, в действительности существует всего 2 реализации web Components.
Я периодически использую в качестве эксперимента(например, там, где однозначно не будет поддерживаться ie) Polymer, однако он сам по себе несколько монструозен и тяжеловесен. В любом случае даже x-tags более тяжеловесное решение, в которое входят полифиллы для HTML imports, Custom Elements, входит достаточно больше количество кода, которое позволяет обсчитывать жизненный цикл компонента.
Если лезть глубже — то директивы Corner-а это что-то среднее между директивами ангуляра и компонентами.
С одной стороны — они навешиваются на элемент (не создают новый элемент, а базируются на старых), их может быть несколько, они могут появляться в любой момент жизненного цикла элемента и так же исчезать. С другой — их события действительно похожи на те, которые используются в web Components — решениях: создание, исчезновение, изменение атрибута.
В пользу директив говорит простота при почти том же функционале, в пользу веб-компонентов — переносимость(вы ведь в курсе, что и полимер, и x-tags способны использовать компоненты друг друга?). Однако далеко не в пользу компонентов говорит то, что они опираются на:
-WeakMap полифилл, при этом они используют решение, которое в в пользу скорости(прирост в сравнении с «правильной» реализацией огромный, в некоторых случаях — в сотни и тысячи раз в силу того что сложность официального решения O(n), сложность их — O(1)) несколько не соответствует стандарту и способно в некоторых случаях банально падать.
-MutationObserver полифилл, не способный отлавливать удаление атрибута(все остальное на самом деле полностью соответствует стандарту)
-HTML imports полифилл, который в силу своей природы выполняет синхронный XHR-запрос, что крайне негативно сказывается на времени загрузки страницы, и поэтому я бы рекомендовал использовать его только в разработке
-Shadow DOM полифилл. Его я не использовал, поэтому не могу по своему опыту ничего сказать, но то, что я видел в исходниках, наводит меня на мысль на то, что опять же быстродействие ощутимо проседает.
Полимер в действительности это огромный прыжок в будущее, и я нисколько не умаляю его роли, более того — я все собираюсь с духом написать про него большую и интересную статью, но все же… даже сами разработчики не рекомендуют использовать его в продакшне.
В любом случае, компоненты не позволяют расширять текущие элементы. А в случае же с Сorner-ом можно спокойно написать что-нибудь вроде
и потом спокойно делать в SCSS примерно такой запрос
Сейчас обновил фиддл, можно поиграться.