Ivan Bogachev

Копирайтер - это сильно растяжимое понятие. Но в целом от этого человека могут ожидать, что он в состоянии структурировать контент в каком-то формате. Чтобы заголовки были заголовками, ссылки - ссылками, картинки - картинками, и.т.д. Тут речь идет не про полноценную верстку, а именно про структурирование информации. В контексте веба для этого могут быть нужны самые основы HTML. Где-то могут ожидать и основы CSS на уровне "цвет заголовков поменять". А могут и не ожидать. Нужно узнавать в конкретном месте. Но в любом случае там информации на день изучения. Школьники все это на уроках информатики проходят классе в 9. Какие-то прямо курсы тут не нужны - эти темы уже были пережеваны миллион раз и всегда были в открытом доступе.

при нажатии на дату в div недели добавляется div card... есть вариант удобнее?

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

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

неделя
    числа
        день1
        день2
        деньN
    бронирование
неделя
    числа
        день1
        день2
        деньN
    бронирование

При таком подходе на одном уровне будут только недели, на другом - только числа. А посередине - простое разделение компонентов недели на логические части. Это должно быть удобно и с позиции CSS, и из JS. И не нужно будет ничего изобретать.

В CSS и SVG есть какие-то градиенты и фильтры, из которых можно что-то такое плюс-минус собрать. Ну и вариации clip-path или масок, чтобы обрезать. Но. Логика формирования градиентов там своя, и она не всегда хорошо подходит под идею, как оно должно выглядеть. Иногда все мешается очень грязно, или какие-то полосы появляются. Не идеально там все. Много костылей нужно подставлять. Если будет нужна какая-то совсем особая интерполяция - то от количества костылей и подпорок тошно станет. Один раз подогнать можно, но с автоматизацией могут возникнуть сложности. А задача построения диаграмм почти всегда требует автоматизации. Это может быть не совсем очевидно с самого начала, но усугубляется там все очень быстро. Так что может иметь смысл сразу брать canvas и делать свою логику под свои хотелки. Там мы нарисовать можем что угодно, мы уже не зависим от браузера и его представлений о градиентах. Это более сложное решение в своей основе, чем подбор градиентов в SVG, но более перспективное в плане его дальнейшего развития.

Для начала для нас важно осознать, что у разных фильтров разная вычислительная сложность. Они не все "плохие". Алгоритмы для brightness, grayscale, hue-rotate и других манипуляций с цветом выполняются за O(1) для каждого пикселя. Т.е. нагрузка на железо растет линейно в зависимости от площади элемента на экране. Это не так страшно. А вот фильтры размытия, blur или drop-shadow, имеют сложность где-то в районе O(R^2). Там есть разные варианты оптимизаций, но в среднем мы говорим именно о квадратичной зависимости от радиуса размытия. И это для каждого пикселя. Именно отсюда мы имеем сильные тормоза при попытке что-то большое размыть на пол экрана. Дохлые видеокарты телефонов и ноутбуков не вывозят. Браузеры не умеют такие вещи переиспользовать, так что это переразмытие происходит снова и снова, и мы имеем что имеем.

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

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

С точки зрения производительности в CSS анимациях почти всегда имеет смысл сразу смотреть на свойство transform, а не на width или height. А в терминах трансформаций у нас для изменения размеров используются вариации функции scale():

50% {
    transform: scaleX(0.9) scaleY(1.1);
}

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

как решить?

.img img {
    display: block;
}

Всё это нужно для затемнения фотографии

Можно рассмотреть еще вариант без отдельного элемента с фоном:

img {
    filter: brightness(0.6);
}

Вероятно вам нужен обычный transition, он будет срабатывать каждый раз, когда значения будут меняться:

.items {
    .single-chart {
        .circular-chart {
            .circle {
                /* animation: progress 1s ease-out forwards; */
                transition: stroke-dasharray 1s ease-out;
            }
        }
    }
}

У нас три координаты - XYZ. Для CSS все элементы на странице - плоские, у них нет толщины, и их размеры по оси Z нулевые. Поэтому CSS за нас не угадает, куда должен смещаться transform-origin по оси Z для кирпичика, который существует исключительно в нашем воображении. Вы смещаете грани кирпичика в отрицательные значения по оси Z, но точка transform-origin, через которую проходит ось вращения, остается в плоскости Z = 0.

Получается, что вам нужно как-то вручную совместить ось вращения и центр кирпичика. Тут два пути - либо сместить точку transform-origin на пол кирпичика вглубь по Z:

.cube {
    transform-origin: 50% 50% -25px;
}

Так ось вращения будет проходить через его текущий центр. Либо сместить грани кирпичика, чтобы он изначально собирался не "весь вглубь экрана", а "половина вглубь, половина к нам". Его центр сразу будет в плоскости Z = 0, где по умолчанию находится transform origin, и не нужно будет ничего дополнительно двигать.

Вариант с градиентами - сложный для анимирования. Рисование линий со stroke-dasharray - это стандартный выбор. Но dash array может быть длинным, им можно описать самые разные последовательности линий и пробелов, так что если вам не нужны разные цвета, то можно сделать одну линию:

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

Хорошего нативного и кроссбраузерного решения у нас пока нет. Но у path в SVG есть методы getTotalLength и getPointAtLength, а из них можно сообразить себе утилиту для расположения кружков вдоль кривой в удобных единицах измерения. Это не так здорово, как на CSS, но тем не менее:

function putCircleOnPath(path, circle, percent) {
    const length = path.getTotalLength();
    const point = path.getPointAtLength(length * percent / 100);

    circle.setAttribute('cx', point.x);
    circle.setAttribute('cy', point.y);
}

Получится что-то такое: