Андрей Павленко

Может конкуренты решили насолить.
Читаем следующее:
https://habrahabr.ru/company/cbs/blog/314738/
https://ru.wikipedia.org/wiki/Sender_Policy_Framework
https://habrahabr.ru/post/270159/
https://yandex.ru/support/pdd/set-mail/spf.html - вот на это обратите внимание.

Гуглите SPF и изучайте редактирование DNS-записей. Вы не сможете полностью защитится от подделок, но для большинства почтовых клиентов это будет сильно ограничивать возможности подобных подделок

По сути, я видел 90-килобайтные файлы мешанины PHP, HTML, MySQL-запросов и прочего.
Писать такой код просто.
Проблемы начнутся через полгода, когда вы этот код забудете и нужно будет что-то изменить. Вам придется проверять весь код и пересматривать его, чтобы не зацепить изменением в одном месте кода другое, совсем неожиданное.
После того, как новички несколько раз сталкиваются с такой проблемой, они начинают писать код более структурировано. Один с методов - это отделить получение информации от пользователя и базы данных с помощью одного кода, отображать эту информацию конечному пользователю с помощью другого, и решать, какую информацию показать и связать два предыдущих компонента между собой - с помощью третьего набора кода.
Грубо говоря, так и получается структура MVC, в которой html и php код разделен.
Это если условно, так как сколько людей - столько и пониманий MVC.

Вы открываете файл локально, а нужно поднять веб-сервер типа Apache, и уже обращаться к нему с помощью localhost
Это самые основы основ, поэтому никто вам и не захотел тратить время на ответ.
Можете скачать https://www.apachefriends.org/ru/index.html ; погуглить "как настроить Apache под Windows", сделать, чтобы localhost указывал вам на нужную папку и уже обращаться к нужному файлу не с помощью file://, когда Chrome читает файл с диска напрямую, а через внутренний веб-сервер.

Можно, но если можете - обходитесь span, а уже на сам тэг A цепляйте display: block, особенно, если единственное предназначение DIV - это сделать ссылку блочной

На самом деле, вопрос хороший, я тоже на нем попался своего времени.
Тут есть разница между физическим количеством пикселей и тем количеством, которые считает браузер, так как если он будет передавать фактические пиксели - все сайты будут слишком мелкими.
Фактически в нем 1080 на 1920 пикселей, но Google Chrome передает в JS что в нем 360 на 640 пикселей, с которых браузер использует 360 на 559 согласно сайту myresolutionis.ru
Подробнее - гуглите Device Pixel Ratio

<?php foreach ( $tabs as $key => $tab ) : ?><li class="<?php echo $key ?>_tab">
          <a href="#tab-<?php echo $key ?>"><?php echo apply_filters( 'woocommerce_product_' . $key . '_tab_title', $tab['title'], $key ) ?></a>
        </li><?php endforeach; ?>

Костыли, но по-другому почти что никак. Можно для читаемости после <?php поставить перенос строки, если заботитесь о читаемости кода (что весьма похвально)

Раньше делали для совместимости по традиции.
Сейчас это вообще не нужно.

Да, лучше создать отдельный id или класс.
Почему?
Да потому, что потом не будет возникать вопросов: "а как этот блок позиционируется", да и проследить проще в одном файле, чем искать потом в десятках других.
Вот даже сейчас рефакторю проект, и сталкиваюсь с этой проблемой - все сделано нормально в общем файле, а некоторые свойства прописаны с помощью style. И этот код и дублируется в разных файлах, и изменяется немного, да и не всегда быстро можно найти, в котором же именно файле генерируется это свойство (особенно если это смесь html, js, php)...

Ведь гуглится на раз-два, стоило ввести, первые же два линка:
stackoverflow.com/questions/6332384/read-id3-tags-... - несколько советов
https://github.com/aadsm/JavaScript-ID3-Reader - библиотека для чтения ID3 тегов

И еще собственно для битрейта:
stackoverflow.com/questions/21634091/is-it-possibl...