dom1n1k

HTML/CSS-верстка тут практически непригодна.
Нужно использовать какую-то графическую библиотеку, работающую с графикой как с логическими примитивами (то есть не только рисует, но потом умеет двигать, обрабатывать действия пользователя и пр.). Это может быть и SVG, и canvas - кому что привычнее и удобнее. В качестве примеров можно привести Snap.svg и Paper.js соответственно, но не обязательно их, есть и другие альтернативы.

Я предпочитаю группировать стили по смыслу и по отношению к одному блоку, а не по отношению к размеру экрана.
Разделять размеры по файлам и тем более папкам кажется логичным только на первый взгляд. По факту так делают жертвы формализма в ущерб здравому смыслу.
Ну вот открыл я один из файлов, смотрю на код блока. Как я должен догадываться, как он себя поведет при уменьшении экрана? Лезть в другой файл? А потом в третий, четвертый... А может там и нет ничего - я не знаю заранее. А ещё часть стилей всегда общая для разных размеров - их тоже в отдельный файл?

Уж лучше побить интерфейс на более мелкие блоки и сделать их максимально независимыми. Но внутри блока код пусть будет в одном файле и рядом. Да, медиа-запросы получаются не полностью оптимальными, да, объем кода получается чуть больше, но меня это не парит.

в фотошопе если измерить от нижнего края Блока А до верхнего края Блока Б

Измерять нужно не от края букв, а между базовыми линиями. От б/л последней строки предыдущего блока до б/л первой строки следующего. Потом вычитаешь высоту одной строки (font-size * line-height) и получается величина отступа между абзацами.

Правильный ответ:

<ul>
    <li><a href="#">Что-то</a></li>
</ul>

li > a {
    display: block;
}

Конечно, в реальном коде стили лучше вешать не на теги, а на классы. Тут просто принцип.

Я бы пообщался с дизайнером или заказчиком и попробовал договориться об устранении этих хреней.

Уголок тут не играет никакой ни смысловой, ни эстетической роли, которые оправдывали бы его присутствие. Это просто потуга дизайнера в духе "чтобы тут ещё всунуть, чтоб они не подумали, что я мало поработал? ну хз, вот пусть ещё уголок будет!"

Движок для изменения по факту тоже никому не нужен, он только глаза мозолит посреди карточки. Никто не будет там это двигать, если фото и текст изначально между собой нормально сбалансированы. Как максимум, я бы сделал 2 дискретных положения - фото узкое/широкое. А кнопочку для этого сделал бы маленькую снизу.

Масштаб увеличенный у клиента настроен.
Это кстати вполне нормальное явление и не должно ломать верстку.

Все зависит от того, насколько эта штука должна быть адаптивной.
Если нет - то всё очень просто, граф рисуется картинкой (можно даже фоновой), иконки расставляются по этажам блоками равной ширины.
Если же оно должно тянуться... тогда вариантов намного больше и нельзя так вот заранее сказать, какой предпочтительный. Можно например вообще всё сделать в SVG. Или можно палки картинкой, а красные кружи флекс-блоками. А можно сделать несколько картинок и просто их менять медиа-запросами.
Зависит от ТЗ.

Sublime, Notepad++. Первый погламурнее, второй покондовее.

Верстать резиново/адаптивно.
Ведь может же на сайт прийти человек, у которого монитор реально 1600? Может. И 1440 может. И ещё куча вариантов.
Верстальщик вообще не должен привязываться к какой-то фиксированной ширине.

Узнать эти числа можно либо от авторов, либо проведя ручной эксперимент в браузере.
Дело в том, что все эти наименования (thin, light, bold и пр) никак не стандартизованы и не подчиняются никаким строгим правилам. Есть приблизительные правила, которые сложились исторически и которых все стараются более-менее придерживаться - но исключений встречается довольно много.
Конкретно в случае с Lato догадаться несложно (очевидно, что 9 начертаний как раз помещаются от 100 до 900 через сотню), но с другим шрифтом всё может быть иначе.
Кроме того, верстальщик имеет возможность назначать свои значения в font-face.

Это очень легко делается в картографических апи - как минимум в Leaflet и Яндексе, наверное и в каких-то ещё можно.
Главная трудность тут подготовить тайлы - то взять картинку во всех нужных масштабах, аккуратно нарезать их на куски и корректно пронумеровать.
Есть и узкоспециальные плагины для подобного просмотра фото, но те что я видел, мне не очень нравились.

Задавал аналогичный вопрос: Как это сверстать?
Насколько я вижу, в общем случае "красивого" решения на флексе нет.
Нужно либо фиксировать высоту контейнера, либо изгаляться с костылями.

Можно. Регулярно так делаю.
Типичный случай: карточка товара в магазине - название, картинка, кнопка, возможны какие-то иконки. И всё это кликабельно.

> как я понял их много
Вообще в природе может и много, но по факту более-менее популярен только один-единственный - бывший Jade, ныне переименованный в Pug.
Использовать ли его - вопрос холиварный. Некоторые люди от него в восторге. Некоторые, включая меня, остались не очень довольны.
Надо пробовать самому.

Всегда делаю так

.elem + .elem {
   margin-top: 20px;
}

В 2017 году всё-таки флекс-бокс. Уже можно :)
Без всякий хрени с дополнительными технологическими обертками.

Ну как написали умные люди в уже вышедших статьях, "гриды для двумерной раскладки, флекс для одномерной".
Двумерка во флексе сделана неважно - это чистая правда.

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

Имею опыт глубокой кастомизации Бутстрапа. Глупая была затея.
Родился такой монстр, который просрал плюсы и сочетал минусы обоих подходов (популярный фреймворк vs самописный велосипед).
Сильно изменив Бутстрап, убиваются:
- его обновления и багофиксы
- совместимость со сторонними плагинами
- низкий порог вхождения новых людей
- возможность гуглить решения в случае багов
Но и самописным велосипедом это тоже не является, потому что сильно завязано на исходную архитектуру. То есть нет полной свободы и гибкости, присущей кастомным решениям. БЭМ-ом там, конечно, тоже не пахнет, откуда идут большие проблемы с независимостью.
Бутстрап нужно использовать либо как есть, либо с минимальными скинами-стилизациями поверх.