Роман Якимчук

Не понял до конца вопроса, но есть два момента:

1. Не совмещайте top и bottom с margin (top & bottom) для абсолютных элементов, потому что это решение одной задачи разными способами, и, честно говоря, даже не знаю как себя поведет браузер

2. margin: auto берет контейнер в котором размещается элемент, и "центрует" его путем добавления margin по разные стороны элемента в равной доле, поэтому для ваших 27% margin вышел больше, чем для большей высоты самого элемента. Но опять же, странное дело, потому что для абсолюта + top & bottom он должен был по идее растянуть его во весь экран, а не делать margin.

Это мысли вслух, может быть чем-нибудь поможет.

Это изображение, его нельзя адаптировать без доп. решений, например:

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

И в целом верно сказали, надо map, или svg.

Простые правила:

• Текст должен быть обычного размера
  
• Для экономии пространства не делаем огромных отступов (если нужно)
  
• Скролл по горизонтали и вертикали
  
• Sticky-заголовки или колонки для удобства
  
• Если нужно вывести доп. данные, то можно сделать через подсказки при наведении, например
  

Задача чтобы выводились все критические данные и было удобно читать, а всё остальное через интерактив.
У нас есть таблицы с 10-20+ колонок, и тысячи строк, плюс фильтры, сортировки, но показать не могу, NDA.

Если есть время, можно прикрутить управление колонками (скрытие/отображение, изменение размера, и прочее), это значительно упростит пользование таблицей.

Но, но не всё так плохо. Когда один раз соберете проект (запуск dev-сервера, например), дальнейшая сборка проекта на каждый "чих" занимает считанные секунды, поэтому особых сложностей не доставляет.

По теме:

1:

Зависит от проекта, но в 99% случаев вебпаком собирают сложные веб-приложения, а там просто запустить файл и посмотреть результат не получится.

Поэтому если это нужно, то можно спроектировать приложение таким образом, чтобы оно работало и БЕЗ сборки. Например, чистый JS (а не TypeScript), только относительные пути, подключение через System (например), полное отсутствие транспиляторов (только чистый JS/CSS). Правда, это будет мощный выстрел в ногу проекта, и соберете другие грабли, поэтому крайне не рекомендую это делать.

2:

Можно, но зависит от задач. Сборка проекта это просто команда, грубо, `webpack` в терминале. Запустить это можно на любом ПК, и так как это команда, то её можно запустить удаленно. Системы непрерывной интеграции работают именно таким образом, и сами собирают проект, тестируют, и так далее.

Другой вопрос, что вы хотите npm от проекта, а одно без другого не живет (webpack это тоже модуль, без npm проект не собрать так как получится зависимости установить), т.е. нет, нельзя. В нормальном режиме.

На самом деле, в теории, можно попробовать и даже это обойти, но я крайне не рекомендую это делать.

Судя по всему, какой-то браузерный баг – вижу что ошибка, вероятно, происходит после вызова таймера на изменение слайда на странице, и это вызывает Paint (перерисовку) всей страницы, и в этот момент происходит мерцание (видимо, баг отрисовки в браузере).

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

Используйте CSS анимации. В анимации опишите transform (rotate).

Интересный случай, по идее всё должно работать.
Если добавить родителю (.wrapper) свойство white-space: break-spaces, то всё работает, но почему, не понятно.

В исходнике много проблем, надо перебирать все классы, опишу проблемы в одном из классов:

background: url(img/section_bg.png) no-repeat;
position: absolute;
background-size: cover;
align-items: flex-end; // Оно не будет работать, потому что родитель не флексовый
width: 100%; // Элемент 100% ширины, а родитель 73%, и уже поэтому размеры могут не совпадать и верстка поедет
height: 25%;
min-height: 374px;
margin-left: 2.6%; // Из-за этого элементы могут встать неровно
margin-top: 1200px;

Мои рекомендации:
1. Уберите абсолютное расположение
2. Уберите все ширины, боковой margin элементов, пусть они тянутся по ширине родителя
3. Установите нужный размер родителя
4. Сделайте нужную высоту нужных элементов
5. Уберите лишние свойства (вроде float: center, который просто не существует, или align-items который не будет работать без flex-контейнера)

Подарите дизайнеру сервый карандаш и попросить нарисовать цветную картину :)
Это к тому, дизайнер должен понимать принципы веб и такие вещи не придумывать, чтобы потом разработчики не страдали.

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

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

Вариант №3, опять же JavaScript, это реализация через canvas.

Вариант №4, и он самый лучший, это согласовать изменения в дизайне.

Вообще, это сложность для веб, управлять не прямоугольной графикой.

Как вариант, внутри разместить круглый синий круглый блок (border-radius 50%), который будет намного больше родительского контейнера, и будет скрыт за его границами, т.е. визуально будет видно прямоугольник. При наведении делается transform: scale, и он уменьшается до нужных размеров. Фон родительского контейнера сделать серым.

Правда, всё зависит от анимации которая вам требуется.

И, вот этот текст, чтобы под блоком был белый, а дальше черный. Попробуйте вот это: https://developer.mozilla.org/en-US/docs/Web/CSS/f...

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

В общем случае, если вы корректируете стиль в отдельном случае, это модификатор. Если у вас их будет много – это тоже нормально (с точки зрения размещения классов), но обратите внимание почему их много, это не совсем типично иметь 20-40 разных модификаторов под один блок на разных страницах.

Не совсем понял задачу, но похоже вам нужен просто `position: sticky`. В этом случае элемент будет "приклеен" к границе окна при прокрутке страницы. Положение такого элемента относительно границ окна можно регулировать, насколько я помню, через `top`, `right`, `bottom`, `left`.

https://developer.mozilla.org/en-US/docs/Web/CSS/p...
Вот здесь есть пример как оно работает

Собирайте все анимируемые элементы (если анимируете группой) в один абсолютный, и двигайте через transform: translateX(<смещение>), translateY(<смещение>), translateZ(<смещение>) вместе со свойством transition. Это все CSS3.

Как альтернативный вариант, тег , в том числе WebGL (например, инструмент https://github.com/PixelsCommander/HTML-GL)

Общее правило по оптимизации анимаций, в котором нужно двигаться — максимально уменьшите количество анимируемых элементов, их сложность (вложенность), каскадность стилей, делайте элементы абсолютно позиционированными, простыми (без прозрачности, градиентов, закруглений, и прочего), делайте самый минимум DOM модификаций, и по-возможности анимируйте при помощи CSS3 или .

Нужно чтобы браузер выполнил минимум операций при перерисовке страницы во время анимации.

Чтобы посмотреть что рисует браузер во время анимации, есть удобный инструмент.
https://developer.chrome.com/devtools/docs/renderi...

На скриншоте есть "Show paint rectangles". Включите это, увидите как браузер реально перерисовывает страницу.