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

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

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

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

Что-то на странице не сжимается до границ родительский области (максимальный размер — экран), и «выталкивается» создавая такую область. Пройдись по элементам инспектором, он подсветит их, что позволит найти. Обычно такое происходит с картинками, картами и заголовками.

Просто и дешево — дублируй элементы и трансформируй. Немного сложнее и чуть адекватнее (наверное) — с использованием SVG, в том числе используя элементы повторно по ID.

https://developer.mozilla.org/ru/docs/Web/CSS/mix-...

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

Может просто понятнее напишу. Речь о переопределении стилей, т.е. о противоречии во входяших условиях. Приоритет определяется специфичностью.

Что простым языком тот же приоритет. Например если ты напишешь такой код:

.class {
    color: red;
    color:  blue;
}

То цвет будет голубой, а в дебаггере первое свойство будет перечеркнуто, т.к. то, что ниже → приоритетнее. Звучит просто, но это работает только в плоскости, специфичность штука, которая не только про порядок, но и про вложенность, !important-ы и т.д.

Именно поэтому рекомендуется медиа-запросы оформлять после в порядке возрастания запроса, т.е. сперва дефолтные стили, потом для таблеток, и так далее. Это подход mobile-first. Но на самом деле не так важна последовательность, сколько отсутствие переопределений. Как по мне.

Как обычно пишут SCSS, то в принципе достаточно перенести CSS-код в исходники и где надо, заменить на переменные. Если в исходнике трудно найти, что именно поменялось — меняй подход к разработке, т.е. дели на блоки.

Если есть sourcemap, то это поможет разобраться.

А так да, как в комментариях написали, конечный файл, который бил модифицирован копируешь, запускаешь сборщик и смотришь разницу. Иной раз может хватить беглого просмотра в двух вкладках редактора (если блоки кода не погуляли вверх-вниз). Ну или таки diff, или сравнить в PR, если кодовая база в репозиториях храниться.

Создай класс со свойством display: none и включай\выключай его для нужных элементов.

https://codepen.io/i-am-studio_ru/pen/BajBrqL

Глобально это хорошо, но суть разработки в том, чтобы собирать локально в конфиг package.json зависимости от проекта. Ибо по обновлении глобального пакета полетят зависимости сразу во всех проектах. Инфа сотка.

А так пробуй запустить конфиг, кто ж мешает?

SVG по своей сути и названию масштабируемая графика. При интеграции ее в тело документа ты указываешь ей фактические размеры (хотя бы для одного из брекпойнта). Если же интегрируешь с помощью object, то max-width:100%, таким образом SVG будет всегда вписана в область, которая ей отведена.

Следовательно, в конечном счете размер вектора зависит от родителя (если ты не накосячил, конечно).

Исходя из этого ты можешь абсолютно позиционировать родителя SVG таким образом, чтобы он занимал столько места от секции, сколько есть в макете. При этом, врядли тебе будет доступен z-index:-1, тогда тебе необходимо будет задать родителю SVG (или ей самой, если ты без родителя обошелся) z-index:0, а форме свойства position:relative;z-index:1;, чтобы она [форма] могла «лечь» поверх пикчи.

Фоном делать не рекомендую, так как в случае с SVG ты потеряешь возможность точно управлять ей.

А начать постигать дзен SVG можно отсюда.