Flying

Приведённая вами ссылка показывает причину проблемы и направление для её исправления.

Дело в том, что Rubik является variable шрифтом.

Подключение шрифта у вас выглядит вот так:

https://fonts.googleapis.com/css2?family=Rubik&display=swap

а в стилях используется font-weight: 600. Если вы посмотрите внутрь CSS, загружаемой для подключения шрифта, вы (естественно) увидите там подгрузку шрифта для font-weight: 400, ведь именно это значение соответствует Regular и используется по-умолчанию.

Таким образом вы ненамеренно создаёте ситуацию, когда вы используете начертание шрифта, которого нет. Очевидно где-то в Firefox (явно в списке зависимостей этого issue) есть проблема рендера variable fonts, причём специфичная для Windows т.к. я проверил (через BrowserStack) на MacOS и там всё нормально.

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

https://fonts.googleapis.com/css2?family=Rubik:wght@600&display=swap

результат сразу становится корректным:

В общем, поигравшись немного с предоставленным кодом, стало понятно следующее:

Это явно проблема браузера, так что имеет смысл сообщить о ней разработчикам, написав bug report в их трекер.

При этом проблема несколько не в том месте где ожидалось: элементы страницы позиционируются правильно, а вот отрисовываются некорректно:



Здесь видно, что картинка с точки зрения браузера находится в одном месте, а по факту нарисована в другом.

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

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

.chat-item__content.force-repaint .content-chat-content__message {
    opacity: 0.99;
}

Остаётся только "дёрнуть" CSS класс force-repaint на элементе контейнера - и всё сразу встаёт на место, поскольку осуществляется перерисовка. Например вот так:

function forceRepaintToFixChrome89Issue() {
    if (!navigator.appVersion.match(/\sChrome\/(89|9\d)\./)) {
        // Apply only for Chrome 89 and 90+
        return;
    }
    window.requestAnimationFrame(function () {
        const e = document.querySelector('.chat-item__content');
        if (!e) {
            return;
        }
        const fr = 'force-repaint';
        e.classList.add(fr);
        window.requestAnimationFrame(function () {
            e.classList.remove(fr);
        });
    });
}

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

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

Таким образом вам необходимо проверить какие символы вы грузите в шрифте. Обычно это следствие необдуманного subsetting'а.

Так при чём здесь Firefox, у вас файла шрифта на сервере нет:

Подобная функциональность - идеальный кейс для использования IntersectionObserver. Добавляете observer на элементы, соответствующие вашим экранам, определяете пороговое значение срабатывания - и дальше просто реагируете на события переходов между состояниями.

Конечно возможны нюансы с тем что, к примеру, несколько (больше двух) ваших страниц попадут во viewport (помним что мониторы можно развернуть и вертикально, получив высоту viewport'а в 2k пикселей), но в целом получается весьма стабильно работающая схема.

Дополнительный плюс в том что вам не нужно заниматься отслеживанием события scroll т.к. это и сложнее в реализации и менее надёжно и есть связанные с ним проблемы (подробнее в документации)

В первую очередь вам необходимо профилировать нагрузку на отрисовку через профайлер, "дёргание" означает просадку по fps, а просадка по fps означает что задачи основного потока выполнения не влезают в 16ms чтобы обеспечить 60fps.

Если открыть сайт в Firefox, то он сразу указывает на возможную причину: "This site appears to use a scroll-linked positioning effect. This may not work well with asynchronous panning; see https://developer.mozilla.org/docs/Mozilla/Perform..."

Быстрый просмотр показывает что это действительно так - у вас подключен jquery.sticky.js, созданный аж в 2012-м и реализующий то, что сейчас делается через position: sticky или IntersectionObserver путём навешивания обработчика на событие scroll. Это приводит к тому что на каждое движение страницы запускается JavaScript обработчик и создаёт изменения в DOM которые приводят к необходимости пересчёта стилей, а то и layout'а.

Изменения в DOM - в целом довольно дорогая операция, а уж пересчёт layout'а - тем более, так что логично что на более слабых CPU мобильных устройств это не влезает в бюджет по времени.

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

Таким образом начните с замены jquery.sticky.js на нормальное решение, а потом перепроверяйте результат через профайлер и смотрите что ещё вы можете выбросить. Ваша страница визуально явно не требует тех 900кб скриптов что вы на неё грузите.

Да, есть свойство aspect-ratio которое потихоньку начинает появляться в современных браузерах. Однако, поигравшись с ним немного - могу сказать что пока что использовать его на практике смысла никакого, придётся подождать пару лет как минимум.

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

1. dart-sass - reference implementation языка т.е. является образцом того как должен работать язык. node-sass binding libsass (реализации спецификации языка на C++) к node.js.
   
   dart-sass содержит в себе все последние фичи языка, к примеру там уже есть поддержка sass modules, libsass отстаёт, а node-sass отстаёт от libsass. За пруфами - сюда и сюда
   
2. libsass производительнее, местами - существенно. К примеру в моих тестах интенсивная работа с sass maps в libsass примерно в 10 раз быстрее чем в dart sass. Насчёт микросекунд - у меня есть проекты которые по 15-20 секунд компилируют только стили на node-sass, на dart-sass всё намного медленнее
   
3. Приведённые ссылки - сравнение тёплого с мягким. Есть реализации языков, а есть плагины для их подключения к различным сборщикам. sass - сама реализация языка, gulp-sass - binding для Gulp, sass-loader - binding для Webpack
   

Это следствие разных алгоритмов обработки суб-пиксельных вычислений т.к. браузерам всё равно в конечном итоге приходится рисовать страницу на экране, состоящем из пикселей. В случае hi dpi экранов, где за один логический пиксель отвечает несколько физических задача решается проще, но для экранов с dppx=1 приходится делать выбор и вот этот выбор делается по-разному.

На больших контейнерах это незаметно, а для маленьких - да, есть шанс того что элемент будет выглядеть "криво". Какого-то универсального решения здесь, судя по всему, нет, остаётся только подгонять, добавляя отступы в 1px туда или сюда для разных браузеров. Для того чтобы добавить CSS код только для какого-то конкретного браузера можно воспользоваться, к примеру, информацией с browserhacks, хотя, конечно, тут надо быть осмотрительным.

Ваша задача по сути сводится к динамическому обращению к переменным. Sass так не умеет. Для реализации вам необходимо сменить структуру данных и использовать maps.

Т.е. ваш код мог бы выглядеть как-то так:

$vars: (
  1 : #333,
  5 : #111,
  100 : #222,
);

@mixin div-color($id) {
  @if (map-has-key($vars, $id)) {
    color: map-get($vars, $id);
  }
}

Посмотреть в действии можно на Sassmeister.

Макет весьма простой для портфолио как по мне. Также отсутствие макетов мешает понять насколько полученный результат им соответствует. Если в качестве источника вы брали именно указанную HTML страницу - то отличия от неё слишком очевидны чтобы это комментировать. Тем не менее хочу сказать что результат лучше многого из того что постят здесь с просьбами оценить.

Однозначные плюсы:

• Внимание к деталям, к примеру то что вы позаботились сделать шрифт только с нужными вам иконками вместо того чтобы пихать всё подряд
  

На что стоит обратить внимание:

По самому проекту:

• Не следует хранить генерируемые файлы (тот же CSS) в системе контроля версий т.к. это приводит к ненужным локальным модификациям. Понятно что в данном случае вы хотели показывать его через GitHub Pages, поэтому в данном случае это нормально, но вообще при разработке - нет, эти файлы должны быть указаны в .gitignore
  
• Использование символа & в имени файла - сомнительная затея. В целом ничего страшного, но он может иметь специальное значение
  
• Подключение шрифта через @import - плохая идея т.к. он будет загружаться после того как будет загружена и разобрана таблица стилей т.е. вы оставляете пользователя с неправильными шрифтами дольше чем нужно.
  
• Не оставляйте неиспользуемый код в проекте, это усложняет его поддержку, особенно когда вы работаете в команде
  
• Продолжайте изучать английский, учите написание слов
  

По CSS:

• Не мучайте себя, познакомьтесь с flexbox. В современном вебе вёрстка на float'ах выглядит архаичной, сложнее поддерживается и требует от вас использования ненужных хаков.
  
• Старайтесь не экономить на CSS классах и использовать их для применения стилей вместо элементов. Это позволит вашему коду быть гибче и отвяжет его от деталей HTML
  
• Из-за неиспользования float'ов структура layout'а для teaser черезчур переусложнена, можно сделать намного проще
  
• Вы слишком полагаетесь на то что реальный контент будет точно соответствовать вашему демо-контенту, а на практике это обычно не так. К примеру:
  
  • попробуйте в .post section добавить не один параграф, а два
    
  • попробуйте использовать "Константин Константинопольский" в качестве имени автора в .post-meta-author
    
  
  
  
• У вас явно прослеживается неумение думать об элементах макета как об иерархической структуре, вы рассматриваете её как плоскую общность элементов. К примеру возьмите .post: Этот элемент обладает очень простой структурой - общим внутренним отступом из которого иногда "вылезают" элементы (к примеру картинка на мелких экранах), но у вас это какие-то кусочки отступов, применённые к разным внутренним элементам, причём иногда даже не к непосредственным потомкам, часть отступов - margin, а часть - padding, в общем полный бардак. Это делает макет весьма хрупким и сложным в поддержке. Вам стоит немного углубиться в теорию и выстроить у себя внутри понимание того как именно взаимодействуют элементы между собой
  
• В мобильном меню кликабельная часть ссылки - только её текст, лучше чтобы это было всё пространство элемента меню.
  

По HTML

• Не надо так с lang, установите корректно
  
• Где ваш some.php?
  
• Старайтесь не увлекаться одинаковым контентом у повторяющихся элементов, тем самым вы лишаете себя возможности проверить поведение макета с реальным контентом.
  
• Вроде незаметно, но это ломает выравнивание элементов на странице. Видите суслика? :)
  

По JavaScript:

• Использование let в JavaScript коде приводит к ошибкам в MSIE, если вы вдруг собираетесь его поддерживать
  
• Хранить у себя внешние зависимости, которые вы к тому же устанавливаете - плохая идея, забирайте код из node_modules при сборке проекта
  
• Код ваших скриптов лучше оборачивать в самозапускающуюся функцию

  (function(window, document) { ... })(window, document);

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

Использую по возможности всё что есть в Sass и хотелось бы видеть в нём больше. Активно использую и переменные и миксины и функции и placeholder'ы и list'ы и map'ы и т.п. Многие практические задачи намного легче решаются через препроцессор, те же CSS variables ни разу не замена.

Конечно для того чтобы код не превратился в кровавое месиво - необходимо соблюдать правила, но это справедливо и для любого другого языка программирования. Да и без использования препроцессоров я видел огромное количество write only css который невозможно нормально поддерживать.

Вопрос поддерживаемости - он не лежит в плоскости используемого инструмента, а является следствием наличия или отсутствия архитектуры в проекте. Если макеты дизайнера сделаны в стиле "я так вижу", без внутренней логики, если всё это сверстал верстальщик по принципу "что вижу - то и сверстал" - то никакое наличие или отсутствие препроцессора на поддерживаемость кода не повлияет.

С другой стороны наличие определённой архитектуры и следование ей в проекте даёт возможность относительно безболезненного рефакторинга стилей и оставляет код стилей поддерживаемым и расширяемым. Препроцессоры здесь только на пользу.

flex-shrink и flex-grow не имеют прямого отношения к размерам элемента в том плане что они не определяют размер напрямую (для этого есть flex-basis). Эти свойства определяют поведение элемента при сжатии (shrink) и расширении (grow).

Т.е. если значение этих свойств ненулевое - то элементу разрешено сжиматься / расширяться, причём с коэффициентом, определяемым значением этих свойств. При нулевом значении соответствующее изменение запрещено.

Более подробно можно почитать, например, на MDN (раз, два)

Причина вашей проблемы в непонимании того как работает псевдо-класс :first-of-type. На Stack Overflow есть пара очень хороших объяснений этого, стоит ознакомиться (раз, два).

Ключевым моментом для понимания должен стать тот факт что в контексте HTML понятие "element type" эквивалентно имени тега. Таким образом ваше ожидание что .services-block:first-of-type означает "первый элемент с классом services-block" ложно и это приводит к неработающему селектору. В реальности этот селектор читается как "любой подэлемент текущего элемента, имеющий класс services-block и при этом являющийся первым элементом с таким именем тега среди всех имеющихся". Слегка контр-интуитивно, да, но уж как есть.

Вашу задачу можно решить если вы вспомните что div - не единственный элемент в HTML и начнёте использовать также и другие элементы. В вашем примере для div.basic-title и div.services-block_title явно лучше подходят какие-то из элементов заголовка, а структура из div.services-block_item и подэлементов - это явно dl/dt/dtt

Простая замена заголовка на какой-либо Hx элемент позволит использовать селектор

.container > div.services-container:first-of-type > .services-block:first-child

.

Также можно ничего не менять, тогда селектор получится несколько более жёстким:

.container > .basic-title + .services-container > .services-block:first-child