Алексей Николаев

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

link.addEventListener('focus', (e) => e.target.blur()); // или фокус на следующую

Ну во-первых, тебе в любом случае придется подписаться на обновление таймера. Без вариантов. Поэтому первым делом определяешь обработчик для setInterval в 1-5 секунд.

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

const range = [Date.now(), Date.now() + 3600 + 12]; // типичный интервал

В-третьих, имея интервалы и обработчик, дело остается за малым. Каждый тик таймера проверяй, не входит ли текущее Date.now() в какой-либо из интервалов. Если входил, обновляй нужные данные, как-то: вешай нужный класс, рассчитывай процент "заполненности" интервала.

В принципе, это все. Алгоритм расписал, дело за реализацией. Удачи.

Извращение какое-то. В этом нет никакой нужды. БЭМ, с которого вы, определенно, сделали кальку, прекрасно применяется к иерархии директорий, что позволяет понять, что куда вложено, по импорту. Тот же БЭМ, кстати, пропагандирует самодостаточность компонентов с минимальными зависимостями между оными. Исключения - когда какой-то элемент действительно предназначен для конкретного домена, там можно и нужно указать принадлежность. HeaderMenu, TableCell и так далее.

Тем более, вложенность. Сегодня она у вас такая, а завтра - этакая. Я давно остановился на domain-driven структуре и не жалею, на мой взгляд, она идеальна. Просто декларативно распределяем компоненты по зонам их ответственности, по доменам. HeaderMenu в Header и так далее.

С появлением css переменных вообще подумываю от препроцессоров отказаться, ведь важный для меня пункт 2 из моего списка, также имеет побочные эффекты в виде усложнения поиска селекторов по проекту.

Ну и зря. У меня на галере капитан заставляет гребцов возвращаться в 90е, т.е. когда де-юре scss, а по факту пишем по старинке, все каскады друг за другом, в одну строчку, без вложенности. Вот где мат стоит. Из аргументов как раз ваше "ну, искать селектор тяжело, если ошибка на продакшене". И не вразумить, он жи "синьор-помидор". Кекмда.

Сам использую scss, не мыслю жизни без препроцессоров. У css-переменных есть только одно преимущество: декларативность, когда меняешь переменную и все меняется сразу же. По факту, очень удобно только менять темы на лету, что напоминает мне детские игры (хотя выглядит круто). Прозрачность переменной не сделаешь. В другой тип переменную не переведешь. Куча каких-то ограничений.

Единственный путь использовать css-переменные в сложном проекте, где они используются не только для однократного присвоения значения, но и для построения сеток, для перевода px в em \ rem, для динамического формирования спрайтов и цветовых схем; нужно идти по пути усложнения. Путь этот геморроен, но достоин любителей live on the edge. Нужно сделать так, чтобы для каждой scss-переменной существовал css-собрат, и добиться их синхронизации. В итоге получаем на деве исходники с мощью scss, на проде - мощь css.

Возможно. С помощью JS.

Да много чего можно, в принципе.

1. использовать outline вместо border
2. сделать margin-left: -1px у всех не первых карточек в строке
3. сделать margin-right: -1px у всех не последних карточек