dom1n1k

Слайдеры всё-таки лучше на JS - намного удобнее, гибче и управляемее.
Плюс много готовых библиотек (которые под капотом могут частично использовать CSS-анимации).
Если использовать в меру, с производительностью будет всё нормально.

В общем-то можно, но гемору и кода столько, что оно того не стоит.
Это тот самый случай, когда по старинке проще и надежнее.

Назовите мне хоть одну причину, зачем тут нужен бутстрап? :)
- лейаут с выкрутасом
- резины и адаптивности нет
- дизайн элементов (кнопочки етц) кастомный

Так и побить страницу на 2 блока (левый и правый), а уже внутри них плясать.
Ширину этих блоков можно подобрать процентами, или vw, или calc - вариантов много, нужно пробовать.
Вероятно, нужен будет либо флексбокс, либо абсолютное позиционирование, чтобы отогнать нижний логотип вниз.

Но сделаю оговорку, что надо видеть внутренние страницы - они могут быть другими и серьезно повлиять на подход.

Во-первых, никто не мешает сделать отдельную ч/б версию лого и подобрать ей оттенки вручную.
Во-вторых: vis4.net/blog/posts/avoid-equidistant-hsv-colors

Похоже на MagistralC

Не так давно тут был аналогичный вопрос. Дело там оказалось в регистре символов в именах. На Винде имена файлов от регистра не зависят, а на Линуксе зависят.

Либо паддинги подбирать, либо каждое значение завернуть в inline-block, ширина которого у всех одинакова и равняется максимальной ширине контента.

Ошибка авторского варианта в том, что приведение к числовому типу (плюсик) стоит за скобкой, то есть выполняется оно уже после сравнения. А надо до - сначала привели к числам, потом уже всё остальное.

Я бы сделал просто картинкой в фоне. Пользы от псевдоэлемента тут не вижу особой.

Если нужно только несколько первых зумов, что мешает скачать готовые тайлы у любого доступного провайдера? Начиная от дефолтного Мапника и заканчивая каким-нибудь Спутником. Разложить по папочкам и прикрутить условный WebView с Leaflet-ом.
Сложности там начинаются, если нужно всё (это очень большой объем) или, тем более, хочется самому всё рендерить (нетривиальная настройка).
А тут вроде всё просто достаточно.

Сейчас специально открыл Хром, посмотрел - слипшихся букв нет. В целом рендеринг шрифтов светлее и вообще меньше нравится, чем в FF, но таких явных дефектов, как на скриншоте - не вижу.
Версия браузера почти та же - на конце 110 вместо 112.
Какая видеокарта? А то, помню, у меня несколько лет творилось какое-то непотребство со сглаживанием шрифтов на встроенном видеоядре Intel. Как только купил самую простую nVidia - проблема исчезла.

Отдельные иконки лучше. И без извращений со шрифтами.

По поводу того, что flex лучше всегда - это конечно чушь. Есть много простых ситуаций, когда он не дает никакого профита, тогда как старый добрый float решает проблему целиком. Флекс, конечно, тоже решит - но с побочными эффектами в виде неполной кроссбраузерности.
Предложения при этом делать фоллбеки на флоатах умиляют - если всё равно их делать, так не проще ли ими и ограничиться?!

В итоге, ответ на вопрос очень простой - flex нужно использовать там, где он дает конкретные преимущества. Самое очевидное - нужно автораспределение ширины блоков с подстройкой к ширине контента. Или вам нужно менять порядок блоков (свойство order).
Если ничего этого не планируется - flex не нужен! Сейчас уже наплодили сеток и "фреймворков", где flex используется фактически для имитации float-ов! Ну типа же стильно, модно, молодежно. Я ж крутой разработчег, не хухры-мухры.

При верстке каждого блока нужно задавать себе вопрос: "я использую flexbox, чтобы что?" Если на вопрос есть четкий ответ - да, нужно использовать. Если только бла-бла типа "ну это современно, прогрессивно и пр" - использовать старые железобетонные приёмы.

Мне в голову приходит такое решение.
При фотографировании класть 5 картонных квадратов контрастного цвета и строго определенного размера (скажем, 10 x 10 см) - по углам и в центре.
Потом сопоставляя их площади, можно примерно оценить искажения от объектива и неточности ракурса.
Потом считать тупо пиксели темнее некого порога и умножать на некий эмпирически подобранный коэффициент, который зависит от расстояния от центра и степени искажений, полученных на предыдущем шаге.