Rustam Bainazarov

С таким подходом не надо сложных манипуляций и ерунды с position: absolute или отрицательных margin для контента, здесь весьма очевидные отступы между блоками и пр.

Я сделал на flex, потому такая штука будет работать и в IE11. Хотя проще сделать с помощью grid. А вообще, такое можно сделать хоть на float (но не надо).



Можете их даже компоновать иначе, ничего не развалится:

На второй странице отсутствует мета-тег адаптивности:

<meta name="viewport" content="width=device-width, initial-scale=1">

Проблема из-за того, что Isotope не дожидается загрузки изображения, которое формирует габариты, и начинает строить сетку.

Можно сделать на хаке соотношения сторон и абсолютно позиционированной картинки. Это нужно, чтобы габариты блоков изначально были просчитаны с помощью CSS и не зависели от скорости прогрузки картинок. В итоге, у Isotope будет вся нужная информация заранее. И ошибка в расчетах из-за отсутствия габаритов не будет иметь место.

Вот рабочий пример. Для пущего эффекта вообще с твоей картинкой и адаптивностью. Сжимай окно — все будет адаптироваться и пересчитываться. И это с учетом абсолютно позиционированной картинки внутри и flex-разметкой:

.grid {
  display: flex;
  flex-flow: row wrap;
}

.element-item {
  flex: 0 0;
  width: calc(20% - 10px);
  margin: 0 0 10px 0;
  position: relative;
}

.element-item:before {
  /* формирователь соотношения сторон + задает габариты, которые будет считать Isotope */
  content: "";
  padding-bottom: 141.3242%; /* процентное соотношение сторон картинок */
  display: block;
}

.element-item img {
  /* картинка на абсолюте, как видишь */
  position: absolute;
  top: 0;
  left: 0;
  width: 100%;
  height: 100%;
}

.element-item p,
.element-item h3 {
  /* скрываем тексты внутри, они для сортировки нужен только (код инициализации из их официального примера просто */
  display: none;
}

/* адаптивность */
@media (min-width: 768px) and (max-width: 1200px) {
  .element-item {
    width: calc(25% - 10px);
  }
}

@media (min-width: 400px) and (max-width: 767px) {
  .element-item {
    width: calc(33.333% - 10px);
  }
}

@media (max-width: 399px) {
  .element-item {
    width: calc(50% - 10px);
  }
}

function toggleSubmenuDisplay() {
    document.addEventListener('touchstart', function(event) {
        // ВОТ ЭТОТ КУСОК -- НАЧАЛО
        if (event.target.matches('a')) {
            var url = event.target.getAttribute('href') ? event.target.getAttribute('href') : '';
            if ('#' !== url && '' !== url) {
                window.location = url;
            } else if ('#' === url && event.target.nextSibling.matches('.submenu-expand')) {
                openSubMenu(event.target);
            } else {
                event.preventDefault();
            }
        }
        // ВОТ ЭТОТ КУСОК -- КОНЕЦ

    ...

Из-за него это всё. Нужно переписать, либо убрать его нафиг. Он все ссылки обрабатывает. С учетом того, что я в разметке не вижу элементов с классом submenu-expand, я бы закомментировал целиком этот участок и посмотрел, что сломалось. Если ничего не сломалось, так бы и оставил.

Скорее всего это функция сборщика (или иной программной надстройки, или визуального редактора), который считает по формуле, сколько конкретный блок текста займёт места на экране и ставит в готовый билд эти значения. А-ля жёсткая макетизация на новый лад. Знаки после запятой нужны для точности рендеринга (чтобы округление не влияло на визуальный результат).

Если просто тупо использовать vw, то это плохой метод для создания адаптивности на сайте.

Данный метод (просто vw) можно и нужно использовать только тогда, когда нужно умещать конкретный текст в первозданном виде на все экраны (кол-во строк, переносы, кол-во символов и т. д.). С адаптивность эта идея не связана вовсе, не понимаю, почему её некоторые форсят.

Есть вариант такой:
https://css-tricks.com/snippets/css/fluid-typography/
Это старый и известный метод, у него есть свои преимущества и сценарии использования, но опять же в целом на сайте я не знаю, чем не угодили те же em, rem да даже px.

P. S. Ну а пример выше не умещается на экране телефона даже со всеми этими ухищрениями, хотя, видимо, призван делать именно это.

Update. Подумал, что там постоянно разные значения в CSS-файле, поэтому запутался немного в показаниях. Посмотрел, значения не меняются на разных экранах, файл mediaelection.com/css/common.css остается нетронутым. Нет «оверайда» стилей на фронтенде. Словом, то может делаться, например, в визуальных конструкторах (индивидуальной разработки) на том же React, либо через иное решение на том же React, которое заранее просчитывает размер того или иного элемента в зависимости от ряда параметров. Крупная студия вполне может позволить себе разработку такого решения для внутреннего использования.

Update 2. Ну или, как отметили Сергей delphinpro и tyzberd, можно по формуле в препроцессорах считать, сверяя результат визуально вручную.

Тег picture или img + атрибут srcset:
https://developer.mozilla.org/ru/docs/Learn/HTML/M...
https://webdesign.tutsplus.com/ru/tutorials/quick-...

Update. Есть и другой подход (не через media, а через x2, x3 и так далее), если так нужна именно Retina:
https://webkit.org/demos/srcset/.
Особого смысла не вижу, т. к. сейчас все телефоны имеют retina-экраны (300 DPI) или очень близки к ней.

Update #2. Вот ещё интересная ссылка для размышления с дополнительной информацией:
https://m.habr.com/post/422531/

P. S. Если будет поддержка IE11, то лучше (проще) использовать img с фолбэком (обычный src):