Senseich, Да, следовать принципам построения сетки, заложенной в фреймворк. $container-lg: 1010px;
(брикпойнт, кстати, тоже подкорректировать придется.)
Конечно я допускаю возможность исключений из правил, если того требует макет. Но у вас, похоже, это просто хотелка. По крайней мере, неясно из имеющихся данных, действительно ли необходимо убирать отступы у контейнера.
Далее в зависимости от параметров.
Например объемы флешки — фиксированный набор цифр.
Если приводить к НФ, то этот набор хранится в отдельной таблице
id — size
1 — 64 Mb
2 — 128 Mb
и т.д.
А в таблице параметров продукта
param_size INT
в нем хранится идентификатор из таблицы размеров.
юзер чекает пару параметров 64 и 128 — из фильтра прилетают айдишники размеров 1 и 2
делаем выборку WHERE param_size IN (1,2)
ну и т.д по всем параметрам.
Понятно, что к каждому типу параметра при проектировании таблицы подходим индивидуально
andrewnsk, вы попробуйте поискать браузерные расширения. Под хром точно что-то есть такое, что позволяет сохранять изменения в инспекторе в исходниках.
С голым css они хорошо работают. С препроцессором у меня тоже заводилось, только сорсмапы нужны.
Я не использую, ибо настраивать расширение нужно под каждый проект.. больше головняка, чем профита.
то и значит )
Я не знаю чем и как вы собираете, но например browsersync подтягивает новые стили и внедряет их не перезагружая страницу. Про webpack с его HMR вообще промолчу.
Происходит это мгновенно. Впечатал цифру, жмакнул ctrl+s и пока переводишь взгляд на второй монитор, там уже новый стиль применился. Легко подбираются значения. Может не за 5 секунд =), но достаточно быстро, чтобы в инспектор не лезть.
andrewnsk, лично я не соглашусь.
в удобном редакторе писать код быстрее.
компиляция css даже на объемных проектах — десятки миллисекунд. Обновления страницы при правильной настройке сборки вообще не происходит, стили встраиваются горячей заменой.
Препроцессоры задумывались не для того.
Если вам приходится, или у вас кто-то правит билды — это проблема ваших рабочих процессов, и менять нужно именно их.
В приведенных вычислениях вы же сами отталкиваетесь от брейкпоинтов, а не от макета.
Наверное мне стоило взять другие размеры, чтобы не вводить в заблуждение )
320 - это исходный размер картинки на минимальном экране, а не размер экрана. А все последующие — расчетные на его основе.
размер мог быть 160 (в полэкрана) и цифры были бы другие.
А брикпойнты расставляются уже по этим цифрам.
В идеальном мире. =)
На практике я так не заморачиваюсь. Времени нет. Для фонов секций например 640-1280-2560 и всё. Рассовываем их по заданным брикпойнтам (как правило 768-992-1200), чтоб уродливо не смотрелось и норм.
pavelkunyavskiy, опять у вас про какие-то мифические размеры...
Ориентируйтесь на макет и на контент. Что здесь может быть не понятного?
Окей, возьмём частный случай. Картинка должна отображаться без мыла на обычном дисплее и ретине с удвоенной плотностью пикселей во вcю ширину экрана.
Будем отталкиваться от минимального экрана в 320 и максимального 1280.
на минималке для ретины нужен удвоенный размер. значит имеем две картинки 320 и 640.
<=320 — 320 и 640
320—480 мы можем использовать ту же картинку 640 для обоих типов экрана.
480-640 - для обычного 640
480-920 - для ретины 1280
640-1280 - для обычного 1280
920-1280 - для ретины 2560
Итого получаем набор картинок 320-640-1280-2560, которые не будут замылены при озвученных входных условиях.
Но вы должны понимать, что это не панацея. Поменяем входные данные так, что картинка должна отображаться шириной в половину экрана. Все размеры будут другими.
Поэтому я повторяю — ориентироваться нужно на макет и контент.
PS если непонятно, откуда взялась цифра 480, то это 320*1,5, компромисс, при котором картинка ещё не выглядит так уродливо
Она и будет такой ширины, если вы зададите контейнеру ширину 1010px
https://github.com/twbs/bootstrap-sass/blob/master...
или https://getbootstrap.com/docs/3.3/customize/#conta...