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

Система координат отсчитывается от левой верхней точки вьюпорта. Отсюда растут все подобные особенности.

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

В комбинации с JS может что-то такое набедокурить.

Если тебе не нужно менять содержимое прилипшего блока, а только делать ему перерасчет, то почему ты не воспользовался обычным position:sticky;?

У тебя отступ у параграфа margin:auto, т.е. не фиксированный, а позиция заголовка имеет жесткую фиксацию от правого края 25px, при разных разрешениях отступ у параграфа разный, следовательно при несовпадении разница видна невооруженным глазом.

Я рекомендую и параграфу и заголовку в данном конкретном примере выдать фиксированные отступы:

p {
  ...
  /* width: 90%; */
  margin-right: 25px;
  margin-left: 25px;
  ...
}

И да, убрать у абзаца размер процентный. Это блочный элемент по умолчанию и он заполнит все вширь.

1. Чтобы иметь возможность ловить события именно объектов, а не квадрата картинки, используй SVG.
2. Тень рисовать можно ее же средствами.
3. Используй svg-спрайты, это позволит снизить фактор жопоболи при перестройке.
4. В чем сложность использовать медиазапросы при постройке я, если честно не понял, располагаешь элементы (острова) один под одним (тупо дивы), а на десктопе позиционируешь абсолютно. Главное не накосячить с z-index-ом.

Я не тебе ли недавно это расписывал? *подозрительно смотрит*

Выноси по логике:
→relative
→→overflow
→→absolute

Краткий экскурс — типографике в вебе = боль. Наслаждайся. Ничего общего с полиграфией, хотя хотелось бы.

Теперь по сути:
1. Править руками частные случаи. Тут возможностей просто море, от line-height:1 (норм) до абсолютного позиционирования (плохо).
2. Постоянно и везде, поэтому стоит понимать анатомию шрифтов, чтобы знать, как с ними работать. Ну и да, никакой Zeplin тебе эту магию не выдаст, так как это программа, которая просто транспонирует свойства редактора (читай все абсолютно спозиционировано) в типа CSS.
3. Да, главное не прострелить себе ногу при этом. Т.е. скорее всего не стоит к такому прибегать.
4. Заказчику важно сделать деньги на том проекте, что ты реализуешь.
5. Да есть, типа Baseliner-а, или всякие плагины для накладывания полупрозрачной пикчи поверх верстки, но вообще это все от лукавого.

Кроме тебя порядок в логике формирования структуры HTML и классов никто не наведет.

Делай это сам, либо пиши ИИ, которая сделает это за тебя.

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

Чтобы обойти это ограничение используй кастомный скролл. Если речь именно о том, чтобы показать элементы, которые «торчат».

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

Если же вопрос был о том, как не довести до такого → не использовать фиксированные размеры, там, где контент превышает размер родителя, не указывать overflow: hidden\auto\scroll.

SVG по своей сути и названию масштабируемая графика. При интеграции ее в тело документа ты указываешь ей фактические размеры (хотя бы для одного из брекпойнта). Если же интегрируешь с помощью object, то max-width:100%, таким образом SVG будет всегда вписана в область, которая ей отведена.

Следовательно, в конечном счете размер вектора зависит от родителя (если ты не накосячил, конечно).

Исходя из этого ты можешь абсолютно позиционировать родителя SVG таким образом, чтобы он занимал столько места от секции, сколько есть в макете. При этом, врядли тебе будет доступен z-index:-1, тогда тебе необходимо будет задать родителю SVG (или ей самой, если ты без родителя обошелся) z-index:0, а форме свойства position:relative;z-index:1;, чтобы она [форма] могла «лечь» поверх пикчи.

Фоном делать не рекомендую, так как в случае с SVG ты потеряешь возможность точно управлять ей.

А начать постигать дзен SVG можно отсюда.

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

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

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

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

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

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

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

Это жесть, конечно.
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. И в зависимости от сетки тебе скорее всего потребуется знания медиазапросов.

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

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

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

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

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

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

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

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

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