Арсений Матыцин

1. Дебаггер браузера наше все. Если у тебя ломается верстка при его использовании → ты напортачил, переделывай.
2. Как верно подметили, яблоко это та еще жопоболь, притом iPhone-ы имеют более менее адекватную сборку Webkit-а, в отличие от iOS-овского. Но если с мобилкой вполне может хватить автопрефиксора за глаза и за уши, то для тестирования iOS тебе поможет виртуальная машина. Ставь Hackintosh и не отсвечивай.
2.1. Проблема браузера на iOS также в том, что ты не знаешь, какой именно вьюпорт будет у открывшегося браузера, поэтому классические медиазапросы идут лесом и мы возвращаемся к пункту 1 с добавлением того, что стоит отслеживать, что происходит в межбрейкпонтном состоянии.

И всякие сервисы есть, которые позволяют это автоматизировать. Лично я никогда не пользовал, ибо зачем.
И, опять же не пробовал, но поговаривают можно собрать свой нулевой Webkit браузер, который будет близок к тому, что происходит на iOS.

По правде говоря твой пример не заработал вообще. Тем не менее рекомендую почитать про всплытие и перехват событий.

0. сonteiner → container.
1. Да, container просто находится в той же плоскости, что и твоя БЭМ-логика. Так же может стать примесью.
2. Бред, все, что от тебя требуется — сделать достаточно гибкую верстку.
3. Адаптивная верстка это в том числе смесь резиновой и фиксированной верстки, при этом не рекомендую отступы формировать на процентах просто так, ты скорее всего прострелишь себе ногу пару раз.
4. Блок услуг = аккордеон (это жаргонный термин), команда — скорее всего усложненная карусель. Без JS можно, но в долгосрочной перспективе это два пробитых колена.

Менторство это штука шаткая, лично я делаю бесплатно это тут и по настроению в моем уютном чатике ойтишнигов.

ЗЫ: твоя логика верстки в header-е приведет к тому, что тебе придется переверстать в будущем. Не стоит смешивать heroscreen с шапкой. Только в том случае, если она железно не плавающая и вообще привязана только к этому блоку с видео (из области лендингов и фантастики).

body.no-scroll {
overflow: hidden;
}

<a href="[оригинальное изображение]" target="_blank"><img src="[миниатюра]"></a>

1. Стоит начать с прослушивания прокрутки
2. Затем вычислять совпадает ли прокрутка с координатами секции.
3. При совпадении любым удобным способом получать индекс соответствующего элемента в твоей навигации (можно раздать через data-атрибуты, или просто ловить текущий индекс [поплохеет при разной вложенности]). И задавать ему класс (для подсветки).

Сама навигация должна быть размещена посредством position:fixed.

1. Рекомендую смотреть на даты публикаций.
2. Кеширование статических ресурсов (в том числе изображений) может осуществляться посредством задачи им времени кеширования в конфиге htaccess (Apache сервер), либо в конфиге Nginx.
3. Кеширование ответа результата работы бэкенда (читай данные из базы) это другой вид кеширования, который не скачивается пользователю в устройство, а просто снимает нагрузку с оперативной памяти, вычислительных мощностей сервера. Этот вид полностью зависит от используемого движка.

Итого, в первую очередь тебе стоит разобраться с кешированием статики, тут уж зависит от того, кто у тебя и как ее отдает. Сейчас почти везде стоит как апач, так и nginx. И часто статика разведена на nginx.

А потом присмотреться к движку. Скорее всего под джумлу есть модуль, или, может из коробки умеет, но тут точно не скажу, так как считаю ее давно умершей.

Это жесть, конечно.
1. У тебя там не svg в коде, а читай iframe, только в лице object.
2. Анимацию оформи прямо в теле своего документа, так ты сможешь ее отладить, в том числе задать реальные размеры, соответствующие области, куда ты ее вписываешь.

ЗЫ: открой сайт в с планшета\режиме эмулятора.

1. У изображения есть физический размер. Любая манипуляция по «впихиваю» его в размер больше или меньше отразится на прорисовке. Плюс огромный фактор играет ретинизация. Если ты работаешь с растровой картинкой 50 на 50 и запихиваешь его в размер 50 на 50 и смотришь на это с экрана повышенной плотности, жди сюрпризов. Тем не менее все это лучше, чем попытка растянуть пикчу, там вообще все плохо.
2. У тебя в верстке куча иконок, а не пикч, используй SVG, это формату по барабану (почти), в какой размер ты его вписываешь, главное в параметрах не обкекаться.

Моя любимая тема:
https://habr.com/ru/company/pt/blog/337450/
Достаточно почитать, чтобы оценить мою боль.

Тем не менее Ankhena права, компенсируй отступами. Можешь даже сделать умный вид и рассчитать отступ на базе метрик шрифта.

Насколько я помню, в contact-form не используется из коробки таблица. Тем не менее если речь о таблица, то твои чекбоксы должны быть обернуты в свои label-ы, а сама ячейка должна обладать свойствами vertical-align: middle.

Но это:
1. Неудобно в управлении;
2. Геморройно в реализации.

Тебе скорее всего потребуются flex-box-ы вместо конструкции ячейки таблицы, чтобы чекбоксы были адекватно выровнены относительно друг-друга с возможностью переноса на следующие строки, если не буду влезать.

А так как ты сам выбираешь, как именно вставлять чебоксы в верстку, то это не составит особого труда, главное иметь знания в css\html.

Оффтопом к вопросу, но по дизайн-решению: По идее у тебя должны быть не чекбоксы, а radiobutton, ведь выбрать можно что-то одно. Край → select, а лучше использовать другой подход к интерфейсу, основанный по механике на radiobutton-ах, но визуализированый понятнее.

без знания html и css?

Без знания никак, потому что:
1. Инлайновые элементы умеют так делать «из коробки».
2. Но чаще используется flexbox\grid\блочная конструкция на float-ах (порядок востребованности от большего к меньшему)
3. И в зависимости от сетки тебе скорее всего потребуется знания медиазапросов.

https://learn.javascript.ru/settimeout-setinterval

Помимо цикличности их можно записывать в переменную и очищать.

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

Другой подход через object-fit, но там сразу смотри в поддержку браузерами.

Или через background-size:contain;, но чем дальше, тем хуже относительно первого корректного метода.

1. Никак, это SVG, а не HTML.
2. Собирать все в один defs и переиспользовать, если есть такая возможность, но тогда просто будет чуть меньше ID's.

Спрайты реализуются вот так. Плюс минус, можно не использовать symbol-ы, или даже defs, а просто вызывать по id.

Можно, но не рекомендую ради кроссбраузерности, вызывать из внешнего файла, стоит встраивать в документ это добро для управляемости.

Еще больше структурированной информации ты найдешь тут.

1. https://jsfiddle.net/za72f19s/
2. Либо ты можешь задать обертке .floating-block высоту 0px, убедиться, что нет overflow:hidden;, а дочернему указать его высоту, к примеру (не обязательно, но я не уверен).
3. Использовать вычисляемое расстояние от правого\левого края (да, я понял, что ты пытаешься сделать → чтобы плавающий блок был в рамках контентной сетки).

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

PS: float-ы → прошлый век, сейчас используют для этого флексы и есть ради чего.

Первое, что следует взять во внимание, navbar яндекс это просто условно готовая база, которая подойдет для большинства решений, но в момент, когда ты упираешься в дизайн, то он [navbar] работать перестает. К слову, в последней версии вроде прямо готовый модуль убрали и заменили на компоновку.

Дальше, принять тот факт, что тебе придется описывать шапку на 90% самому.

Структурно же у тебя все вписывается в сетку и логику:
container-fluid
→container (верхняя часть шапки)
→container + отрицательный margin или transform для желтой навигации и к ней тебе с наибольшей вероятностью удобно будет использовать flex + justfy-content: space-between.

А про адаптивность говорить нельзя пока у тебя не руках нет макета для мобилок. Но как результат тебе все равно придется описывать самостоятельно, чтобы вписаться в дизайн. Либо по макету, либо брать на себя ответственность за мобильное решение.

PS: в идеале решение должно быть mobile-first (так проще).