egowka

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

Причина такому положению вещей простая - замучаешься ты так тонко настраивать дизайн. Вот ты озвучил 4 ширины - моник, ноут, планшет и мобила. Теперь помножь это на варианты высот. А если еще вспомнить, что окошко браузера юзеры могут ресайзить - рехнёшься. Поэтому и советуют делать высоту для настольных браузеров в районе 600-800рх, а для мобильных - 400-500.

Чтобы упростить задачу - сокращаем количество вариантов ширины. Делаешь только два - для больших экранов (моник, ноут, планшет - 1000-1200рх) и для маленьких (смартфоны - 320-360, эппл со своими 375 тут идёт лесом). Соответственно первой ширине присваиваешь высоту 600-800, а второй - 400-50.

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

Можно, нужно просто создать класс со своей анимацией, например:

@keyframes myAnimation {
    from {
      -webkit-transform: translate3d(0, 0, 0);
      transform: translate3d(0, 0, 0);
    }

    to {
      visibility: hidden;
      -webkit-transform: translate3d(0, -100%, 0);
      transform: translate3d(0, -100%, 0);
    }
  }
 .myAnimation {
    -webkit-animation-name: slideOutUp;
    animation-name: slideOutUp;
  }

Если фотошоп не совсем старый, то там есть Extras. При зажатом CMD (или Ctrl) они показывают расстояния до ближайших элементов в макете.

Удали его и поставь тот что по ссылке ниже. Далее надо будет его настроить, инструкции в описании.

"[php]": {
    "editor.formatOnSave": true,
    "editor.defaultFormatter": "bmewburn.vscode-intelephense-client"
  },

https://marketplace.visualstudio.com/items?itemNam...

"Вопрос задан более года назад". Ну мало ли, СексиМонкей, вдруг прочитаешь.
Воспользуйся их неявным сервисом manager.avocode.com.
Туда без проблем грузятся макеты и через синхронизацию попадают в приложение на компе.
Кириллица ни при чем, даже размер не очень важен.

Была подобная проблема, когда сам psd весил за сотку метров. Дизайнер пооставлял изображения в макете с резолюшеном 4k. Решилось оптимизацией макета.

Тоже столкнулся с проблемой валидизации телефонных номеров.
Телефоны берутся с участников вебинаров, на которые записываются люди из очень разных стран.
Соответственно, со всеми предыдущими схемами возникают проблемы:
1) а что если телефон с Украины (не +7-, а +38-)? А из Казахстана? А США (1-)? А Уганда ( +233-)? (из Уганды, правда, пока слушателей не было, но все впереди).
2)В разных местностях приняты самые невообразимые способы разбиения телефона на группы цифр:
8(8888)8-88-88-88 например. или 888(88)88888-888. Да и какие угодно могут возникнуть в будущем.
Поэтому вариант с "дефолтным разбиением типа "8(888)888-88-88 ну совершенно не катит.

Соответственно, я придумал следующий валидатор:
1) В начале могут быть пробелы, после них может быть "+" (а может и не быть)
2) Дальше должна идти группа цифр в количестве от 10 до 14 (мне нужны номера в международном формате; но если кому-то нужны более короткие - можно исправить диапазон длин).
3) Поскольку я не знаю, как люди группируют цифры - до и после каждой цифры может быть один из 8 знаков ("-", " ", "_", "(", ")", ":", "=", "+"). Это значит, что между двумя цифрами могут быть любые два из этих знаков.

В итоге получилось очень коротко и понятно )) :
/^(\s*)?(\+)?([- _():=+]?\d[- _():=+]?){10,14}(\s*)?$/

Съедает следующие телефоны:
+7(903)888-88-88
8(999)99-999-99
+380(67)777-7-777
001-541-754-3010
+1-541-754-3010
19-49-89-636-48018
+233 205599853

Попробуй добавить

* {
  min-height: 0;
  min-width: 0;
}

Кроме

display: flex;

задайте для

.owl-stage

еще и

flex-wrap: wrap;

Тогда не будет ужимать элементы.

Более-менее стандартный рабочий процесс с использованием Pug подразумевает, что используется какой-либо инструмент сборки или таскраннер вроде Gulp или Webpack, который полностью автоматизирует компиляцию HTML из Pug, как в dev-режиме, так и в build. То есть при грамотной настройке рабочего процесса описанная тобой проблема перекомиляции пропадает.
Актуальность зависит от объёма и характера задач. Простой лендинг или визитку может и не имеет смысла верстать с использованием Pug. На более-менее крупных проектах можно добиться серьезного прироста скорости благодаря упрощённому синтаксису и дополнительным фишкам типа миксинов и функций.
Так что, как и по отношению к любому инструменту, сначала нужно чётко понимать, зачем и когда его следует использовать. Если это понимание не пришло - скорее всего, пока не возникла та ситуация, когда инструмент реально нужен.

Чем разметка HTML не устраивает? Она и читабельней и редакторы с ней адекватно работают.

Мой первый опыт с тогда ещё Jade - это где-то лет 6 назад. И был он, мягко говоря, спорный. Отчасти понравилось, но больше всё-таки нет. Были проблемы, которые многократно перекрывали экономию от укороченного синтаксиса. Я писал где-то на Хабре комментарий на этот счет. В общем, забросил.

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

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

Но есть два но.
1. Подобный функционал есть в любом другом шаблонизаторе? Верно. И я посмотрел несколько (нунчаки, slim, haml, дуст). И везде я сталкивался с какими-то раздражающими нюансами или чего-то не хватало. А раз святой грааль не был найден, то я не нашёл для себя аргументов для смены шила на мыло.
2. Мне удобнее решать такие вопросы на фронте. Если вам удобнее делать всё то же самое в PHP - тогда да, выходит, что особого смысла нет.

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