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

NodeList это не массив. Это NodeList. И его можно «крутить» в обе стороны за счет перемещения Node-узлов (append\prepend и т.д.). Остается только прикрутить анимацию (для начала).

Можно и в массив конвертировать, да крутить средствами массивов.

Повышай специфичность или используй !important.

Но вообще дешевле будет пройтись с автозаменой на регулярках.

Абсолютное позиционирование, только так. Идеального результата не будет. Задавать надо в процентах с учетом процентного заполнения картинкой (можно не бэкграундом делать, а вставлять картинку, которая задает размер). Когда изображение пропорционально масштабируется легче угадать позицию текста в процентах.

Но изображение уменьшается, а текст нет, поэтому корректировку надо делать под медиазапросы. И не на уровне «переберу стандартные», а править там, где выглядит косячно.

Как вариант еще можно вырезать картинку лампочку из фона и использовать ее в рамках сетки, можно даже применить гриды, чтобы было типтопчик, но без медиазапросов это все равно обречено на провал.

Области должны совпадать\пересекаться. Если между пунктом и выпадаюшим меню есть воздух, то ты снимаешь событие наведения.

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

Ну допустим можно на двух элемантах, которые будут расчитаны на JS (два фона) + псевдоэлемент для пункта меню, который дорисует фон справа от него. Но это скорее тупиковое, хотя и интересное решение.

Те же самые расчет лучше оформить на уровне SVG-отрисовки. Собсно, вызывая расчет по клику.

Край — можно мягко намекнуть дизайнеру, что он...

Потому что переключается ресурс на другое начертение шрифта, если кратко и грубо.

Для анимации текста оптимально использовать svg на уровне path-ов.

Абсолютное позиционирование с точкой отсчета right будет всегда расчитано от правого края элемента. При каждом его изменении. Чтобы зафиксировать, необходимо указать точку отсчета слева.

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

Привязать это к изменяемому классу, а не вот это вот все.

Как запутаться в трех соснах.

Решение →

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

Для визуализации алгоритмов испокон веков существуют блок-схемы. Ничего нового выдумывать не надо.

Героя ждали и он пришел нежданно.

БЭМ необходимо знать достаточно, чтобы уловить концепцию и разбираться в спорных моментах. Я собрал большой материал тут под расширение примерами и уточнений.

Не использовать text-align: justify в принципе. Но в данном случае можно не использовать с применением медиазапроса.

Да, сжимать руками в редакторе.

ЗЫ: что 5,5 мегабайт, что 6,16 — это архидохрена.

Подключение может быть не защищено потому что на сайте присутствуют связи с сайтом\сайтами на http (обычно отображается в адресной строке, как сломанная иконка замка). Или может htaccess настроен некорректно или вообще не настроен.

Иными словами, проблема не в папках, это в принципе странный атавизм, который скорее всего никто и не использует. С ссылкой гадать было бы проще.

В примере несколько вещей не очень:
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, чтобы покрасить в шапке в белый цвет, а в подвале нет (базовым цветом может быть черный у ссылок).

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

Дописать для этого стили.