7) Всегда имеет смысл. Изображения стоит подгружать по требованию. Слушать событие скрол и перед тем как изображение появится во viewport только тогда стоит подгружать это изображение. Это так же относится и к фоновым изображениям.
Если мобильного трафика много, то как можно меньше js
Давай начнем сначала.
Нам нужен код который будет валидировать все формы.
Запуск первой валидации и live - режима будет запускаться после первого события submit. Это важно. Так как пользователь только начал заполнять форму, ввел 1 символ и у него уже подсветились все поля и появилось куча ошибок.
Пользователь нажал на кнопку submit, запустилась валидация всей формы и добавились обработчики событий для каждого поля.
У обчного input необходимо слушать 2 события input - для обычного ввода с клавиатуры и change - для автокомплита.
После срабатывания одного из этих событий необходимо запустить функцию валидации (validate). Проверять стоит только то поле на котором сработало событие. Функция validate должно вызывать другие функции предикаты которые должны проверять на пустоту (isEmpty) и минимальную длину (isTooShort) и эти функции должны получать на вход значение и правило (например минимальная длина) и возвращать true/false. Также имеет значение порядок вызовов этих функций, сначала необходимо вызвать isEmpty и если вернулось true (не прошло проверку) значит нет необходимости вызывать isTooShort.
После того как было определено валидно поле или нет (конъюнкция всех результатов проверки), то вызываем в функции validate функцию отвечающую за показ ошибок toggleError и передаем в нее имя поля и статус валидации (true/false). Если в toggleError передали true значит поле валидно и необходимо скрыть ошибку, если false - то необходимо показать ошибку. Тут нам понадобится внешняя переменная errors которая будет содержать ссылки на html элементы ошибок полей. Если передали false, то нам необходимо проверить был ли ранее создан html элемент ошибки или нет. Object.prototype.hasOwnProperty(errors, name), если возвращается true (т.е. ошибка была ранее создана), то просто показываем эту ошибку (лучше через добавление CSS классов, так как позволит в будущем при необходимости анимировать появление). Если вернулось false (ошибки еще не было) то необходимо создать html элемент ошибки и вставить на страницу. Постоянно удалять и добавлять html элементы это плохо, лучше показывать или скрывать их.
Осталась задача менять состояние (disabled) кнопки submit. Для этого должна быть отдельная функция. Подумай как ее реализовать.
Потому что в checkFieldsEmpty идет перебор полей и достаточно чтобы последнее поле было не пустым чтобы у submit удалился атрибут disabled. Нужно проверять чтобы все поля были не пустыми. Есть несколько вариантов, самый простой в данном случае это при нахождении первого пустого поля добавлять submit атрибут disabled и выходить из цикла (break). И еще функция называется checkFieldsEmpty, а в ней помимо проверки на пустоту проверяется еще минимальная длина и выводятся сообщения об ошибке. По хорошему нужно все вынести в отдельные функции. И запускать валидацию не всех полей при событии input, а только на том input где сработало событие. Также событие input не везде сработает при autcomplete, необходимо использовать также событие change.
Если поставить правильный класс то под одним ипнутом будет отображаться только одна ошибка. И если мы пришли к тому что всегда будет отображаться только одна ошибка, то лучше не удалять/добавлять DOM элементы, а хранить ссылку на эти элементы (ошибки) и менять текст и скрывать/показывать их.
Сам сталкивался с подобным.
Моя теория в том что хром не правильно округляется дробные css пиксели. Этот фантомный 1px возникает не всегда, а только на определенных разрешениях, либо четных, либо нечетных, в зависимости от ширины изображения. Данный баг ловил не только с svg, но и с обычными растровыми изображениями и просто абсолютно спозиционированными блоками. Решаю костылем в виде сдвига на 1px - 2px в нужную сторону.
Но хотелось бы нормального решения.
Код который экспортируется из Тильды не редактируемый. Стили и скрипты минифицированные. HTML код страшный. Смысла в этом экспорте нет вообще. Хотя возможно за полгода что-то поменялось.
parentNode не очень хороший вариант. Так как проверяет только родителя, а не всех предков. Если в вашей кнопке будет большая вложенность то это не сработает.
Например:
Заказать звонок
Клик сработает на i, потом ищется его родитель, это div, у которого нет нужного класса.
Дмитрий, я бы и рад, но не всегда это статика. Иногда требуется подмена контента в зависимости от utm меток. И киллер фича WP для меня это GUI кастомных полей в виде плагина ACF