Единицы измерения viewport в CSS. Все 24 комбинации.

Раньше в CSS было всего четыре единицы измерения, которые вам нужно было знать, и они могли охватить практически все мыслимые варианты использования. Однако со временем и изменением технологий этих четырех единиц уже не хватало для обработки всех вариантов использования. Из-за этого CSS добавил еще 20 единиц измерения области просмотра. Это много, но они разбиты на шесть основных с тремя уникальными модификаторами, что дает нам в общей сложности 24 комбинации.

Оригинальные четыре единицы измерения

Основными единицами CSS являются vw, vh, vmin и vmax. Скорее всего, вы использовали или видели их раньше, поэтому рассмотрим их кратко.

vw

vw расшифровывается как Viewport Width и представляет собой процент от ширины окна просмотра. Число, помещенное перед vw, представляет собой процент от ширины области просмотра, которой будет эта длина. Например, если вы написали 10vw, то это будет представлять 10% от ширины вашего окна просмотра. Окно просмотра (viewport) — это по сути размер вашего экрана, поэтому, если бы вы были на большом рабочем столе шириной 1920 пикселей, 10vw означало бы 192 пикселя. Если бы вы вместо этого использовали мобильный телефон шириной 300 пикселей, то 10vw был бы только 30 пикселей.

vh

vh расшифровывается как Viewport Height. Он точно такой же, как vw но для высоты, а не ширины. Эти две единицы можно использовать в комбинации, чтобы легко заставить элемент заполнять весь размер экрана.

.full-screen {
  width: 100vw;
  height: 100vh;
}

vmin и vmax

vmin и vmax представляют собой максимальное и минимальное измерение области просмотра. Например, если вы работаете на телефоне шириной 300 пикселей и высотой 800 пикселей, vmin будет представлять ширину области просмотра, а vmax — высоту устройства. Эти единицы действительно полезны, если вам нужно определить размер элемента на основе наименьшего/наибольшего размера экрана. Например, следующий CSS создаст квадрат, который будет максимально большим, не переполняясь ни в каком направлении, поскольку он никогда не будет больше 100% от наименьшего размера экрана.

.no-overflow {
  width: 100vmin;
  height: 100vmin;
}

Две новых единицы

CSS пытается отойти от строгой модели верха/низа, слева/справа, высоты/ширины к более динамичной модели начала/конца, блочной/инлайн модели. Основная причина этого изменения заключается в том, чтобы упростить внедрение различных направлений написания в коде. Если все ваше приложение переключается с горизонтального направления письма на вертикальное, идея верха/низа или ширины/высоты не обязательно означает одно и то же, поскольку, если вы хотите добавить отступы выше и ниже текста, это будет представлено как отступы слева и справа в вертикальной системе, а не заполнение сверху и снизу. Вот почему CSS добавил модули просмотра vi и vb.

vi

vi расшифровывается как Viewport Inline и представляет собой встроенное (инлайн) направление вашего документа. В горизонтальном направлении это соответствует ширине окна просмотра, а в вертикальном направлении это соответствует высоте окна просмотра. Самый простой способ запомнить направление встроенного текста — помнить, что это то же направление, в котором движется ваш текст. Еще один способ запомнить это: если у вас есть два встроенных элемента (например, два span) рядом друг с другом, направление, в котором они складываются, является вашим встроенным направлением.

.horizontal {
  writing-mode: horizontal-tb;
  width: 10vi; /* То же, что и 10vw */
}

.vertical {
  writing-mode: vertical-lr;
  height: 10vi; /* То же, что и 10vh */
}

vb

vb расшифровывается как Viewport Block и представляет собой направление блока вашего документа. Это противоположно vi, поэтому в горизонтальном направлении это будет соответствовать высоте окна просмотра, а в вертикальном документе это будет представлять ширину вашего окна просмотра. Если вы изо всех сил пытаетесь запомнить эту единицу, просто помните, что направление блока всегда будет направлением, в котором блочные элементы (например, два div) будут складываться друг на друга.

.horizontal {
  writing-mode: horizontal-tb;
  width: 10vb; /* То же, что и 10vh */
}

.vertical {
  writing-mode: vertical-lr;
  height: 10vb; /* То же, что и 10vw */
}

Модификаторы единиц измерения вьюпорта

До сих пор мы рассмотрели шесть основных типов модулей области просмотра, но есть три различных модификатора, которые вы можете добавить к единицам, чтобы они вели себя по-разному, когда ваше окно просмотра может изменять размеры. Например, когда вы просматриваете веб-страницы на мобильном телефоне, вы можете заметить, что адресная строка исчезает при прокрутке вниз. Когда это происходит, ваше окно просмотра технически меняет размер, так как теперь строка URL-адреса больше не занимает часть вашего окна просмотра. Текущие блоки CSS не имеют возможности справиться с этим изменением размера области просмотра, поэтому были добавлены эти модификаторы. Этими модификаторами являются s, l и d. Для того, чтобы использовать модификатор, вам просто нужно разместить модификатор после номера и перед единицей измерения, например 10svw. Это дает нам 4 комбинации для каждого из 6 модулей области просмотра. vw, svw, lvw и dvw. До сих пор все, что мы рассмотрели в этой статье, не использовало модификатор. Если вы не используете модификатор на устройстве, например 10vw или 10vh, браузер автоматически по умолчанию использует один из 3 модификаторов в зависимости от реализации браузера.

Модификатор s

Модификатор s расшифровывается как Small и представляет собой минимально возможное окно просмотра. В нашем примере с мобильным телефоном это будет размер окна просмотра при отображении строки URL. Если вы установите для элемента значение 100svh он будет занимать 100% высоты экрана в зависимости от размера экрана при отображении строки URL. Неважно, видна ли строка URL-адреса или нет, размер этого устройства всегда будет основываться на том, каким будет окно просмотра, если будет отображаться строка URL-адреса.

Модификатор l

Модификатор l расшифровывается как Large и представляет собой максимально возможное окно просмотра. Это в значительной степени противоположно модификатору s. В нашем примере с мобильным телефоном это будет размер окна просмотра, когда строка URL-адреса НЕ отображается. Если вы установите для элемента значение 100lvh, он будет занимать 100% высоты экрана в зависимости от размера экрана, когда строка URL-адреса НЕ отображается. Неважно, видна ли строка URL-адреса или нет, это устройство всегда будет основывать свой размер на том, каким будет окно просмотра, если строка URL-адреса НЕ отображается. Это означает, что если вы установите элемент на 100lvh, а строка URL-адреса показывается, то технически он будет больше, чем экран.

Модификатор d

Модификатор d расшифровывается как Dynamic и представляет текущий размер области просмотра. Это похоже на комбинацию модификаторов s и l. В нашем примере с мобильным телефоном это всегда будет размер текущего окна просмотра, независимо от того, отображается ли строка URL-адреса или нет. Если наша строка URL-адреса отображается, то модификатор d имеет тот же размер, что и модификатор s, а если строка URL-адреса НЕ отображается, модификатор d имеет тот же размер, что и модификатор l. Во время перехода между отображаемой и скрытой строкой URL-адреса это устройство будет динамически увеличиваться в размерах, поэтому оно всегда будет заполнять все доступное пространство. Это здорово, если вам нужно гарантировать, что размер элемента всегда зависит от области просмотра, но может быть обременительным, поскольку это вызовет много перерисовок, поскольку размер постоянно меняется.

Поддержка браузеров

С каждой интересной функцией CSS вы всегда должны учитывать поддержку браузера, и, к сожалению, поддержка браузера для этих новых модулей просмотра не очень хороша. В настоящее время эти новые единицы поддерживают >85% и на самом деле поддерживаются только в Safari и Firefox. Причина такого отсутствия поддержки заключается в том, что это предложение все еще находится на стадии рабочего проекта, что означает, что оно находится на очень ранней стадии своего жизненного цикла и довольно далеко от того, чтобы быть официальным CSS.

Итоги

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

Это серия статей о функциональном программировании:

1. Парадигмы программирования
2. Композиция
3. Функторы
4. Каррирование (рассматривается в этой статье)
5. Чистые функции
6. Функции первого класса

Что такое каррирование?

Каррированная функция — это функция, которая продолжает возвращать функции до тех пор, пока не будут отправлены все ее параметры.

Как работает каррирование?

Предположим, есть функция сложения add.

const add = (a, b) => a + b

Простейшая реализация каррирования — заставить функцию возвращать функцию и т. д.

const add = (a) => (b) => a + b

Эту функцию можно использовать так.

const addOne = add(1) // addOne = (b) => 1 + b

Представим, что у нас есть функция curry, которая принимает функцию и каррирует ее.

const add = curry((a, b) => a + b)

Как мы видим, curry — это функция, которая использует другую функцию для ленивой обработки параметров. Итак, теперь мы можем вызвать ее следующим образом.

const addOne = add(1) // addOne = (b) => 1 + b

Итак, сначала мы создали addOne, передав 1 в качестве первого параметра (a) каррированной функции добавления. Что привело к другой функции, которая ожидает остальные параметры, где логика добавления не будет выполняться, пока не будут предоставлены все параметры.

addOne(2) // 3

Теперь, передавая 2 (как b) в addOne выполняет логику 1 + 2.

Пояснение к функции curry

Функция curry принимает функцию и делает ее параметры ленивыми, другими словами, вы предоставляете эти параметры по мере необходимости. Так же, как addOne. Вы по-прежнему можете вызывать каррированную версию функции добавления следующим образом.

const three = add(1, 2)

Таким образом, он либо принимает аргументы по частям, либо все аргументы сразу.

Для чего нужно каррировать функции?

Каррирование делает код:

• Чище
• Уменьшает количество повторяющихся параметров и делает код более лаконичным
• Более компонуемым
• Переиспользуемым

Почему каррирование делает код лучше?

Некоторые функции принимают конфигурацию в качестве входных данных

Если у нас есть функции, которые принимают конфигурацию (начальные настройки), нам лучше их каррировать, потому что эти конфигурации, вероятно, будут повторяться снова и снова. Предположим, что у нас есть функция перевода, которая принимает локаль и текст для перевода.

const translate = (locale, text) => { /* логика перевода */ }

Использование будет выглядеть так.

translate('ru', 'Hello')
translate('ru', 'Goodbye')
translate('ru', 'How are you?')

Каждый раз, когда мы вызываем translate, мы должны указывать язык и текст. Что является избыточным для предоставления локали при каждом вызове. Но вместо этого давайте каррируем translate следующим образом.

const translate = curry(
  (locale, text) => { /* логика перевода */ }
)

const translateToRu = translate('ru')

Теперь translateToRu имеет ru в качестве locale, предоставленного каррированной функции translate, и ожидает текста. Мы можем использовать это так.

translateToRu('Hello')
translateToRu('Goodbye')
translateToRu('How are you?')

Каррирование действительно внесло улучшения, нам не нужно каждый раз указывать локаль. Вместо этого каррированная функция translateToRu содержит locale из-за каррирования. После каррирования - в этом конкретном примере код стал:

• чище
• менее многословным и менее избыточным.

Потому что мы отделили конфигурацию от фактических данных. Что очень удобно во многих случаях.

На практике

На практике у нас есть динамическая локаль (у каждого пользователя свой язык), может быть fr, en, de или что-то еще. Поэтому вместо этого лучше переименовать translateToRu в translateTo, где translateTo может быть загружен с любой локалью. Теперь у нас есть translate, который принимает locale как конфигурацию и text как данные. Благодаря тому, что translate каррирован, мы смогли отделить параметры конфигурации от данных.

Зачем отделять конфигурации от данных?

Многие компоненты и функции нуждаются в использовании некоторой функциональности (в нашем случае, translateTo), но не должны или не могут знать о части конфигурации (locale). Эти компоненты или функции имеют только часть данных (text). Таким образом, эти функции смогут использовать эту функцию без необходимости знать о части конфигурации. Таким образом, этот компонент или функция будут меньше связаны с системой, что сделает компоненты более компонуемыми и более удобными в сопровождении.

Когда применять каррирование?

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

Связь между замыканием и каррированием

Замыкание - это функция, возвращаемая «родительской» функцией и имеющая доступ к внутреннему состоянию родительской функции. Каррирование всегда приводит к замыканию. Потому что каждая функция, возвращаемая каррированной функцией, будет снабжена внутренним состоянием родителей.

Примеры каррирования

Перед тем как продолжить

Добавим некоторые утилиты, чтобы мы могли перейти к примерам. Прототип массива имеет такие утилиты, как filter, map и другие. Но они не поддерживают каррирование, потому что используют запись через точку (.). Итак, давайте конвертируем их в каррируемый формат.

const filter = (fn, list) => list.filter(fn)
const map = (fn, list) => list.map(fn)
const startsWith = (starter, s) => s.startsWith(starter)

Теперь мы можем использовать их так.

const lessThan21 = user => user.age < 21

// Вместо такого использования...
const filteredUsers = users.filter(lessThan21 )

// ...будем использовать такое
const filteredUsers = filter(lessThan21, users)

Мы исключили запись через точку и передали обработанные данные в качестве последнего параметра. Затем мы их каррируем. Функция curry будет принимать функцию и возвращать каррированную функцию.

const filter = curry((fn, list) => list.filter(fn))
const map = curry((fn, list) => list.map(fn))
const startsWith = curry((starter, s) => s.startsWith(starter))

Пример 1

Дан список чисел, нужно увеличить все числа на 1. Вход: [1, 2, 3, 4, 5] Выход: [2, 3, 4, 5, 6] Реализация:

// каррированная функция add была определена ранее
const addOne = add(1)
const incrementNumbers = map(addOne)
const incrementedNumbers = incrementNumbers(numbers)

Пример 2

Дана строка, оставить все слова, начинающиеся с буквы c. Вход: "currying javascript function” Выход: “currying” Реализация:

const startsWithC = startsWith('c')
const filterStartsWithC = filter(startsWithC)
const filteredWords = filterStartsWithC(words)

Пример 3

Дан список диапазонов и список чисел. Создайте массив функций, которые могут фильтровать числа на основе предоставленных диапазонов.

const ranges = [
  { min: 10, max: 100 }, 
  { min: 100, max: 500 }, 
  { min: 500, max: 999 }
]
const numbers = [30, 50, 110, 200, 650, 700, 1000]
// 30 и 50 в первом диапазоне
// 110 и 200 во втором диапазоне
// 650 и 700 в третьем диапазоне
// 1000 не принадлежит ни одному диапазону

Выход: массив функций. Каждая функция может принимать числа и возвращать отфильтрованные числа, которые находятся в заданном диапазоне.

const isInRange = curry(
  (range, val) => val > range.min && val < range.max
)

const filters = ranges.map((range) => filter(isInRange(range)))

В этом примере есть двойное каррирование, filter и isInRange. filters теперь представляют собой список функций, каждая из которых ожидает numbers для обработки.

Для лучшего понимания можно развернуть каррирование и вместо этого использовать обычные функции.

const isInRange = (range, val) => val > range.min && val < range.max

const filters = ranges.map(
  (range) => (numbers) => numbers.filter(
    number => isInRange(range, number)
  )
)

Итоги

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