Rustam Bainazarov

Что первое, что второе, по описанию, требуют WebGL. Второй вариант проще и легче в плане кода будет: статичная сфера с текстурой + текст, который описывает движение по её орбите.

Можно на CSS сделать достаточно убогую бесконечную прокрутку карты, но она не будет учитывать геометрию шара.

Типа так:


UPDATE. Увидел такой баг в Android Chrome в результате совместной работы border-radius и overflow:

Нашел решение хаком. Нужно добавить следующее к такому блоку:

-webkit-mask-image: url(data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAEAAAABCAIAAACQd1PeAAAAGXRFWHRTb2Z0d2FyZQBBZG9iZSBJbWFnZVJlYWR5ccllPAAAAA5JREFUeNpiYGBgAAgwAAAEAAGbA+oJAAAAAElFTkSuQmCC); /* this fixes the overflow:hidden in Chrome/Opera */

Это исправило проблему, обновил песочницу.

Если вы о линиях, то я для одного ответа тут уже делал :))


Можно, конечно, просто картинкой на задний фон поставить эти круги.

А ежели вы о вёрстке всего блока — то это уже задание, а не вопрос.

Я сделал на flex, потому такая штука будет работать и в IE11. Хотя проще сделать с помощью grid. А вообще, такое можно сделать хоть на float (но не надо).



Можете их даже компоновать иначе, ничего не развалится:

На второй странице отсутствует мета-тег адаптивности:

<meta name="viewport" content="width=device-width, initial-scale=1">

Retina-макетов не бывает. Retina — не более чем маркетинговое название экранов с высоким разрешением (300+ px на дюйм). Retina могут быть только ресурсы, например, картинки, которые будут иметь в несколько раз большее, чем целевой макет, разрешение, чтобы попасть в пиксельную сетку реального разрешения.

Вы же верстает не под размеры экрана в физических px, а под viewport с его «виртуальными» px, которые получаются из:
[физическое разрешение] : [степень масштабирования]

Чем выше разрешение при равных размерах экрана — тем всё мельче, если масштаб 1:1. Поэтому принято увеличивать масштаб, иначе всё мелкое-мелкое. Таким образом достигается высокая чёткость + адекватные размеры элементов на экране (эффект retina).


Так, старый iPhone 6 и iPhone XS имеют одинаковый размер viewport (375px), но реальное разрешение различается очень сильно: 750px против 1125px. Достигается это с помощью масштаба: x2 у iPhone 6 и x3 у iPhone XS.

Макет должен быть 1:1 к целевому размеру viewport, а не к физическому разрешению экрана. Потому что после всех манипуляций с масштабированием у нас остаётся четкое значение размера viewport, именно на него и надо ориентироваться.

Наличие или отсутствие retina в этом деле вам совершенно не важно, ибо вы верстает под чёткие размеры viewport, которые могут быть одинаковыми на устройствах с совершенно разными физическими разрешениями: например, ширину viewport 375px (как у iPhone XS) можно достичь на древнем VGA-экране, сжав в нём окно браузера до этих 375px.


Если у вас в макете текст имеет 15px, то и делайте его 15px. Надеюсь, кстати, что макет вам делал не совсем отбитый дизайнер, который не забыл поставить px вместо pt в макете для текстов. Иначе — либо подгонять на глаз, либо пытаться конвертировать их в px, исходя из выбранном плотности печати в настройках документа макета. Ибо pt — это относительная единица для печати, в web её нет.

Есть дизайнеры-уникумы, которые делают макеты в два раза больше необходимых размеров, типа, блин, retina x2. А если у меня retina x3 — что мне тогда делать? Или же делают макеты вообще неведомых размеров. Да и в Photoshop'e web-макеты в 2019-м году уже делать не надо, конечно.

В CSS и HTML есть методы детекции наличия масштаба, чтобы грузить нужный ресурс в зависимости от его степени.
UPDATE. С макетом полный порядок, тут уже дело в навыках верстки.

@media (-webkit-min-device-pixel-ratio: 2), (min-resolution: 192dpi) {
  
  /* Тут ваш код для чистой retina, начинающейся от минимального размера viewport в два раза меньше физического или, если нет поддержки первого свойства, от от разрешения в 192DPI */
  
}

Вот пример, где работает cover везде и безо всяких проблем. Проверяется это тем, что там две картинки на фон, первая с надписью X1 (обычная), вторая — с надписью X2 (retina). Везде background-size: cover. И всё работает:



На обычном экране грузит X1:



На экране, который проходит проверку retina — X2



Android Chrome тоже всё понимает и, если экран высокого разрешения, использует retina-вариант (X2):

Вам поможет только хак с отступами. Так делаю не только я.

Добавляем к контейнеру, у которого применен overflow: hidden, следующие стили:

padding-bottom: 1000px; // делаем отступ внутренний
margin-bottom: -1000px; // вычитаем отступ внешний, что нивелировать

В вашем случае, вроде, нет проблем, если только на CSS делать безо всякий динамики (но лучше на JS, читайте об этом под спойлером):




У хака есть одна проблема (решаемая): если есть элементы, типа кнопок-стрелок, на абсолютном позиционировании внутри сдвигаемого блока с oveflow: hidden, то эти элементы будут скакать, ибо вы реальные размеры блока увеличили с помощью padding-bottom. Решается это просто калькуляцией половины вычитаемого отступа и половины размера элемента.

И ещё в принципе можно упросить, но не нужно.

input {
   line-height: 1;
}

Когда вы применили :hover к нужному элементу, это не значит, что именно у него будут показаны стили дочерних элементов. На примере div:hover a — после выбора состояния :hover для родителя нужно выбрать именно a, потому что стили применяются именно к нему, несмотря на то, что они идут от :hover родителя (что, чёрт, логично).

Потому что с чистыми inline-элементами (:before и :after являются оными изначально) не работает свойство transform. Поменяйте, к примеру, на inline-block, как я в примере, и все будет работать:

Можно даже без классов модификаторов, тупо на nth-child:


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

Если есть контент, который должен «плавать» внутри непосредственного родительского блока без сложной логики этого действия, то можно использовать position: sticky;. Но он поддерживается не всеми браузерами.

Для условной автоматизации этого дела есть хороший плагин https://dollarshaveclub.github.io/stickybits — там, где нет sticky, он сделает с помощью fixed и наоборот.

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

P. S. Но без JS не обойтись вовсе, если нужно добавить логику по типу «если плавающий элемент доходит до какого-то элемента внутри общего родительского блока, то сделать то-то, то-то».

Data-атрибуты -- тоже CSS-селекторы.

height: 100% у детей будет работать, если задать родительскому элементу четкое (эксплицитное) значение высоты.

min-height таким свойством не является. Оно не чёткое. Поэтому height: 100% работает внутри такого контейнера как height: auto.

Как один из вариантов,:
https://codepen.io/anon/pen/YgqEoJ

Таким методом удобно задавать соотношение сторон, кстати.

Вот это в head:

<meta name="format-detection" content="telephone=no">

Вообще, этих мета-тегов больше:

<meta name="format-detection" content="telephone=no">
<meta name="format-detection" content="date=no">
<meta name="format-detection" content="address=no">
<meta name="format-detection" content="email=no">

Информация:
https://stackoverflow.com/questions/28027330/html-...

Flex (для лучшей и более простой поддержки браузеров) + box-shadow (чтобы не увеличивать габариты блоков; можно заменить на псевдоэлемент):

https://codepen.io/xgad/pen/3dca3c1c396966acc4f8db...

https://codepen.io/sergiopedercini/pen/jmKdbj

https://codepen.io/saadeghi/pen/IBhfJ