ZakkMalin

Решение найдено
https://codepen.io/anon/pen/xopBZw


блок сверху светло-фиолетовый (фон добавила для наглядности, так разумеется он прозрачный) это :before
со стилями:

{  
  min-height: 20px;
    max-height: 80px;
    flex-grow: 8;
    width: 100%;
}

т.е. от текста до верхней и нижней границы блока .box (тот, что с розовым border) одинаковое расстояние (стрелки) вне зависимости от количества текста, если нет переполнения.
При переполнении верхний блок сжимается

Я это понимаю так:

Под multiroot воркспейсом подразумевается просто-напросто воркспейс, в котором сгруппировано несколько отдельных проектов, каждый может иметь свои настройки в подпапке .vscode. А вот это:

This can be very helpful when you are working on several related projects at one time. For example, you might have a repository with a product's documentation which you like to keep current when you update the product source code.

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

в фаерфоксе переписывают на rust

Css парсит браузер. Из этого можно сделать вывод, что чем хотят разработчики браузера его парсить, тем и парсят.
Подозреваю, что в основном это C.

Фреймворки с ошибками и дырами не редкость.

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

Вопрос нужно ставить не так. Не "нужно или не нужно?". А "для чего нужно?" Т.е. чего вы хотите от вышки?

Если знаний, то, касательно айтишной области, отечественные вузы вам никаких знаний не дадут. Куда лучше забугорные курсы типа https://www.edx.org/course/subject/computer-science . Вот если бы речь шла о фундаментальной физике или о какой-нибудь ракетной области, тогда да, отечественная вышка была бы необходима (но не в провинциальном вузе).

Если корочки для устройства на работу (айтишную), то лично я скорее взял бы человека без вышки, но с хорошим портфолио (скажем, учёткой на гитхабе), чем обладателя красного диплома МГУ без портфолио. Но, скажем, для занятия государственных должностей вышка может требоваться по закону, так что министром вы без вышки не станете.

Для чего логический оператор «!» (NOT) возле переменной с булевым значением?

не обязательно переменная может быть булевым значением.

function example(user) {
  // Если пользователя нет, то user->undefined->false
  // Логическим оператором отрицания мы "поменяем" false на true и выйдем из функции
  if (!user) return;
  // Тут какой-то код, когда user->object (пользователь есть)
  // т.к. user->object->true, то при отрицании в условие попадёт: user->object->true->false
}

ещё кейс:
поменять значение на противоположное, например, при нажатии кнопки должна сниматься или устанавливаться метка

check = true;
function handlerClick() {
  check = !check;
  // То есть берём текущее значение check, меняем на противоположное и присваиваем
}

на самом деле таких кейсов много может быть, зависит только от ваших фантазий

Для чего логический оператор «!» (NOT) возле переменной с булевым значением?

Чтобы инвертировать его, или как вы сказали переключить с true на false и обратно.
Пример:

if (isAdmin) {
    // Ничего не делаем.
} else {
    // Блокируем доступ к ресурсу.
}

Намного удобнее записать как:

if (!isAdmin) {
    // Блокируем доступ к ресурсу.
}

В случае, если оператор ! стоит не перед bool, то он еще и приводит тип данных к bool.

Логические конструкции, в основном, используются для условий (if-else) и циклов (while, for). В вашем случае, вы не меняете "выходные на будние", а получаете новую переменную, которая зависит от того, выходной ли сейчас. Понятным языком все это выглядит как: принять сегодня душ? Да - если НЕ (!) "выходной", нет - если "выходной".

Быстрота работы приложения - подойдёт всё.
Низкий порог вхождения в изучение библиотеки - Vue.

feature/jira-12543
bugfix/jira-12345
master
release/1.2.3
release/1.2.4

Мировые практики в действии

да как хотите. Назовите ветку для продакшена "production", для разработки "development", для фичи с логином пользователя через фейсбук "feature/facebook-login" никто не запутается.

Все это зависит от проекта/размера/привычек команды/сложности/процесса разработки/процесса тестирования/схемы релизов и так далее.
Единственное что есть более менее везде - это ветка master которая создается по дефолту и чаще всего ее и оставляют для продакшена. Но это тоже не всегда - бывает наоборот в мастере девелопмент а для релиза - релизные ветки.
Еще часто используется "feature/name", "bug/name" и так далее для удобства, плюс некоторые гит клиенты умеют такие ветки в списке веток группировать между собой.

Можно взять git-flow, если своего не придумывается ничего, но надо понимать что он предполагает определенную и достаточно жесткую структуру работы над проектом вообще, которая затрагивает не только названия веток но и вообще все аспекты цикла создания продукта.

До первого значения которое можно интерпретировать как true.

тут интерпретатор остановится и не пойдёт дальше?

Да

Переход на другую страницу - это не кнопка, а ссылка.

Ссылка может быть оформлена в виде кнопки по внешнему виду.
В этом случае обработчика, как такового, нет. Хотя в ссылке могут быть параметры, которые обрабатываются при формировании страницы на сервере. В этом случае можно сказать, что условный обработчик находится на сервере, то есть делает Back-end разработчик.

Однако часть логики может быть сделана на клиенте. Например, перед отправкой формы (кнопка + переход на дргую страницу) на всякий случай может быть проверка введенных данных. Конечно, на сервере эти данные нужно перепроверить, но чтобы честные пользователи не ждали долго, пока данные гоняются туда-сюда, гораздо быстрее проверить их перед отправкой и сразу выдать ответ. В этом случае обработчик делает Front-end разработчик.

Мы можем создать массив:
var arr = [2,1,3];
А можем обратиться к его элементу по индексу:
arr[0]; //2
Этот же способ обращения используется и для объектов, но помимо него ещё есть точечный
И да, строка -- это массив. Ещё стоит упомянуть, что в JS не существует типа для одного символа, а все массивы (да вообще всё кроме примитивных типов) -- объекты