Алексей Уколов

Можно, для этого достаточно понять, что написано в коде. Если же вы хотите, чтобы код переписали за вас, то для этого есть фриланс, на Тостере задания не решают.

Этот формат записи цветов включили по-умолчанию в Chrome 62.
Судя по селектору, это обычный сброс стандартных стилей - у всех перечисленных элементов убирается фон. Вы можете поменять формат отображения цветов в этой панели.

Большинство email-клиентов просто проигнорируют ваш внешний css-файл. Добавьте правила прямо в html, как при обычной вёрстке писем.
Также шрифты нужно перенести на протокол HTTPS, добавить корректный SSL-сертификат и убедиться, что на сервере настроены корректные cross-origin-заголовки.

Два разных селектора, к которым применяется одно правило. Альтернативная запись:

:indeterminate { background: limegreen; }

:indeterminate + span { background: limegreen; }

Ссылку браузер может закешировать, base64 будет гоняться по сети каждый раз. Я ответил на ваш вопрос?

Нужно.

Это реально?

На стороне сервера - нет.

Или надо искать другой выход?

Просто нужно скрывать эту ссылку средствами CSS и медиавыражений (гуглите прямо по этим ключевым словам).

Если вы следуете методологии REST, то у вас post_id не в $data, а прямо в URL.
И тогда метод контроллера будет выглядеть примерно так:

public function save(Post $post, Request $request) {
  $fields = $request->only(['field', 'other_field']);
  $post->comments()->save($fields);
}

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

Первый способ - процедурный. Связь между сущностями описана в "магическом" поле в каком-то массиве. Он имеет право на существование в каких-то технических консольных скриптах, например (и то не всегда).
Второй - объектно-ориентированный и легче читается. Этот код очень хорошо коррелирует с методологией REST, когда мы оперируем сущностями, а не массивами и абстрактными объектами.

Пока такое невозможно, но в четвёртой версии спецификации появится:

li:has(~ .hover:hover) {
  color: red;
}

Вот такие.

Проблема в этом правиле:

* {
  overflow-x: hidden;
}

Вообще, это очень плохая практика - сбрасывать таким образом какие-то правила. Это явный признак того, что человек не понимает, что происходит у него в CSS и борется сам с собой при помощи костылей. Учитесь, экспериментируйте, разбирайтесь почему работает так, а не иначе. На костылях и Тостере далеко не уехать.

У стилей внутри медиазапросов нет какого-то волшебного приоритета над прочими, к ним применимы те же самые правила. Конкретно в данном случае - применяется последнее объявленное правило среди максимально специфичных. Селектор section ... .application input гораздо более специфичный, чем просто .application input, поэтому правила перекрываются.

Вот простой пример: https://codepen.io/alexey-m-ukolov/pen/EbeZvY?edit...

P.S.

Не работают медиа запросы

Медиа-запросы работают, проблема в другом.

браузер жалуется

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

выше (не в медиа даже) указаны другие свойства

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

Надо. Это не вмешательство в контент — это часть контента и к адаптивности не имеет никакого отношения.
Хотя, если вы таким образом костыли в вёрстку ставите, то не надо.

Никак, на prompt нельзя навесить никакие слушатели событий. Реализуйте своё модальное окно на html и делайте с ним что хотите.