Falseclock: ну тогда стоит поменять регулярку))) Главное, что понятно где её менять. Может её вообще аргументом функции сделать на такой случай. Идея ничего)))
Александр Ружевич: понимаешь, мужик, ты делаешь довольно банальные ошибки. У тебя просто нет понимания того, что такое методы, функции, переменные, типы данных. Как код читается и исполняется. Это всё и есть ООП. Без этих базовых основ - основ всех основ ты будешь лажать в применении любых библиотек, не говоря уже о чистом js. Начни с ООП. Я тоже как ты раньше думал. А потом посмотрел курс и всё как по полочкам расставилось.
Александр Ружевич: я вижу здесь баг даже без дебаггера. Тебе бы конечно следовало бы подучить юзать devTools, но и без него очевидно, что в первом же условии b будет undefined. var b перед i добавь.
WingRS: да просто свой image в jquery положи и убери аргумент scale. Тут даже ребёнок, 5 минут посидевший за туториалами яваскрипта способен вдуплить процесс. Для тебя это лучший вариант. Думаешь я не искал плагин подобного функционала когда это всё делал?) Искал, как видишь, безуспешно)
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))) он привычнее
