It

Ну что, неужели никто не отслеживает сколько с поддоменов переходит на основной сайт?

Всё решилось в разы банальнее чем сначала казалось. Все эти массивы с переборами абсолютно не нужны. Повесил на кнопки обработчики onclick="this.parentElement.classList.toggle('visible');" и всё. На закрытие такоё же только с parent.parent. Так что вопрос исчерпан.

Пробовал кучу вариантов статических сайтов для блога, и джекил и хуго и нодовский ghost, в итоге получил некое самоудовлетворение от того, что оно заработало, но как только начал работать с ним это всё превратилось в ад. Статика лично тебя привяжет ко всем работам, постоянный головняк, плюс как правильно заметили с тегами и фильтрацией нельзя никак работать, а в блоге это прям маст хев.
Никто из фрилансеров-копирайтеров\контентщиков не хочет работать с замороченными системами.
В итоге перевел на WP, заказал у специалистов нормальную настройку под PageSpeed и наступил дзен. Так что ИМХО - не следует изобретать велосипед. Статика это для несколько-страничных сайтов-визиток, которые сделал и забыл на 10 лет, не более того. Ну или же сразу нанимать в штат того кто будет этот сайт ковырять каждый день.

По факту проблемы не было, просто почему-то GA показало все цели на следующий день только, а не сразу как События.

Если вдруг актуально:
1. Устанавливаем аддон Shell launcher
2. Идем через ctrl + shift + p в Keyboard Shortcuts json (просто вводить начинаем и появится в подсказаках), добавляем нужное сочетание клавиш для себя в формате

[
       { "key": "ctrl+alt+t", "command": "shellLauncher.launch" }
]

3. Идем в файл настроек settings json (Files --> Preferences --> Settings) и там в конце вставляем:

"shellLauncher.shells.windows": [
       {
           "shell": "C:\\Windows\\sysnative\\cmd.exe",
           "label": "cmd"
       },
       {
           "shell": "C:\\Windows\\sysnative\\WindowsPowerShell\\v1.0\\powershell.exe",
           "label": "PowerShell"
       },
       {
           "shell": "C:\\Program Files\\Git\\bin\\bash.exe",
           "label": "Git bash"
       },
       {
           "shell": "C:\\Windows\\sysnative\\bash.exe",
           "label": "WSL Bash"
       }
]

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

{
  "liveSassCompile.settings.formats":[
   {
      "extensionName": ".min.css",
      "format": "compressed",
      "savePath": "/site/public/stylesheets/"
   }
 ],
 "liveSassCompile.settings.excludeList": [
    "**/node_modules/**",
    ".vscode/**",
    ".git/**"
 ],
 "liveSassCompile.settings.generateMap": false,
 "liveSassCompile.settings.autoprefix": [
     "> 1%",
     "last 10 versions"
],
"emmet.triggerExpansionOnTab": true
}

Это рабочие настройки.
SavePath укажи нормальный вместо null.

А кто мешает использовать 4 разные доп класса? Каждому классу задайте нужную позицию как всплывающего так и треугольника.

Пробовал множество разных вариантов верстки, от самого "ручного" до webpack или gulp. В итоге понял, что если сайт не SPA, а просто лендинг или корпоративный многостраничник, то идеальным по скорости подготовки и удобству лично для меня является алгоритм:
1. Папка обычной структуры index.html + /img + /css + /js + /fonts + /sass .
2. Сразу инициализирую репозиторий (использую битбакет, а не гитхаб).
3. Открываю папку в VSCode, копирую настройки из любого другого проекта для плагинов.
3.1. Если только начинаем использовать VSCode, то нужно сразу поставить плагин для автокомпиляции Sass в CSS в онлайн режиме (Live Sass Compiler), этот плагин на лету конвертит код + сразу автопрефиксера функционал имеет + css map + минификация. Один раз настраиваем его для всех проектов.
3.2. Ставим Live Server, один раз настраиваем его для всех проектов.
3.3. Подключаем репозиторий во вкладке для репозиториев в VSCode
4. Всё, начинаем работать.
Я пропускаю шаг по настройке VSCode всякими мелочами типа линтеров, подсвечивалок кода, и прочего, тут кому что удобнее.

Такая связка позволяет использовать один инструмент (VSCode) для комфортной и быстрой верстки, если все в норме настроено, то я пишу\правлю код и тут же сразу всё вижу в браузере, не нужно ни обновлять ничего не подтягивать, ни ставить плагины в браузеры. Sass использую давно, ИМХО, ускоряет написание стилей в разы, и это при том, что не использую обычно даже миксины, максимум иногда готовые куски кода, а так обычно только дерево делаю через &, чтобы не писать по BEMу длиннющие цепочки руками и переменные через $.

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

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

Для SPA, когда нужен React или Vue тут да, webpack, а на простой верстке - лишнее.
Как-то так, спрашивайте, критикуйте)

Вообще интерактивные элементы под ховерам не делаются для мобильной версии или планшетов т.к. на них только тапы, без мыши, нечем наводить, а значит интерактив можно делать только до 1024 условно, а меньше или убирать интерактив вообще или переходить просто на показывание элемена по нажатию кнопки, а это обычный display: none и position: absolute по удобным координатам.

Изначально ориентируюсь на Хром + Сафари. Для оконщиков самым удобным делать Хром + FF (или EDGE), т.к. вторые ближе к сафари.
А вообще по практике если говорят, что есть косяк в том же сафари, то просто открываешь в IE10 и там видишь этот косяк гарантированно, соответственно исправляешь. Ослик конечно неприятная штука, но если она отображает нормально, то и все остальные будут с 99,9% тоже отображать нормально.
P.S. Автопрефиксер уже даже не рассматривается как нечто дополнительное, он в принципе по-умолчанию должен быть.

Или адрес админки изменен при установки с manager на что-то еще или проверьте редиректы с http. У меня такая проблема была один раз после перехода на https.
Ну или совсем невозможный вариант - проблема с браузером и дополнениями к нему, которые что-то блокируют или меняют (аля modify headers и т.п.).

Сетка необходима для соблюдения симметрии элементов. Используйте любую, какая подойдет лично вам.
Если вы будете для верстки использовать готовый фреймворк типа бутстрапа или фаундейшн, то вам следует взять сетки от соответствующего фреймворка, т.к. по этой сетке будет выполняться и адаптивность элементов при изменении размеров экрана.
Размеры экрана сейчас самые ходовые 1600px и 1366px. Но тут решать вам, многое и от макета зависит, если шахматка безрамочная, то пределов ширины вообще не будет, за ориентир можно и 1920 брать, без разницы.

Самая простая CMS - та, которую знаешь.
Если нужен полный готовый конструктор из коробки, то смотрите в сторону CMS изначально заточенных под интернет-магазины, из бесплатных простая и с шаблонами OpenCart, платных навалом в гугле на первых позициях.
Если есть возможность заказать разработку, то как вариант ModX Revo из бесплатных (советую сквозь призму своих умений).

Имхо, зависит от частоты и объема страниц. Если все отдельные лендинги это самостоятельные разделы, информационно не связанные с друг другом и если пользователь в большинстве случаев ищет только один из этих разделов и по другим не переходит, то нужно делать один общий файл normalize, как написали выше, и отдельные для каждого лендинга. Как минимум уменьшишь объем килобайт скачиваемых пользователями.
А если лендинги связаны между собой информативно и по ним пользователи прыгают, то делать один.

Я бы в любом случае начинал использовать сборщик и методологию. Разбивай как хочешь файлы, по любому принципу, а в продакшен пойдет только один и уже оптимизированный.

Конкретно сейчас может и не нужно, но завтра появится необходимость изменить/расширить проект и все равно нужно будет на что-то сажать.
Выберете что-то не создающее кучи левого кода и влейте туда ваши 4 страницы. Тот же modx revo, создайте 4 статические страницы просто скопировав код в поле контента и всё. Как минимум проще зайти в админку чем изменять файлы локально и лить их на хостинг.
Имхо, вопрос даже не в динамике, а в элементарном удобстве. Как ни странно тот же WP, Joomla и прочие типа простые CMS требуют на порядок больше времени (изучение) для такой банальной задачи.

ModX Revo, еще задел на будущее останется, прикрутить все что угодно можно

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