Арсений Матыцин

В инспекторе кода данные свойства перечёркнуты.

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

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

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

Компонент здорового человека — SVG.

Задай параметры функции (неплохо бы ещё прикрутить TS к проекту), если актуально, задай базовые значения или тернарники на присваивание.

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

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

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

Блок логотипа описывает поведение исключительно логотипа, а класс-элемент родителя, в котором он находится задает отступы и вполне может регулировать размеры блока. В свою очередь поведение логотипа в разных размерах должно быть описано, хотя бы max-width: 100% для изображения.

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

background: linear/radial/и т.д.-gradient.

Обычно такое реализуют в рамках маршрутизации либо бэком, либо на JS, в идеале на фреймворке.

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

Используя ванильку (JS) можно передать в data-атрибутах ID-шники блоков, которые должны появляться снизу и справа от сайдбара и активировать их, скрывая остальные, во время нажатия. Но это на уровне костыльного решения, табуляция выглядит и реализуется проще.

Чтобы имитировать навигацию, т.е. чтобы можно было передать кому-то URL на конкретный таб, ты можешь использовать ссылочные якоря, опираясь на которые (разбирая ссылку, историю) открывать тот или иной контент впридачу к описанному мной выше.

Дело не в бутстрапе, там перечислены те же свойства, если описывать прилипающий контент вручную. А ломает эту логику overflow-ы. Ищи, где в родителях обрезка видимости.

Чтобы элементы всегда были по обе стороны, их можно банально переставлять\клонировать и крутить. Дальше уже вопрос позиционирования. Так делают в принципе все карусели.

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

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