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

Глянул каменты:

чтоб шрифт менялся при изменении экрана. Конечно могу задавать через медиа, но интересно, есть ли круче свойства

Пикселы — фиксированные значения. Если тебе нужен плавающий шрифт в зависимости от экрана — используй относительные. Скажем vw\vh.

В примере паралакс, который базируется на расчете прокрутки (scrollTop).

Можно использовать абсолютное (можно и родителя крутить, или фиксированное, на самом деле и т.д.) позиционирование и делать элементам положение left (да и right сойдет, тут все в твоей фантазии) в рамках вьюпорта при совпадении с прокруткой.

Ключевое слово тут паралакс. Его стоит погуглить. Ну и просто спроецировать это в горизонтальное решение. Реально сложного тут — не обосраться в позиционировании элементов на разных разрешениях.

Смотри в сторону переопределения сырцов. Или переопредели с таким же шагом, но уже после, свой стиль. После — после файла с подключением стилей.

Но в крайнем случае (или если они инлайновые) можешь написать свои стили + !important флаг.

Жесткий захаркоженный каркас это про гриды.
Masonry это совсем не про жесткость.

У тебя элементы вложенные, но обращаешься ты к последующим на том же уровне. Тебе стоит уделить больше внимания селекторам и все получится.

И немного поменять уровни вложенности так как ты с помощью css можешь двигаться только «вниз» и «вглубь». А «всплывать» не умеет.

Т.е. тебе нужно расположить всю цепочку на одном уровне и через селектор + пройтись. Впрочем, я бы рекомендовал такие проверки делать на уровне бэка. Чтобы не вываливать наружу логику.

UPD глянул каменты. Менять разметку woocommerce ты можешь, ищи это в их документации. Ключевым словом должно быть «переопределение». И на самом деле это крутая сторона WP и хорошо спроектированных под него плагинов. Или делай проверку через. JS, ему пофиг на правила CSS о движении вниз и вглубь.

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

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

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

Так что я рекомендую закрыть этот минус и идти договариваться подмастерьем (джуном).

Что-то типа спойлера? Можно взять за принцип что-то типа такого и если речь о чем-то типа «схлопнуть на мобилке и показать все на пекарне», то прикрутить медиазапросы + видимость (свойство display).

Если же нужно считать в зависимости от разрешения + наличия\отсутствия элементов, то помочь может JS или расчет шаблонизатором от бэкенда (показать первые n элементов, а остальные под спойлер\табуляцию).

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

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

Или использовать гриды, просто разбить на блоки и давать порядок в зависимости от разрешения. Типа

grid-template-area: 'header_1 header_2 header_3' 'features_1 features_2 features_3'

на пекарне и

grid-template-area: 'header_1' 'features_1' 'header_2' 'features_2' 'header_3' 'features_3'

на мобилках. Зайти и с другой стороны, выдавая позицию в номерах. Грубо, но свойства есть, дальше поможет интернет. Но смотри поддержку браузерами, осел не вывозит гриды.

Да и таблицами на самом деле сделать можно. Главное обеспечить им адаптивность. Это реально, но геморроя больше, чем в подходах выше.

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

Действительно, какая-то дичь. Ежели ты используешь Chrome Devtools, то там есть вывод размера вьюпорта (при эмуляции устройства и если двигать ползунок панели), зачем его скриптом ловить — для меня секрет.

Дальше в комментариях верно отметили про стандартные разрешения — можно взять за референс популярный Bootstrap и повторять его breakpoints до того, как начнешь понимать, что к чему.

Естественно, это не убережет от косяков, ибо да хотя бы пользовательский ввод. Или самое косячное — навигация в шапке. Постоянно с этим сталкиваюсь, особенно при введении новых элементов (сейчас у меня на сайте, к примеру, ни в п... короче ни к месту форма входа, правда ее там никогда и не было). Я к тому, что дизайн в любом случае при некоторых масштабных введениях приходится переделывать. А чтобы максимально избегать провисов между популярными viewport-ами, достаточно осваивать переносы и обрезку контента. Если позволяет условия, конечно.

Например у флексов есть свойство flex-wrap:wrap, а гриды так вообще супер, можно указать минимальный размер для переноса и он будет работать не как в обычных блоках + зависимость от контента. Но, к сожалению это работает по сути только в списках, при верстке специфического контента работают другие условия.

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

PS: чтобы тестировать, как мужик открывай эмулятор и дергай ползунок, прокручивая страницу. Где-то поехало — переделывай). А потом лови лучи боли от IE, в котором забыл оттестировать или Safari на iOS.

PSS: самое малое устройство за базу можешь взять 320 по ширине, а больше 1920. Если шире, то оптимально обернуть в контейнер отцентрированный.