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

Да, добавь order-ы и присыпь медиа-запросами.

Рассчитывай размер, исходя из макета. А с помощью CSS это можно реализовать на calc() расчетах (чтобы совпадало с макетом). Ну а если ты знаешь размер в процентах исходя из макета, или можешь легко его посчитать, то просто верстай от левого края (лучше бы ограничить, ибо странно будет выглядеть на широкоформатке), в процентах.

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

https://developer.mozilla.org/ru/docs/Web/JavaScri... — это для перебора.

Оптимизируй анимацию.

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

Но на самом деле проще на гридах с grid-gap.

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

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

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

Поэтому надо поработать над таймингов и логикой отрисовки.

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

Грубо, но по сути: команда пушит директорию dist (скомпилированный код) в ветку gh-pages (то, что будет отображаться в github pages репозитория).

Бери на вооружение слушателя скролла (по старинке) и высчитывай положение элементов относительно его (запрос в гугле «координаты документа на JS»). Либо используй intersectionObserver. А дальше уже по заданным условиям рисуй, можно на SVG-шке. При совпадении корр со скроллом или вхождении в условие intersectionObserver.

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

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

Андрей Белый, но все-таки они неверно подключены)

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

Кроме того, никакого смысла в preload-ах без их последующего объявления нет. А использованный подход, очевидно подобранный на каком-то сайте оптимизаторов, кроме того, что попахивает, так еще и не работает (глянь в PagesSpeed).

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

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

На фоне всего этого очень уморительно смотрится «Быстро с 1С-Битрикс».

И да, IE умер, помянем.

Скрин буквально неверный, интерлиньяж в вебе работает не так, как в редакторе, он не отсчитывается от baseline шрифта, это буквально высота всей строки. А размер шрифта это точно не x-height с ascent и пустым пространством, это еще и descent с пустым пространством, сформированным интерлиньяжем.

Если хочешь поседеть, можешь почитать, как это происходит тут.

Max-width задает условие максимального размера, а не размер. Для стопроцентного размера ему необходимо задавать width:100%.

Самой svg-шке надо задавать размер в соотношении (прямо в теге), и ему уже, как обычной картинке указывать ширину 100%, а высоту «как пойдет».

Ничего лучше пагинации и\или динамической подгрузки для страниц с большим ассортиментом пока не придумали. Разве что если слева\справа нет фильтров, и параметров сортировке в привычной позиции сверху — их стоит добавить.

При flex ориентации по горизонтали align-items это выравнивание по горизонтали. Чтобы центрировать, как text-align в данном случае нужно использовать justify-content. Ну или text-align, почему нет.

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

И я вроде не увидел переопределений на тему -self. Так что без этого самого динамического добавления трудно что-то сказать наверняка.

Но причиной может быть неправильный уровень вложенности приходящего объекта, структура, класс, который может на нем висеть, может с фиксированной высотой прилетает посчитанной на JS. Это все надо смотреть на уровне дебаггера → инспектора кода. Что-то может гасить стили обертки и там это будет видно.

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

И именно он скорее всего нужен, чтобы задать стили шапке вкрая, а вложенный container нужен, чтобы внутри содержимое было упорядочено сетке и логике фреймворке (максимальная ширина и т.д.).

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

Для работы с DOM хватает интерфейса работы с DOM: https://vk.cc/awd12n

https://developer.mozilla.org/en-US/docs/Web/SVG/S...
Можно заюзать SMIL, задав каждому элементы запуск scale со смещением во времени.