Андрей Хохлов

Отвечу непосредственно по сабжу, то есть касаемо верстки.

1. Верстаю всегда только по PSD-макету (по договоренности можно AI). Всякие там джипеги и т.д. - мимо.

2. Макет должен соответствовать требованиям: https://github.com/andrey-hohlov/psd-templates-req...
Для точной оценки прошу предоставить макет, если для оценки есть только превью-картинки - оценка увеличивается на прогнозируемый риск от каши в макете.

3. В оценку входит только то, что было в макетах (превью) и ТЗ.
Сразу уточняю:
- Требования к кроссбраузерности, микроразметке (делаю обычно из коробки стандартные элементы) и т. д.
- Планируется ли адаптив, если да - то где макеты. Если макеты будут позже - рискую умножив оценку на некоторый коэффициент. Если есть макет только 1024 например и других не будет, то прикидываю смогу ли я сделать качественно 768 и 320 и оцениваю это дороже, чем верстку при наличии таких макетов вменяемого качества.
- Нужны ли анимации - параллакс, появления, вот это всё.
- Какой интерактив нужен. Маски ввода, валидации форм - это не проблема, обычно делаю по умолчанию самую базу. А вот динамичная маска ввода с кучей условий - это уже сложнее. А если в макете нарисован например калькулятор пластиковых окон, то это вообще задачка не про вёрстку. Я за такие берусь с удовольствием, но надо обсуждать отдельно (см. так же пункт 4).
- На какой движок будет верстка натягиваться и какие есть особые требования к ней. Подробнее про это Что значит «опыт верстки под битрикс, вордпресс и т. д.»? Всё что не озвучено - делаю на своё усмотрение и претензии на переделку потом только за отдельную плату.

4. Так же стараюсь обсудить различные вещи с нестандартной реализацией. Например, был у меня макет сайта строительной компании, который включал планы этажей, с подсветкой по наведению квартир и открытием детальной карточки квартиры по клику. План реализовал на SVG, который формировался из объекта с данными. Соответственно структуру этого объекта предварительно обсудил с backend-разработчиком.

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

1. Прошу дизайнера не рисовать символ рубля
2. Подключаю шрифт с единственным символом рубля.
artgorbunov.ru/bb/soviet/20120223 (там есть архив с набором готовых шрифтов - artgorbunov.ru/bb/soviet/20120223/b-rub.zip )
3. Или использую svg-иконку

А для :active состояние прописали стили?

Верстаем мы всегда с макета.
Я не говорю о таком кейсе как собрать админку из компонентов бутстрапа по прототипу - это как раз самое правильное его использование.

Так вот от макета мы очень сильно зависим.
Если дизайнер потрудился хотя бы использовать сетку, то сетка и система breakpoints из Botstrap (4 версия, на scss) нам очень поможет. Если дизайнер идиот - не поможет ничего.

В моем шаблоне проекта сетка и брекпоинты есть по умолчанию. Так же как некоторые helper-классы.

Что касается остальных компонентов (типографика, таблицы, формы, кнопки и т.д.) - всегда нужно задавать вопрос, что проще/лучше: стилизовать свою кнопку или переопределить имеющиеся.

Насколько классы предлагаемые бутстрапом впишутся в общий стиль проекта?

Насколько мы облегчим поддержку проекта, перекостылив под дизайн половину того что взяли от бутстрапа, а 2/3 проекта написав своими стилями?

Я видел как по дефолту суют
bootstrap.min.css
bootstrap-theme.min.css
bootstrap.min.js
потом в отдельном файле переопределяя и дописывая все что нужно. Целый мать его bootstrap.min.js из которого использовалось только меню-бутерброд!

Видел целую коллекцию костылей, перемотанную изолентой чтобы было как в дизайне.

И что, насколько я новичёк и максималист с моей библиотекой миксинов (документированных, в т.ч. из бутстрапа), scss файлами, разнесенными по блокам и BEM-подходом к наименованию классов?
С опрятным css на выходе и инструкцией-рекомендацией как и зачем всё же использовать препроцессоры.

Таким образом, присоединяюсь к ответам Сергей и Serj-One . Каждой задаче - свой инструмент.
А поддерживать легко не столько код где использовался фреймворк (особенно в контексте css), а код, где использовалась голова.

P.S. Вот ещё достойное мнение например:https://gist.github.com/iAdramelk/d328b73c72cab92ef95f

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

Создание svg-спрайта с генерацией fallback для не поддерживающих svg браузеров легко автоматизируется.
Для иконок с градиентами, тенями и т.д. так же не сложно делать png-спрайты с версиями под ретину.

Если устраивает поддержка браузерами - svg symbols. Это все преимущества спрайтов + все преимущества шрифтов.

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

Не использу, так как в ТЗ как правило пишут ie9+ :(

Есть основные размеры которые можно условно назвать
Смартфон 320+
Планшет в портретной ориентации 768+
Планшет в альбомной (нетбук) ~980+
Десктоп (ноутбук) 1200

Далее все зависит от дизайна, который в свою очередь зависит от целей проекта. У меня был проект в котором последний breakpoint был 1600 например.

Все достаточно просто: после каждого задуманного breakpoint'а меняются стили элементов, предлагая оптимальный интерфейс для текущего размера экрана.

Логично, что ширина контента 1280px оптимальна для экранов с разрешением от 1366px по ширине.

Разработка адаптивного интерфейса - задача дизайнера.
Многие заказчики тут пытаются сэкономить, заказывая статичный макет (в котором чудо если ещё сетка есть), а затем дают верстальщику чтобы значит адаптив от айфона до телевизора. На выходе в таком случае получается нечто на костылях.

На мой взгляд тут больше вопрос дизайна, чем верстки.
Макет выглядит как на 100% ширины, но со слайдером действительно возникает вопрос.
Если изображение для него на самом деле 1920px по ширине - то есть оно по центру и все что не поместилось в экран обрезается...
... или допускается пропорциональное увеличение изображения -
тогда да, тянуть блок на 100% ширины экрана.

Если нет - можно ограничить по ширине как есть в макете (1366), но тогда нужно тоже подумать о его уменьшении для экранов меньшего размера.

Решение должен принимать тот, кто отвечает за визуальную составляющую проекта, желательно согласовав с заказчиком. Если делаете для тренировки вы тут за всех сразу.

Варианты решений посмотрите тут: stackoverflow.com/questions/21719833/how-to-add-sr...

А я рекомендую разбить все на отдельные задачи:
- компиляция coffee
- объединение js
(я бы ещё вынес отдельной задачей минификацию)
И сделать третью задачу, которая поочередно запускает их.
Так получится более гибко и модульно, можно делать различные варианты билдов.

Посмотрите на админку wordpress например.

Идея в том, что колонку-меню можно сделать position:fixed, высотой 100% экрана, а правый блок с контентом сместить на её ширину от края.