alex-1917, брейкпойнты в BS выбраны плохо. Не надо приводить их пример. (Да и вообще приводить в пример BS не нужно - то сборник антипаттернов, имеющий популярность больше по историческим причинам).
Стоит почитать эту статью, автор правильную идею толкает: https://medium.freecodecamp.org/the-100-correct-wa...
Из картинок неясно, в чем конкретно проблема? Ну да, макет не назовешь простым, но что именно вызывает затруднение? Что и как там должно адаптироваться? Думаю, вариантов решения будет несколько, и однозначно предпочесть какой-то один нельзя. Нужно будет смотреть по ситуации и требованиям.
На глаз я буду оценивать восприятие, а вот задавать размеры точно - в пикселях.
Чтобы не было вот так, как на экране. Потому что для разных шрифтов эти магические константы дадут непредсказуемо разные высоты.
одинаковый lh смотрится по-разному у разных шрифтов.
Да, такое бывает, особенно если взять очень разные шрифты. Но это абсолютно не оправдание для "процентов на глазок".
Если я решу, что мне нужно увеличить lh, то я её увеличу. Cознательно. А при подогнанных процентиках она будет жить собственной жизнью, рандомно и непредсказуемо.
Совсем избежать гемора не получится, но можно сильно его уменьшить. В частности, можно сохранить неизменную line-height. На приложенном скрине line-height плывёт (на глаз подобрано?). Это означает, что дизайнер любит трудности.
Ответ неправильный. "Подгонять на глазок" - плохо.
Даже если вы подберете нужное значение для одного конкретного шрифта, вы потом получите гемор в случае если понадобится заменить шрифт на другой.
Это один шрифт, хотя и на первый взгляд кажется, что разные.
Автор, случай интересный, но телепатически гадать тут малоэффективно.
Выложи 2 демо-странички куда-то, чтобы можно было посмотреть вживую.
Если меток суммарно не очень много (ориентировочно в пределах одной-двух сотен), можно вообще грузить все сразу - вывезет и так. Просто лишние не будут попадать во вьюпорт.
Если точек много, ну значит грузить точки для каждого города по мере их просмотра. А в чем проблема-то? По событию клика менять координаты карты, грузить аяксом json с данными и в цикле добавлять их на карту. Стандартными методами яндекс-карт, которые описаны в доке.
А можно даже без аякса, а данные подгрузить сразу пятью массивами. И на клик повесить уже только отрисовку.
Можно, но бессмысленно. У движка интернет-магазина есть шаблоны из коробки, чтобы его можно было купить и сразу использовать. Да, крупные магазины шаблоны модифицируют - добавляют свои элементы, цвета, стили и так далее. Но зачем, скажите на милость, им переделывать шаблоны с нуля? Это огромная работа и пропасть потенциальных багов.
Например, есть такой движок Shopware. Очень популярен в Европе и особенно на родине в Германии. Я сам неоднократно сталкивался с ним в процессе покупок.
Вот можно посмотреть на их демо-магазин - https://www.shopwaredemo.de/beach-relax/fashion/me...
У них каталог даже в самой последней версии сверстан флоатами.
Если я куплю этот двиг, зачем мне переделывать шаблоны с нуля? Чего я этим добьюсь кроме геморроя? :) Я возьму имеющиеся и немного подправлю.
Нет, шаблоны часто тоже имеют общее происхождение. С нуля дизайнить и верстать целый магазин - зачем? Это огромная работа. Берется один из коробочных шаблонов и допиливается. Если посмотреть например европейские магазины одежды, то у многих невооруженным глазом видны общие куски интерфейса.
Beliyadm, большинство крупных магазинов сделаны на одном из популярных (в этом секторе рынка) движков. А авторы движка делают максимально возможную кроссбраузерность, потому что он будет применяться в куче проектов и для него максимальная универсальность полезна и оправдана.
Ключевая ошибка таких рассуждений - они как бы неявно подразумевают, что все "дешевые мониторы с плохой матрицей" косячат одинаково. Но это далеко не так, они все показывают в разнобой. Главным образом, в этом и состоит их плохизна. Плюс дело усугубляется хаосом в пользовательских настройках, возрасте и ушатанности мониторов. Возьмите десяток рандомных мониторов из квартир и офисов - они все покажут по-своему.
И что вы проверите в таких условиях? Ну увидите как косячит один из миллионов и что? Остальные сделают это по-своему.
Работать нужно на нормальном мониторе, который отображает все близко к стандарту. Смысл стандартов не столько в количестве цветов, сколько в приведении их к единому эталону. Пусть лучше ваши пользователи видят сайт с погрешностью относительно стандарта, чем относительно другого косячного монитора, когда совершенно непредсказуемо, как сложатся эти погрешности.
А какие там будут искажения и артефакты градиентов у юзеров с говномониторами - это не так уж важно. Во-первых, они привыкли всё видеть именно так и им норм. Во-вторых, смотри выше про разнобой.
Единственное, надо держать в голове, что 6-битные матрицы могут уравнять 2 очень близких цвета. У меня много лет назад было такое - я сделал у страницы светло-серо-голубоватый фон, а под меню подстелил белую плашку. На IPS (даже дешевых, с 6 bit + frc) разница была видна нормально, а многие TN просто сливали в одно.
Ну тут решение простое - просто не использовать такие очень близкие цвета. Имея минимальный опыт, этого можно избегать и без контрольного просмотра.
"У большинства пользователей интернета мониторы с плохим цветовым охватом, а значит и для веб-дизайнера нормальный охват не важен" - это в корне неправильная логика.
Если кто-то так говорит, то он не понимает, как это на самом деле работает.
Даже если ваши пользователи сидят на самом дешевом low-end, веб-дизайнеру нужен sRGB.
Насколько мне известно, мультиакки у PP всегда были строго-настрого запрещены.
Некоторые люди всё равно их делали, конечно, и даже довольно долгое время не палились.
Но чтобы саппорт сам советовал заводить новый аккуант... это дикость какая-то.
Хотя допускаю, что я отстал от жизни.