SelenIT

appendChild, конечно же, добавляет в конец предка (по смыслу слова append). Чтобы вставить перед определенным элементом, нужно использовать insertBefore. Где стоял тег <link>, обоим этим методам неважно.
Кстати, HTML-импорты по факту поддерживаются только в Хроме, но и оттуда их собираются выпилить. Не прижились ?

button — некая «вещь в себе», которая заключена в «волшебный» контейнер с display:inline-block, и плювать хотела на явно заданные стили, к сожалению:(. Очень многих лет уговоров стоило убедить разрабов браузеров (прежде всего Мозиллы), что такое поведение — не фича, а вообще-то баг, и что display кнопки должен слушаться заданных стилей (в частности, кнопка должна уметь становиться флекс- и грид-контейнером), но display:inline для кнопки — последний рубеж, который пока никак не поддается. Единственный известный мне обходной путь — задать кнопке display:contents и работать со вложенным в нее span-ом — работает пока только в Хроме с включенным экспериментальным флагом (возможно, в Сафари ТП теперь тоже). В качестве обходного варианта можно задать для кнопки <label>, а саму кнопку скрыть (как при кастомизации чекбоксов/радио).

Приоритеты по специфичности относятся к разным селекторам, применяющимся к одному и тому же элементу. Но любой селектор,  применяющийся к самому элементу, всегда приоритетнее стилей, доставшихся этому элементу по наследству (неважно от кого). Поэтому для ссылки приоритетнее стиль, заданный конкретно для ссылок, чем стиль, доставшийся ей по наследству от body или элемента с классом. И т.д.

У вас в атрибуте style стоит сокращенное свойство background, которое включает в себя background-size и, соответственно, перебивает его (на дефолтное значение auto в данном случае, т.к. не указано иное). Указывайте там только background-image, а всё остальное (включая background-size) перенесите в стили, и всё будет ОК.

Почему это внутри цикла? Вот кнопки, кроме первых трех, и оказываются вне формы...
Вообще возьмите за правило — отлаживайте ту часть системы, в которой проблемы, а не всю систему как «черный ящик». Если проблема в работе HTML — смотрите сгенеренный HTML, а не PHP-исходник. Так будет намного нагляднее и быстрее...

Вот это, к сожалению, CSS-ом сейчас никак не описать. Ни плюсик, ни тильда не умеют проверять наличие/отсутствия текстовых нод. Умеет только :empty, но он, очевидно, тут не подходит.
Так что добавлять padding инлайновым элементам, над которыми нет полного контроля — изначально была не лучшая идея. Теперь, если юзер сделал бяку, придется терпеть :(. Можно разве что немного смягчить последствия бяки отрицательными margin-ами, прозрачностью у фона и разрядкой букв, чтобы стыки padding-ов внутри были не так заметны, типа такого...

Универсально убрать это расстояние, к сожалению, нельзя. Это внутреннее расстояние резервируется для выносных элементов букв (всевозможные хвостики-завитушки у f, например) и диакритических знаков (немецкие «умляуты», французские «аксаны» и прочие родственники наших точек над Ё и «улыбки» над Й), а его точный размер зависит от конкретного шрифта и значения line-height. Для небольшого размера шрифта  можно лишь «методом тыка» подобрать необходимую поправку с приемлемой точностью. Подробнее про это расстояние и откуда оно берется — в этой статье.

По-простому — в элемент можно вкладывать всё, что можно вкладывать в его родителя. Например, если <a> лежит непосредственно внутри <div>, то в нее можно вкладывать другие дивы, абзацы, списки и т.п. (всё, что можно вкладывать в сам <div>). Но если <a> внутри <span>, то ничего этого нельзя (потому что в <span> этого нельзя) — можно только «Phrasing content» (голый текст и то, что в прошлой жизни называлось «строчными элементами»).
Кроме <a>, такая же модель у <ins> и <del>. Помимо этого, у <a> еще своё дополнительное ограничение на интерактивные элементы (напр. кнопки, инпуты и саму <a>). Но это уже отдельная история:)

IE4-8 включительно. Которые давно 1) составляют мизерные проценты, 2) работают на таком древнем железе, что лучше не грузить его никакими необязательными красивостями.
Потому что та древняя технология не умеет в разные варианты одного font-family. Там было тупо 1 font-family — 1 файл.
Было дело. Но опять же, очень давно, сама Apple давно не поддерживает те версии iOS и то железо, на котором с нее нельзя обновиться, да и не живут обычно столько даже эпловские девайсы:).
Сейчас woff и woff2 достаточно каждому (с). Даже ttf уже не особо нужен.

CSS2.2 — та же CSS2, но с исправленными ошибками, найденным после выхода CSS2.1 (напр. в нем не забыт табличный контекст форматирования). Некоторые ошибки еще в процессе исправления/уточнения. В какой-то момент заменит CSS2.1.
CSS3 — неофициальное собирательное название для всего, что вышло после CSS2, независимо от уровня. Модули начинаются либо с 3 уровня (если дополняют то, что было в CSS2), либо с 1 уровня (если вводят что-то принципиально новое). Так что модули 4, 5 и т.д. уровней формально относятся к CSS3 (хотя это звучит дико, поэтому сейчас лучше говорить просто о "языке CSS", без цифр). "Версий" как таковых у CSS сейчас нет.

Implementors — именно «реализаторы». CSS реализуется в браузерах. Авторы самого CSS (спецификаций) — это specifiers.
В принципе, всё относится ко всем, просто в разной мере. Например, описания алгоритмов, как и в каком порядке что должно рисоваться, какие координаты откуда и как рассчитываются и т.п., важнее для разработчиков браузеров — им надо перевести эти описания в реальный код рендеринга, наделав в этом как можно меньше ошибок. Поэтому им приходится разбирать эти алгоритмы в мельчайших деталях, порой уточняя спецификацию по мере необходимости. Но авторам стилей (нам) желательно иметь представление об этих алгоритмах хотя бы в общих чертах — чтобы знать, в каких ситуациях чего от них ждать, и что в какой ситуации эффективнее решит конкретную задачу в верстке.

Может быть, BOM-метка?

Не обязательно, :not(.что-то) без указания тега равнозначно *:not(.что-то), соответствует любому тегу, не имеющему класса .что-то.
По сути да. Между .q1 и целевым li, кроме ul.q77, есть еще один ul — .q2. Поэтому формально условие селектора «внутри какого-нибудь ul без класса .q77, находящегося внутри .q1» выполняется.
 

Так зачем отказываться? border-image же всё нужное уже умеет, кажется?
Ну не сказал бы...

Вообще, если нет аллергии на слово table, то самое простое и, имхо, прямое решение — display:table для ссылок (вместо block). Делает ровно то, что надо — сохраняет поведение блочным, но ширину ужимает до содержимого. Из побочек — разве что с max-height могут быть проблемы.
Если такая аллергия есть, можно задать ссылкам float: left; clear: left; а панелям — .clearfix или (имхо, лучше) overflow:hidden, чтоб эти флоаты не «цеплялись» за соседей.

Типа такого?

Да, в данном случае в выборе между формальным соблюдением стандарта и быстротой первичной отрисовки страницы Гугл рекомендует второе. Да, формальное нарушение спеки, но в некоторых случаях оправданное. Да, удовлетворить валидатор и PageSpeed Insights одновременно не всегда возможно — выбирайте приоритеты.
Справедливости ради, сейчас WHATWG-шная спека разрешает <link rel="stylesheet"> внутри <body>, так что можно делать как-то так. По W3C-версии это по-прежнему невалидно, но... кого она волнует?)

И только в начальный/конечный момент применяется top, заданный непосредственно шарику (280px). Вот и получается, что между 91% и 100% он, плавно проявляясь из прозрачности, меняет top с 480 на 280px — «выпрыгивает снизу». А к отметке 33% опять туда опускается.
P.S. Зачем никому не нужные -moz-animation-* и особенно -ms-animation-*, и где, где стандартный беспрефиксный animation-*?

Еще :first-of-type есть, тоже может пригодиться для подобных случаев.

Скорее всего, нет слеша в начале пути к картинкам. Отчего браузер пытается искать их от (несуществующей в реальности) папки /korotkie/zheleznye/.

А так нельзя?

Добавьте vertical-align: top вашим «ячейкам» (aside, article). По умолчанию содержимое ячеек выравнивается по базовой линии, в ее расположении браузеры и расходятся (в спецификации этот момент описан довольно запутанно, так что какое поведение правильное — вопрос интересный ).
 
P.S. От main в качестве общего контейнера и aside у него внутри наворачиваются слёзы (а селекторы по тегам усиливают эффект). Ладно б еще это был по факту мертворожденный section...

Сходу на ум приходит только вариант с display: table и очень маленькой шириной для контейнера, которая благодаря «особой табличной магии» работает как желаемая ширина, но фактически блок растягивается по картинке.
 
Может быть, кто-нибудь подскажет вариант лучше (хотя лично я в display:table, примененном прицельно и к месту, ничего зазорного не вижу).

Ага, поторопился я с прошлым ответом (про фон)
 
Вроде position: relative; помогает. Вообще, конечно, налицо баг реализации ellipsis в Фоксе. Судя по всему, этот.

Как вариант, можно задать стиль только для тех img, которым атрибуты не проставлены:
img:not([width]) {    width: ...px;}img:not([height]) {    height: ...px;}Ну или наоборот, если проставлены — переопределять на auto, как предложено выше...