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

Можно поставить размер шрифта в зависимости от размеров экрана, но через calc() задавать минимальное значение.

В этом примере ( codepen.io/paulradzkov/pen/jqYqgY ) размер шрифта заголовка никогда не будет меньше 16px (1em):

h1 {
    font-size: calc(1em + 4vw);
}

Можно использовать более сложные формулы совместно с @media. Тут размер шрифта плавно меняется от 14 до 18px в диапазоне от 480 до 1024px.

@media (min-width: 480px) and (max-width: 1024px) {
  p {
    font-size: calc(14px + (18 - 14) * ( (100vw - 480px) / ( 1024 - 480) ));
  }
}

До 480 и после 1024px размер задан жестко с использованием @media.

Но в целом это все сложно и редко нужно. Я обычно задаю размер фиксированно на двух-трёх диапазонах при помощи @media.

UPD: можно даже заставить текст максимально заполнять площадь вьюпорта codepen.io/CrocoDillon/pen/fBJxu

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

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

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

При помощи grunt или gulp копировать нужные файлы из папки bower-components в правильные папки.

Для информационных сайтов лучше всего подходят генераторы статики.
Доводы в пользу генераторов статики и против большинства классических CMS для информационных сайтов:

1) Контент неудобно хранить в базе, как делает большинство CMS.

Если контент в базе, то его тяжело бэкапить и восстанавливать из бэкапа, неудобно сравнивать версии до изменения и после. Тяжело откатить изменения в конкретной статье, не затронув всё остальное. Для всего этого в CMS должна быть запрограммирована собственная функциональность.

Если хранить контент в файлах (так делают все генераторы статики), то связка «файлы + GIT» даёт легкий бэкап, сравнение и восстановление контента целиком и отдельным статьям почти с нулевыми затратами.

2) Редакторы контента в админке (TinyMCE, CKeditor) обычно неудобные и часто выдают посредственный код. А еще тяжело настраиваются. Контент-менеджеры, которые умеют верстать, всё равно тянут код в текстовый редактор, правят там и вставляют обратно.

Быстрее сразу работать с файлами в любимом редакторе кода. От этого можно получить дополнительные плюшки в виде подсветки измененных строк по сравнению с последним коммитом и некоторые другие.

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

4) С классическими CMS, где контент в БД, разработчику приходится держать localhost и/или dev версию сайта с копией живой базы данных и синхронизировать их между собой. Чаще синхронизация односторонняя (с лайва на локалхост), т.к. мерждить базы сложно и страшно что-то сломать на лайве. А в таких случаях, контентщикам приходится сначала делать все локально, а потом повторять на лайве.

С генераторами статики в этом так же просто как с файлами: можно нарендерить несколько версий для тестирования, сделать зеркала и т.д.

5) Скорость и безопасность. Статический сайт по определению быстрее любой CMS. Сгенерированный сайт легко положить в CDN и получить максимальную скорость открытия при любых нагрузках. А еще статические сайты не взламываются.

https://www.staticgen.com/ — список всех генераторов статики, отсортированный по популярности.

Сам уже года три пользуюсь docpad.org — генератор на node.js. Не сказал бы, что это идеальный инструмент. Я на нем потому, что уже хорошо его знаю, и у меня собралось много наработок для docpad, в том числе автоматизация.

Так же отмечу https://octobercms.com/ — CMS, которая следует принципам генераторов статики. Сам еще не пробовал, но если понадобится поддержка PHP, то это первый кандидат.

1. Убедитесь, что масштаб страницы в браузере в обоих случаях одинаковый и равен 100%
2. Проверьте, а не разные ли шрифты. Для этого во вкладке «Computed» в самом низу посмотрите какими глифами отрендерен текст.



3. Если разные, проверьте во вкладке «Networks», правильные ли подключены веб-шрифты. Грузятся ли.
4. Если пути у шрифтов правильные, но не грузятся, посмотрите этот ответ Почему могут слетать шрифты, после заливки на хостинг?

masonry masonry.desandro.com и isotope isotope.metafizzy.co

Недавно отвечал в соседней теме. Скопировал сюда.

1. Айдишник можно использовать на странице один раз. Два и более раза — это уже не валидно. Поэтому, если понадобится переделать сайт по схеме «три колонки → блок от края до края → снова три колонки» на одной странице, этот кусок кода придется полностью переписывать.

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

3. У айдишников слишком высокий вес селектора. Если вам понадобится контекстно перестилить что-то внутри колонки, то вероятнее всего вы впишите в селектор айдишник и потом, чтобы обнулить овверрайд или сделать новый, вам придется использовать этот же айдишник (или поставить другой). Классами перебить селектор с айдишником не получится — не хватит веса. Айдишник будет множиться в css-ке и реффакторить становится всё сложнее.

Поэтому выводы: 1) никогда не вешать на айдишники стили; 2) если нет выбора, писать селектор так: div[id="left"] {...} — этот селектор медленнее, чем селектор по классу, но и вес у него на равне с классом. Т.е. это меньшее зло, чем айдишник в стилях.

Миксины .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: пишут больше мелких, но переиспользуемых конструкций, имена классов придумывать сложнее, т.к. они должны быть достаточно абстрактны, но всё ещё показывать, что этот класс делает.