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

SVG, прокачанный на математических расчетах.

В этом примере фоновую картинку стоит сделать не частью фона всего блока, вложенный в родителя и с заданными размерами + background-size: cover с отсчетом позиции от правого нижнего угла.

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

В примере несколько вещей не очень:
1. Пустой тег header. Т.е. незаполненный классом.
2. Как в принципе верно подметил g33km нормой считается вкладывать в тег списка, потому что многоуровневую навигацию так проще оформлять за счет прослоек.
3. Но наличие пустых тегов тоже идет вразрез БЭМ-у, так как для вложенных элементов должны быть классы, которые позволяют ими управлять. Инкапсуляция классами предполагает отстраненность от тегов, хотя и и приходится на всякий случай (а для списком в обязательном порядке) обнулять отступы и т.д.
4. То, о чем говорит в своем ответе g33km:

Если данная навигация будет использоваться в разных местах в одном и том же виде, то ей не нужен класс .content-header__nav

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

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

<header class="content-header">
    <a 
        href="/"
        class="content-header__logo logo">
        <img 
            src="/img/logo.svg" 
            class="logo__image"
            alt="">
    </a>
    <nav class="content-header__nav nav">
        <ul class="nav__list nav__list--inline">
            <li class="nav__item"><a href="" class="nav__link"></a></li>
            <li class="nav__item"><a href="" class="nav__link"></a></li>
            <li class="nav__item"><a href="" class="nav__link"></a></li>
            <li class="nav__item"><a href="" class="nav__link"></a></li>
        </ul>
    </nav>
</header>

...

<footer class="footer">
    <nav class="footer__nav nav">
        <ul class="nav__list nav__list--column">
            <li class="nav__item"><a href="" class="nav__link"></a></li>
            <li class="nav__item"><a href="" class="nav__link"></a></li>
            <li class="nav__item"><a href="" class="nav__link"></a></li>
            <li class="nav__item"><a href="" class="nav__link"></a></li>
        </ul>
    </nav>
</footer>

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

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

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

Удивительно, но заказчик прав. А тебе рекомендую обратиться к документации, что есть footer и header. Там же и найдешь уточняющую информацию к моему ответу.

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

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

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

отловить события и при неудачной попытке лишь добавить класс

Вопрос в ответе, лучше пока не придумали.

https://masonry.desandro.com/ или grid (+ dense)

Да, все ок.

Семантика — определение содержимого. Внутри формы поле ввода и label к нему.
Спаны и дивы — нейтралы, строчный и блочные соответственно. Более того, у form нет каких-либо жестких требований к оформлению, более того, ты можешь кнопку активации вынести за ее видимость, а <fieldset> — это из области приятных бонусов, присущие хорошей форме, содержащей множество полей ввода.

1. SVG
2. ClipPath
3. Трансформации типа поворота (при overflow hidden)

1. Дизайнер, конечно, не очень умный. Бесспорно. Такие решения согласуются на тему адекватности и профессионализма верстальщика + ресурсозатрат на уровне человекочасов и клиента (браузера).
2. Это легко делается на SVG, оно по идее прямо в макете есть, с помощью самого SVG или CSS ты можешь применить маску.
3. Можно поизвращаться в бордер-радусами.

1. Выбираешь бэк, на выбор тьма ЯП: PHP, Python, Node.js, Java и т.д. Ну вообще буквально по барабану.
2. Заводишь базу данных: SQLite\MySQL (одного из двух с головой хватит)
3. Пишешь логику MVC.
4. Пишешь форму, которая будет собирать данные, отправлять их в экшн на бэке, который создаст новую модель, занесет в нее свойства, что ты в форме указал и сохранит это безобразие в базу. База это читай эксель, который просто так руками не взять (на самом деле можно PHPMyadmin\DBBrowser).
5. На главную они просто так не попадут, тебе надо будет написать вьюху, в которую выбрать из базы записи моделек, и циклом вывести (скорее всего шаблонизатором, но это неточно).

5.1 То, что приходит из базы можно фильтровать, скажем сортировать по дате и т.д. Это уже по части языка SQL.

Прием, прием, из будущего 2021-го:
— Верстают все так же.

1. Смещение в пределах разумных допусков
2. Для межбуквенного — https://developer.mozilla.org/ru/docs/Web/CSS/lett..., да, я видел это в вопросе.
3. Если это макет без пользовательского ввода, можно вгонку и выгонку осуществлять вложенными span-ами и загонять разнообразные шпации, кастомные переносы и т.д.

Нус в общем Роман ответил в комментариях по делу, разве что я бы порекомендовал проверять подстроку, так как request.path может содержать вложенную директорию, к примеру, а проверка в духе if '/' in request.path (не помню точно, умеет ли в такие проверки Jinja2, но если что можно функцию набросать).

Но тут будет другая проблема, что есть пути частично совпадают, тогда проверка будет провдена в обоих случаях, поэтому ИМХО, лучше поднимать из шаблона, который наследует или прямо из функции, которая запускает рендер идентификатор, проверка которого и будет в шаблоне в этой навигации.

Скажем в роутах:

...
render_template('template', current='home')

И в самих шаблонах:

<nav class="navigation block">
    <a class="nav-link {% if current == 'home' %}active{% endif %}" href="/">Главная</a>

Максим Ленский продемонстировал ответ на вопрос. Маску для картинки: она встраивается в документ и применяется по необходимости.

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

1. Задать отступ для размещения тени.
2. Использовать отрицательный отступ на те же значения, чтобы не уехала сетка.

Дополню ответ azerphoenix.

Все иконки стоит обрабатывать вручную, так как:
1. В верстке они регулируются только по ширине. Да, можно задать условия выравнивания относительно друг-друга или захардкодить размеры, но чем дальше, тем сильнее сердце сжимает от костыльности решений. Базово это ширина. Следовательно, чтобы все они были +- на одной горизонтальной оси — их надо сделать одинаковой высоты и выровнять прямо в ФШ. Верстальщик, если это не ты, спасибо скажет.
2. Все иконки имеют разный визуальный вес и за счет масштабирования ты, как дизайнер, можешь привести их к единому знаменателю, опять же, вручную.

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