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

Вы неправильно настроили панель разработчика. У мобильных телефонов количество физических пикселей больше, чем количество «css-пикселей» в браузере. Разница выражается параметром Device Pixel Ratio (DPR) — это коэффициент умножения, сколько физических пикселей в одном «css-пикселе».

take.ms/v1Ms8

В режиме Responsive у Хрома по-умолчанию DPR=1.0 (у макбука по-умолчанию 2.0, т.к. retina-экран). Вы выставили ширину вьюпорта 540px, но у вашего телефона, скорее всего, DPR = 1.5 и разрешение в браузере соответствует 360px (540 / 1.5 = 360).

Вам надо включить отображение DPR и доработать верстку на малых экранах от 540 до 320px.

Проблема явно в скрипте font loader
https://github.com/ivankirshin/ivankirshin.github....
Проверьте синтаксис. После этой строки даже подсветка кода ломается.
Если загрузить страницу c выключенным js, всё нормально выглядит.

У инпутов есть атрибут, с помощью которого можно управляться отображаемой клавиатурой на мобильных девайсах — «inputmode».
https://developer.mozilla.org/en-US/docs/Web/HTML/...

Сам не пробовал, но может это вам поможет.

Не понял, какие у вас проблемы с масштабом.

В хроме удобный эмулятор экранов, как мобильных, так и десктопных, тач и не тач, разной ориентации и плотности пикселей.
Можно даже имея монитор 1920×1080 посмотреть как сайт будет выглядеть на более крупных экранах, например, 2550×1440
https://youtu.be/RB2ZDE7WVpk

<meta name="viewport" content="width=device-width">

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

<meta name="viewport" content="width=1024">

ставьте, если у вас сайт фиксированной ширины или резина с минимальной шириной. В этом случае сайт уменьшится в масштабе, чтобы колонка шириной 1024px помещалась без горизонтальной прокрутки. Конкретное значение подбирается исходя из минимальной ширины верстки. При изменении ориентации устройства с портретной на ландшафтную, масштаб сайта увеличится, чтобы занять новую ширину.

4) Что лучше брать новичка и развивать его или брать сразу опытного спеца?

У вас такая ситуация: вы разработчик и верстать не хотите. Раз вам приходится самому нанимать верстальщика, значит других верстальщиков в компании нету? Значит развить новичка выше своего текущего уровня вы не сможете. К тому же, новичок не разгрузит вас, а наоборот будет отнимать у вас время (поставить задачу, проверить, научить, переделать). Новичок не вариант.

Вам надо нанимать опытного специалиста, причем опытнее вас. Иначе вам по-прежнему будет оставаться самая тяжелая работа по верстке.

Как нанять специалиста умнее себя?

В вакансии напишите, что ищете главного верстальщика. Отсеются те, кто к этому морально не готов.

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

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

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

5) Есть ли смысл искать верстальщика который еще и понимает в разработке на уровне натяжки своей верстки на сайт или проще натягивать верстку самостоятельно?

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

Распределить работу покомпонентно.
Любые макеты можно разобрать на следующие компоненты и этапы.

0. Создается общий репозиторий для проекта.
Все работы ведутся сразу в нем. Чем чаще делаются коммиты, тем раньше вылезут и будут исправлены проблемы. У каждого компонента есть свой css/less/sass файл, чтобы легче управлять кодом и избегать merge-конфликтов.

1. Основные строительные блоки:
- Типографика и стили для контента (таблицы, цитаты)
- Элементы форм + стили валидации
- Декоративная графика (иконки, плашки)
- Модульная сетка (сразу респонсив)

Каждый верстальщик отвечает за свой кусок работы и создает демо-страничку с перечнем компонентов, которые он сверстал. Работа верстальщиков не пересекается.

2. Повторяющиеся компоненты:
- Навигация
- Ленты новостей, событий, блогпостов, результатов поиска, чего угодно
- Типовые формы (логин, регистрация, поиск)
- Табы
- Слайдеры
- и так далее

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

После этих двух этапов у команды готов UI-kit проекта.

3. Предварительная сборка всех шаблонов страниц с реальным контентом

Работа распределяется постранично. Каждый верстальщик копипастит блоки из UI-кита и наполняет реальным контентом. В конце команда оценивает, где что еще нужно доделать.

4. Редкие кастомные компоненты и модификации

На основе проблем, которые вылезли на третьем этапе, каждый верстальщик допиливает блоки, за которые он отвечает.

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

Обо всем этом говорят Atomic Design, ITCSS и многие другие методологии.

Не дробите сетку на большое число колонок, это не поможет. Управлять такой сеткой будет тяжело, но всё равно попадутся сайты, которые в неё не лягут.

Я для себя сделал генератор flexbox-сеток на LESS: под каждый конкретный проект я могу сгенерить сетки с разным количеством колонок, гуттерами разной ширины и разными media брейкпоинтами. Всё настраивается при помощи 5 переменных. По-умолчанию моя сетка старается быть похожей на бутстраповскую 12-колоночную, как самую привычную. Но некоторые фишки я утянул из сетки Zurb Foundation 6.

paulradzkov.com/flxgrid.css

К тому же, flexbox настолько гибкий, что колонки могут распределять между собой ширину автоматически.
Посмотрите пример paulradzkov.com/flxgrid.css/#auto-width-columns

Можно смешивать колонки с явно заданной шириной (фиксированной или в процентах) и автовыравнивающиеся колонки. Т.е. дизайн сайта не обязан быть выровнен строго по вертикальным направляющим, как с float-сетками.
Flexbox-cетку можно подстроить под почти любой дизайн, дописав немного кастомного кода.

По скриншотам трудно гадать, может дело в таблице, которая, скорее всего, генерится скриптом.

Вот пример рабочего лэйаута c фиксированными хеадером и футером и прокруткой посередине codepen.io/paulradzkov/pen/mPwyYO?editors=1100

Общая рекомендация: не использовать короткую запись «flex: 1», т.к. в разных браузерах есть разночтения по поводу. Лучше указывать явно «flex-grow: 1».
Про этот и другие баги флексов можно почитать тут https://github.com/philipwalton/flexbugs

Миксины .make-row() и прочие я использую, только чтобы сгенерировать альтернативную сетку. Например, параллельно стандартной 12-колоночной нужно использовать 5-колоночную с увеличенным гуттером.

В остальных случаях пишу классы «row», «col-*» и прочие бутстраповские сразу в вёрстке, мне так удобнее. Потому что нужно сбалансировать сложность в HTML разметке и сложность в CSS коде. Рассмотрим крайности.

1) Если каждому блоку в разметке писать уникальный класс, а потом в CSS миксинами накидывать rows, cols и прочие свойства из фреймворка, то в HTML сложность понижается, ведь у нас на блоке всего один класс, зато в CSS сложность резко вырастает: чтобы исправить баг, верстальщику придется бегать по миксинам, анализировать зависимости, чтобы не поломалось в другом месте. При этом растет размер CSS файлов: стили для модульной сетки повторяются в разных селекторах (дублирование кода), а верстальщику для каждого нового блока приходится придумывать новое уникальное имя класса. Два внешне похожих блока имеют 90% одинакового кода и этот код повторяется два раза. Такая ситуация называется «css bloating» (css наводнение).

2) Противоположная ситуация называется «html bloating»: когда в стилях создают простейшие классы типа .colorred, .fontsize14, fontweightbold, .padding20 и т.д., а в разметку на каждый тег кидают по 10-20 таких классов, пока блок не будет выглядеть как надо. В этом случае в CSS очень низкая сложность, нет никаких конфликтов, размер файла невелик. Но если дизайн хоть чуть-чуть поменяется, верстальщику придется переписывать классы на каждом тэге. Вся сложность из стилей ушла в разметку.

В первом случае (css bloating) у нас 100% отделение внешного вида от разметки. Это вроде бы хорошо, блоки выглядят независимыми, но достигается это высокой ценой: большой риск сломать что-нибудь, внося правки в миксины; повторения в коде и в результате обязательный gzip стилей. В чистом виде можно использовать, когда нет доступа к html-разметке: один и тот же виджет используется на разных сайтах и должен выглядеть по-разному, менять ему html опасно.

Во втором случае (html bloating) внешний вид смешан с разметкой (это лишь чуть-чуть лучше, чем инлайн styles) и даже самое маленькое изменение в дизайне влечет кучу тупой работы по перестановке классов в html, но зато в css конфликтовать нечему. Пожалуй, в чистом виде может встречаться в веб-приложениях, когда верстка генерируется через js-шаблоны (тупая работа автоматизирована). Отлавливать css баги в динамичной верстке приложений очень сложно, поэтому есть смысл увеличить прочность стилей, перенеся сложность в разметку.

Оптимальный вариант — распределить сложность примерно поровну между стилями и разметкой — «multiple classes». На каждый блок вешать 3-5 классов, которые отвечают за модульную сетку, геометрию, скин этого блока. Соответствующие классы можно переиспользовать в других блоках. Классы Bootstrap'а хорошо справляются с модульной сеткой и частично с геометрией, а скины и геометрию собственных компонентов верстальщик дописывает сам.

В БЭМ баланс сложности смещен в сторону css bloating: блоки должны быть независимыми, их нельзя смешивать, можно лишь вкладывать друг в друга, а значит увеличено количество повторений css кода.

В OOCSS баланс смещен в сторону html bloating: пишут больше мелких, но переиспользуемых конструкций, имена классов придумывать сложнее, т.к. они должны быть достаточно абстрактны, но всё ещё показывать, что этот класс делает.

Правильный способ — сделать наоборот: сначала для маленьких экранов сверстать список, а для больших экранов яваскриптом добавить классы и инициализировать слайдер. Этот подход называется «Mobile First» habrahabr.ru/post/269419