PavelScron: Это можно исправить апишкой используемого тобой лайтбокса. Там в разметке ты стопроц указываешь какой-то атрибут для привязки одной работы к конкретной галерее. Сложность у тебя будет в том, что в новоподгруженных работах тебе наверняка придётся переинициализировать твой лайтбокс, чтоб он и новые данные начинал видеть
Да, относительно карты, мне просто нужно получить километрах в результат выполнения API. Потом его уже отдавать в свой калькулятор. Относительно карт - нашёл в яндексе подобный апи, но по лицухе карту нужно разместить обязательно. Я думаю это даже круто. Юзер сразу может увидеть путь. Но по документации 2 поля ввода на карте. Скорее всего придётся немного повозиться и после map.load() при change в полях ввода моей формы - отправной точки и точки назначения - отправлять данные в поля карт, которые просто скрою через свой css.
В google maps API я и этого не нашёл. В mapbox тоже не увидел. Короче как всегда, в веб-разработке, ситуацию спасает яндекс)))
В принципе всё круто и понятно, только не понимаю где правильно хранить частоповторяющиеся вещи, которые по сутя не являются компонентами. Напиример layout-grid. Или переменные с цветовой гаммой и стандартными отступами, ширинами колонок итп. Сейчас я создаю в styles каталог core и туда кидаю подобные сущности, используя sass extend %layoutClassFromMixin. Но на каком уровне переопределения держать их в project-stub не очень ясно. Точнее ясно что в common.blocks по идее, так как они повторяются в каждом новом проекте. Неясно как их наследовать, не забивая bemjson лишним классом. То есть чтоб он видел elem: 'plate', например, и кидал на неё стили layout сразу.
Технология супер, описывать так проекты - просто блеск. С каждым новым проектом у тебя появляется своя небольшая библиотека компонентов, которую можно без труда перенести в следующий проект. Даже про sass можно забыть с плагином postCSS pobem. Вообщем рульно, но тяжелее чем кажется на первый взгляд. И декларативное описание поведения элементов на javascript тоже мне не особо ещё понятно. я хочу jQuery))) он привычнее
Дмитрий: Вот у меня даже перемотки нет. Вещание ведь потоковое. Есть только play и pause. Написал свой toggle, где play, только если плеер paused срабатывает с колоссальной для промисов задержкой в 150 мс. Всё равно некоторые станции глохнут. При чём нет определённой последовательности - хаотично глохнут. Думал, что кликаю быстро и тоггл просто захлёбывается от большого интервала. Но и мальнький в 10 мс изменений не дал
tripcollor: Ну я, в моём случае, для отвязки поведения использовал модификатор calltracker. Если у класса есть модификатор calltracker, то событие не применялось. Я бы на твоём месте всем формам написал один класс, а перед всей валидацией добавил условие. Если у формы есть такой-то модификатор, то нужно валидировать вот такие-то поля ещё впридачу. Но суть в том, что используя serialize форма всё равно отправляет значения и имена всех полей. Ты можешь и в php пропалить какую форму заполнили обычным isset.
tripcollor: если сайт на CMS, то подставить под страницу плагин отправки форм. Отправлять данные ему через ajax. Валидацию от спама и уведомления написать на jQuery (ну и notie js), как у меня. Остальные данные либо отправлять как заполнены, валидируя на уровне атрибутов, либо добавить if такое то поле не undefined. Либо валидировать на уровне плагина отправки, если он позволяет. Короче куча решений, но ajax должен быть один.
evilcore: ну значит тебя не интересует своя система подписки, если ты не можешь её реализовать. Используй CMS с готовыми модулями. По мне лучшая практика - MODX Revo + Sendex
Realetive: да, написал ему после 2х дней ожидания) С величинами разобрался, но вызовы сниппетов мониторинга всё равно не очевидны. Тестировать компоненты тоже не получается. Я затусовал модуль на сайт с более чем 300 чанков (сайту 3 года и он довольно сильно засран), но модуль позволяет тестить только те чанки, которые начинаются с буквы b))) Марк пока что по этому вопросу ничего не отписал))) Вот https://forum.modmore.com/t/what-mean-some-column-...
Спасибо за приближённую к моей конструкцию. Методом различий выявил проблему. белый бэк был задан не фронту и бэку а целой карточке. Отсюда и дублировался front на back. когда убрал с карточки цвет всё магией заработало)
Андрей Федоров: "важно что у меня в firefox неправильно рассчитывается распределение по flex-блоку дочерних элементов. вот с этим я борюсь."
Борись))) Удачи
Андрей Федоров: вообще-то sleepyKitty прав. Псевдоэлемент на флексбокс никак не влияет - он просто висит сверху. Добавь .item{position: relative; z-index:11} и .item встанет выше своего псевдоэлемента.
Игорь Воротнёв: боже, ну всё, завалил))) Но тем не менее, в данном вопросе я ударил в точку. А значит и без углублённых знаний матчасти я умею думать) Ты прав. Доклад супер) на этом предлагаю остановится)
Игорь Воротнёв: я не буду матчасть учить - она мне не нужна. Я верстальщик))) Да и какая разница - кэшировать на винчестер или оперативку. Основные делэи - это сеть, а не работа сервера. И при соединении в 20мб.с не оч будет разница между запросом кэша из оперативы и винчестера. К тому же время жизни кэша в оперативе явно не такое длительное, как на винчестере. Это грузит сервер.
Игорь Воротнёв: ты хочешь сказать, что разработчики WP настолько о*ели, что берут на себя право засирать оперативную память пользователей кэшем из своего движка. Боже, класс - одного хрома, отбирающего полтора гига мне будто недостаточно... Я начал ненавидеть WP ещё больше.
//reinit lightbox with params
})