Павел Радьков

Mobile first верстать удобнее: от меньшего экрана к большему, от простого к сложному. При mobile first верстальщику приходится дописывать новые стили для бóльших экранов поверх базовой версии в 320px вместо того, чтобы обнулять написанные для настольных браузеров стили (как в mobile last). Меньше переопределений — чище код, легче верстальщику.

Существует признак плохого кода: если вам приходится обнулять стили, значит, что вы их задали где-то слишком рано. При mobile last обнулять приходится часто, при mobile first — очень редко.

С точки зрения браузера, чем меньше переопределений, тем быстрее парсинг.

А если заморочиться с оптимизацией, то при помощи некоторых программных средств можно пересобрать все стили для больших экранов в отдельный файл и загружать их только, когда сайт открыт на больших экранах. Т.е. грузить меньше килобайт и вообще не парсить лишнее.

https://codepen.io/paulradzkov/pen/vjEdbM

Вместо рекурсивного определения переменной, рекурсивно вызываем миксин:

@num: 100;
.mixin(@num) when (@num > 0) {
  .mixin(@num - 1);
  .square-@{num} {
    animation-delay: @num;
  }
}
.mixin(@num);

Ссылка внутри ссылки — невалидный код. Браузер пытается его исправить разметки самостоятельно и ломает внешний вид.

Нужно положить дополнительные ссылки рядом, сестринскими элементами внутри общего родительского элемента. При наведении на этого родителя, позиционировать дополнительные ссылки поверх основной ссылки с картинкой.

https://codepen.io/paulradzkov/pen/zzvOvR?editors=1100
вариант без svg и без js, но с кучей других органичений:
- нужно знать точные width и height таблицы для calc вычислений в css
- нужно знать все дополнительные горизонтальные размеры вокруг таблицы. это могут быть маргины, паддинги, ширина сайдбара и т.д.
- нужно делать кастомный брейкпоинт на основании всех этих размеров

Добавлено
Поторопился я отправлять — работает только в blink и webkit

Когда-то писал статью об этом paulradzkov.com/2013/lists_and_floats
И решение работало несколько лет. Но пару недель назад в новых хроме и опере появился баг: пока не поресайзишь окно, буллиты прилипают к левой границе контейнера.
Но в статье есть и «старое» решение, у которого были проблемы с размеров буллитов в IE.

Самый древний способ — direction: rtl;
htmlbook.ru/css/direction
Контейнеру direction: rtl; — чтобы пустить блоки справа налево.
Блокам direction: ltr; — чтобы контент внутри блоков вернулся в нормальный поток.

И вместе с ним можно использовать и флоаты, и инлайн-блоки, и таблицы.
Но лучше флексы :)

Анимируйте background-size

Можно попробовать использовать transform: scale().

1. Узнавать через js высоты контейнера и блока текста. Текст пока с прокруткой.
2. Высчитывать через пропорцию коэф. уменьшения, чтобы выровнять высоту блока текста и контейнера.
3. Применять к блоку с текстом transform: scale() с вычисленным коэффициентом. Тогда видимая ширина блока текста внутри контейнера уменьшится, появятся margins справа и слева.
4. На тот же коэффициент увеличить ширину блока текста. Тогда текст начнет занимать меньше строк и под текстом появится пустое пространство.
5. Похимичить с формулами, чтобы отступ снизу был минимальным.

Может этот вариант натолкнет вас на решение. По крайней мере у него фиксированное количество итераций.

Пишем parallax правильно, ребята :)

Тут кроме технического вопроса есть вопрос эргономики.

Технически:

a) при уменьшении ширины убрать декоративную девушку и масштабировать карту пропорционально. Но тогда города станут маленькими и кликать в них будет тяжело.

б) при уменьшении ширины убрать декоративную девушку, а карту показывать в том же масштаба, но с горизонтальной прокруткой. Кликать в города удобно, но некоторые оказываются за экраном.

Принципиально:

в) при уменьшении ширины убирать декоративную девушку и, как только карта перестает помещаться, заменять карту на обыкновенный список по алфавиту. Все города поместятся на одном экране.

Использовать viewport-height единицы измерения для задания высоты обложки:

.page-cover {
   min-height: 100vh;
}

По ссылке не прямой ответ на ваш вопрос, но рассуждение на близкую тему — о балансировке сложности и крайностях.
Оправданность применения миксинов bootstrap типа .make-row()?

Мой выбор — multiple classes. Там сложность между css и html распределена примерно поровну.