archelon

Не работает, потому что вы в backgroung-image кроме картинки понаписали ещё кучу всего.
Пишите либо всё в сокращенное свойство либо всё по отдельности. А не кашей, как сейчас.

При такой структуре разметки вам не нужен для этого JS.

Поменяйте id="info_block" на class="info_block" и добавьте css

.info_block {
  disply: none;
}
.open_link:hover + .info_block {
  disply: block
}

Правда, лучше немножечко видоизменить, чтобы наведение было на общего родителя.

Сделайте плюс не шрифтом, а блоком из горизонтальной и вертикальной линий, потому что у шрифтов полно свойств:

Чему к примеру равна горизонтальная линия вашего шрифтового плюса при размере 35px? Если у вас размер блока 45px, то линия должна быть так же с нечетным размером ровно 1px или 3px, или 5px в любом другом случае (1.2px, 3.6px, 4px) браузер начнет смещать ваш плюс вверх и вниз, что вы и наблюдаете.

Если же блок будет с четным значением, например 44px, тогда, чтобы плюс стал по центру у него должен быть размер 2px,4px и т.д..

Шрифты для такой задачи не подходят, тем более с изменением шрифта изменится и его центр.

setTimeout(myFunc, 5000)
5000 миллисекунд = 5 сек
вместо myFunc - ваша функция, которая закроет модалку.

По сути никакому.

Использование нижнего подчеркивания перед именем переменной, такого как наприме р this._data, является соглашением в некоторых языках программирования, включая JavaScript. Это не является частью синтаксиса языка или специальной функциональностью, а скорее соглашением об именовании, указывающим на то, что переменная является "приватной" или "внутренней" для твоего класса

В js вообще нет строгой приватности для переменных или свойств классов. Все свойства и методы класса по умолчанию доступны извне объекта. Использование символа _ перед именем переменной или свойства служит как некий сигнал или подсказка для других разработчиков о том, что эта переменная или свойство предназначены для внутреннего использования и не следует напрямую обращаться к ним извне класса.

Таким образом, this._data в вашем примере указывает на то, что _data предполагается использовать только внутри класса User. Если бы использовалось this.data без символа _, это могло бы дать впечатление, что свойство data предназначено для публичного доступа извне класса.

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

https://github.com/asvd/dragscroll

Dragscroll is a micro JavaScript library (910 bytes minified)

Если нужно будет больше опций, то рекомендую: Swiper https://github.com/nolimits4web/swiper

Что значит "не задаётся бэкграунд"? Всё накидывается и работает в соответствии с тем, что указано в css.
У nav белый фон, у списка внутри - серый, согласно универсальному селектору

* {
    box-sizing: border-box;
    background: #E5E5E5;
}

(без чёткого понимания всех нюансов этого селектора использовать его не рекомендуется).

Кратко: можно, если это не было прямо запрещено.

Если устно или в переписке была озвучена просьба не выкладывать, то чисто по-человечески следует пойти навстречу. Если просят не выкладывать, но очень хочется — ищите компромисс (убрать упоминание фирмы клиента, выложить лишь часть и т.п.).

Если запрет прописан в договоре, то нельзя выкладывать.

Во всех остальных случаях никаких ограничений нет. По-умолчанию считается, что фрилансер может показать свою работу в портфолио.

С учётом того, что мы привыкли скроллить страницу сверху вниз, колонки ни в каком виде не будут удобны для чтения.

Смыслов много. Во первых исходник не всегда отражает намерения разработчика или есть какая-то информация которая лежит вне этого поля зрения. Например фиксится какое-то сложное поведение кода наподобие undefined behaviour и нужно написать сверху комментарий почему именно сделано так. В противном случае другой разработчик может не понять все эти изменения и откатить их или просто выкинуть кусок кода за непониманием. Такова природа людей. Непонятное - откидываем в сторону. А если будет написано :

// Warning! Do not touch next line of code, because ...

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

Смысл также есть в авто-документировании для авто-документации. По ключевым словам типа Doxygen, JavaDoc можно посмотреть примеры и туториалы по документированию. Это очень хороший навык который сделает в беспорядочной разработке видимость ведения документации. Тут надо конечно идти от scrum-agile и потребностей бизнеса но бывают также проекты (ведомственные, и прочие промышленные) где это важно, и где требуют сопроводительную бумажку. Тулзов для этого много. Я перечислил только 2 но их больше.

Вот что точно не надо комментировать так это : твою подпись, дату-время изменений и заголовок JIRA-ticket на основании которого велась разработка. Вся эта инфа всегда храниться в системах версионного контроля и нет смысла ее дублировать дважды.

Задайте элементу с тенью
pointer-events: none

Вы выделили в системе два класса сущностей. Одна - Пользователь, вторая - Роль.
Под каждый класс нужна отдельная таблица.
Как определить какие взаимоотношения между этими классами?
Нужно примерить следующие коммутативные гипотезы:
Первая пара гипотез:
"Один пользователь должен (может) иметь только одну роль."
"Одна роль должна (может) быть назначена многим пользователям."
Вторая пара гипотез:
"Один пользователь должен (может) иметь несколько ролей."
"Одна роль должна (может) быть назначена многим пользователям."
Если в вашей архитектуре системы справедлива первая пара гипотез, то вы строите взаимоотношение между классами Роль и Пользователь как "один ко многим". Это значит, что у таблицы Пользователь будет внешний ключ в виде идентификатора роли, тем самым вы каждому пользователю сможете назначить только одну роль. Но сами роли могут повторятся у разных пользователей.
Если в вашей архитектуре системы справедлива вторая пара гипотез, то вы строите взаимоотношение между классами Роль и Пользователь как "многим ко многим". Для этого нужно создать промежуточную таблицу, например Пользователь_и_роль, в которой будут два внешних ключа - идентификатор пользователя и идентификатор роли пользователя (можно, но технически нужно еще создать еще идентификатор первичного ключа, чтобы можно было корректно обращаться к записям этой таблицы, не путая их). В этом случае каждому пользователю можно выделить целый набор ролей, не ограничиваясь одной ролью.

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

Я обычно просматриваю изменения ключевых пакетов/библиотек раз в 1-3 месяца.

В большом проекте ключевые пакеты/библиотеки может быть сложно обновить, особенно если меняется номер старшей (major) версии (например, Bootstrap v4 => v5). Несущественные изменения (minor), в некоторых случаях могут иметь ощутимые последствия, что-то может сломаться или изменится поведение.

Я бы не стал просто так обновлять такой пакет, как Bootstrap. Если обновление ключевого пакета происходит, то это неизбежно увеличит нагрузку на QA команду (quality assurance - обеспечение качества, тестирование). В случае с Bootstrap, вероятно придется весь проект перетестировать. Без автоматического тестирования будет особенно тяжко.

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

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

Ну и главное, не делать просто так обновления на текущей активной версии проекта. Чем дольше проект с обновленными пакетами будет находиться на тестировании, тем лучше.

На html игры не пишут. Их всегда пишут на javascript
Просто так называют игры, которые для отображения используют холст (canvas)
Такое название сложилось исторически, с тех времен, когда игры в основном писались на флеше. Вот чтобы их как-то обособить игры на js стали называть играми на html5 в противовес флешу.