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

Как по мне, самый безболезненный в плане верстки и расчетов способ: взять либу типа Vue и крутить массив со значениями + transition-group (для появления\исчезновения td-шек), либо то же самое, но на ванилке накатать (ни один фреймворк не может больше того, что умеет сам JS, просто там уже накатаны те подходы и методы, которые ты не захочешь реализовать сам).

При таком подходе не придется считать размеры относительно друг-друга, хотя при очень разном контенте таблица будет прыгать по высоте. Впрочем, она в любом случае будет прыгать. Можно смягчить чем-то в духе свойства css transition: all .5s.

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

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

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

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

QuizFilter это запрос, при выводе в шаблоны это игнорируется, в ЯП тебе необходимо преобразовать полученные данные в список. Вот тут есть разбор.

PS: это вопрос не столько Django, сколько обмена данными между ЯП и базами данных. В том же Flask с такой проблемой можно при отсутствии знаний столкнуться на раз. Да и продолбившись в глаза и со знанием дела тоже можно.

На сегодняшний день верстальщик это стек минимум из 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. Если шире, то оптимально обернуть в контейнер отцентрированный.

intersectionObserver либо ловить положение «триггера»-объекта относительно вьюпорта.

У первого нет поддержки в IE, ну да и как бы все равно, зато есть полифил.

На странице «Б» запускать скрипт. Можно даже по факту загрузки документа. Это тупо звучит, но работает.
Чуть сложнее — передавать в searchParams данные, и принимать их на странице «Б» и если выполняется условие, запускать функцию.
Еще сложнее — SPA.
Ну и в принципе это не предел.

Если иное не оговорено\написано в ТЗ\очерчено дизайнером, то следует уточнить этот момент.

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

У каждого пользователя должна быть своя строка в таблице пользователей и связи типа one-to-many к заказам.