ch в CSS


One more step

Please complete the security check to access

Why do I have to complete a CAPTCHA?

Completing the CAPTCHA proves you are a human and gives you temporary access to the web property.

What can I do to prevent this in the future?

If you are on a personal connection, like at home, you can run an anti-virus scan on your device to make sure it is not infected with malware.

If you are at an office or shared network, you can ask the network administrator to run a scan across the network looking for misconfigured or infected devices.

Another way to prevent getting this page in the future is to use Privacy Pass. You may need to download version 2.0 now from the Chrome Web Store.

Cloudflare Ray ID: 53404aaebc748ed1 • Your IP : • Performance & security by Cloudflare

CSS Units

CSS Units

CSS has several different units for expressing a length.

Many CSS properties take «length» values, such as width , margin , padding , font-size , etc.

Length is a number followed by a length unit, such as 10px, 2em, etc.

A whitespace cannot appear between the number and the unit. However, if the value is 0, the unit can be omitted.

For some CSS properties, negative lengths are allowed.

There are two types of length units: absolute and relative.

Absolute Lengths

The absolute length units are fixed and a length expressed in any of these will appear as exactly that size.

Absolute length units are not recommended for use on screen, because screen sizes vary so much. However, they can be used if the output medium is known, such as for print layout.

Unit Description
cm centimeters Try it
mm millimeters Try it
in inches (1in = 96px = 2.54cm) Try it
px * pixels (1px = 1/96th of 1in) Try it
pt points (1pt = 1/72 of 1in) Try it
pc picas (1pc = 12 pt) Try it

* Pixels (px) are relative to the viewing device. For low-dpi devices, 1px is one device pixel (dot) of the display. For printers and high resolution screens 1px implies multiple device pixels.

Relative Lengths

Relative length units specify a length relative to another length property. Relative length units scales better between different rendering mediums.

Unit Description
em Relative to the font-size of the element (2em means 2 times the size of the current font) Try it
ex Relative to the x-height of the current font (rarely used) Try it
ch Relative to width of the «0» (zero) Try it
rem Relative to font-size of the root element Try it
vw Relative to 1% of the width of the viewport* Try it
vh Relative to 1% of the height of the viewport* Try it
vmin Relative to 1% of viewport’s* smaller dimension Try it
vmax Relative to 1% of viewport’s* larger dimension Try it
% Relative to the parent element Try it

Tip: The em and rem units are practical in creating perfectly scalable layout!
* Viewport = the browser window size. If the viewport is 50cm w >

Browser Support

The numbers in the table specify the first browser version that fully supports the length unit.

What is the CSS ‘ch’ Unit?

I keep seeing authors and speakers refer to the ch unit as meaning “character width”. This leads to claims that you can “make your content column 60 characters wide for maximum readability” or “size images to be a certain number of characters!”

Well… yes and no. Specifically, yes if you’re using fixed-width fonts. Otherwise, mostly no.

This is because, despite what the letters ch might imply, ch units are not “character” units. They are defined as:

Equal to the used advance measure of the “0” (ZERO, U+0030) glyph found in the font used to render it. (The advance measure of a glyph is its advance width or height, whichever is in the inline axis of the element.)

So however wide the “0” character is in a given typeface, that’s the measure of one ch . In monospace (fixed-width) fonts, where all characters are the same width, 1ch equals one character. In proportional (variable-width) fonts, any given character could be wider or narrower than the “0” character.

To illustrate this, here are a few example elements which are set to be exactly 20ch wide, and also contain exactly 20 characters.




It’s probably no surprise that in Courier, all the elements are the exact same width as their text contents. In Helvetica, by contrast, this is mostly not the case except for numbers, which appear to be fixed-width. In Georgia, by contrast, none of the text contents fit the boxes, not even the numbers.

What I’ve found through random experimentation is that in proportional typefaces, 1ch is usually wider than the average character width, usually by around 20-30%. But there are at least a few typefaces where the zero symbol is skinny with respect to the other letterforms; in such a case, 1ch is narrower than the average character width. Trajan Pro is one example I found where the zero was a bit narrower than the average, but I’m sure there are others. Conversely, I’m sure there are typefaces with Big Fat Zeroes, in which case the difference between ch and the average character width could be around 50%.

So in general, if you want an 80-character column width and you’re going to use ch to size it, aim for about 60ch , unless you’re specifically working with a typeface that has a skinny zero. And if you’re working with multiple typefaces, say one for headlines and another for body copy, be careful about setting ch measures and thinking they’ll be equivalent between the two fonts. The odds are very, very high they won’t be.

It would be interesting to see the Working Group take up the idea of average character width as a unit of measure—say, 1acw or possibly just 1cw —which actually uses all the letterforms in a typeface to calculate an average value. That would get a lot closer to “make your columns 60 characters wide!” in a lot more cases than ch does now.

  • Published Thursday, June 28th, 2020
  • Categorized under CSS, Gu >
    • Thursday, June 28th, 2020 9:38pm
    • Patrick Hall wrote in to say.

Wouldn’t it be hard to define an average character width without specifying language (character frequencies vary wildly across languages, even if they have similar alphabets)? And even with a single, language it seems to me that you could have significant problems defining average in (say) a mathematical text versus a romance novel.

[…] What is the CSS ‘ch’ Unit? […]

Great information, I had no idea that measure even existed, thank you for sharing. I guess an important point to be considered is the language used in the page, particularly because of the average amount of letters per word.

Have you looked into the difference between “ch” and “ex” or “ch” and “en”?
“en” is not a css uom but in typography is defined to be half an “em”.

So what even is the point of this unit? Seems like it’s not useful in practicality.

[…] What is the CSS ‘ch’ Unit? “however wide the “0” character is in a given typeface, that’s the measure of one ch” […]

[…] What is the CSS ‘ch’ Unit? […]

Interesting idea, Eric! It got me thinking. Please bear with me.

I see two issues with using ch for column width as it stands, both of which you address implicitly:

Other than for monospace fonts, it does not correspond to the average width of the letters.
The deviation from the average width is inconsistent between fonts.

I understand that you’re looking for a unit that is better at predicting the actual letter count than ch is. Arguably, if the deviation from the average were consistent regardless of font, #1 would be less of a problem.

But how should we define average width for our purposes?

Considering the situation you describe — to make a column n characters wide — just using all the letterforms in a typeface to calculate an average value, as you proposed in your last paragraph, would probably not correspond to the actual average character width in any given column, since actual letter form distribution in ordinary text in non-uniform. It even varies by language. Granted, it would probably more often than not be closer to the actual average width than using the character “0”.

Furthermore, using all Unicode blocks covered by a particular font would skew the average even more. For example, CJK characters are in general much wider that Latin characters. Using only a subset, let’s say all four Latin blocks, would give a more practical value for Latin texts, but not for those using non-Latin scripts.

A pragmatic solution would maybe be computing the average width using the letters in a 30 word long Lorem ipsum string. That value would probably be close enough for Latin and maybe Greek and Cyrillic scripts. For other scripts, probably not, but then again, the concept of a “n characters wide column” maybe is a purely western typography thing. I don’t know.

I don’t have a good solution, I just think that this problem can’t be solved just by introducing a new unit. Maybe something that works analogously (is that a word?) to font-size-adjust , but for widths. And, preferably accommodating non-western scripts.

Until a better solution comes along, I’ll follow your advice in the second-to-last paragraph: tweaking it manually

Nevertheless, thank you for your ideas, insights and advocacy. Reading your articles is always educational.

Thanks, Eric for this wonderful deep dive of measurement nerdiness! I’ve seen this measure and wondered about how it worked–didn’t know it was based on zero character.

The characters examples with 3 different fonts looks all the same in FF mobile.

Average character width would be useful, but I can think of more cases in which a maximum character width unit would help more. 1mcw could mean the width of the widest character, such as ‘m’ or ‘w’, but not necessarily only those. Using this unit would guarantee that the text content will not exceed the boundaries.

CSS Единицы

Единицы CSS

CSS имеет несколько различных единиц для выражения длины.

Многие свойства CSS принимают значения «Length», такие как ширина, отступ, отступ, размер шрифта, ширина границы и т.д.

Длина — это число, за которым следует единица длины, например 10px, 2em и т.д.

Между номером и устройством не может быть пробела. Однако если значение равно 0, единицу можно опустить.

Для некоторых свойств CSS допускается отрицательная длина.

Существует два типа единиц длины: абсолютный и относительный.

Абсолютные длины

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

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

Единицы Описание
cm centimeters
mm millimeters
in inches (1in = 96px = 2.54cm)
px * pixels (1px = 1/96th of 1in)
pt points (1pt = 1/72 of 1in)
pc picas (1pc = 12 pt)

* Pixels (px) are relative to the viewing device. For low-dpi devices, 1px is one device pixel (dot) of the display. For printers and high resolution screens 1px implies multiple device pixels.

Relative Lengths

Relative length units specify a length relative to another length property. Relative length units scales better between different rendering mediums.

Unit Описание
em Relative to the font-size of the element (2em means 2 times the size of the current font)
ex Relative to the x-height of the current font (rarely used)
ch Relative to width of the «0» (zero)
rem Relative to font-size of the root element
vw Relative to 1% of the width of the viewport*
vh Relative to 1% of the height of the viewport*
vmin Relative to 1% of viewport’s* smaller dimension
vmax Relative to 1% of viewport’s* larger dimension
% Relative to the parent element

Совет: Модули EM и REM практичны в создании идеально масштабируемой компоновки!
* Видовой экран = размер окна браузера. Если видовой экран шириной 50 см, 1ВВ = 0.5 cm.

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

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

Length Unit
em, ex, %, px, cm, mm, in, pt, pc 1.0 3.0 1.0 1.0 3.5
ch 27.0 9.0 1.0 7.0 20.0
rem 4.0 9.0 3.6 4.1 11.6
vh, vw 20.0 9.0 19.0 6.0 20.0
vmin 20.0 9.0* 19.0 6.0 20.0
vmax 26.0 Не поддерживается 19.0 7.0 20.0

Примечание: Internet Explorer 9 поддерживает VMIN с нестандартным именем: VM.

What is difference between CSS em and ch units

What is difference between CSS em and ch units ?

I have been using ch in my stylesheet but em seems more common, I don’t understand the difference between them ?

I understand that 20ch would give enough space for 20 zeroes, I dont understand what em is, does it give enough space for 20 M’s or is it 20 x fontsize, i,e size 16 font would give 320, but 320 of what unit. I don’t get if they are almost the same or completely different

4 Answers 4

I’ve looked at all the answers and also your comments on them and I got the feeling that you want using em and ch units mainly for width or height properties.

[. ] they are not good for setting a field width then?

And from my perspective, I would not recommend that.


First of all, I’ve never worked with ch before and honestly I do not see any real use for it — maybe an input for the year, so that there is always the width for four numbers, but not more — because it never tells you exactly how wide an element will end up.

I changed my mind and now I see a good real use for ch . :)

The example of an input for the year, so that there is always the width for four numbers, will persist. But ch is also very useful for correctly defining the text width of a paragraph.

With pixel, relative or percentage values it is very difficult — especially for a responsive design — to set the perfect text width per line including spacing for a paragraph. However, this can be a liability for the user experience on the website. An abstract by Atlassian Design is a perfect match:

Set the reading environment to suit the reader. Wide lines of text are difficult to read and make it harder for people to focus. While there is no right way to measure the perfect width for text, a good goal is to aim for between 60 and 100 characters per line including spacing. Setting an optimal line length breaks up content into easily digestible blocks.

This is where ch can be used perfectly as a unit. For a better view, you can look at the examples at the end.

But now finally to the definition of ch ;)

As often been said, ch refers to the width of the 0 character to its font size.

As example: The body has a font-size: 16px and the 0 character has a width of 10px from the selected font-family, then 1ch equals 10px . And even that is still inaccurate, because e.g. italic or bold can change the width of the character.

EM- & REM-Units

As also often said, em — and to bring one more player in — also rem are relative to the font-size .

Where rem is always relative to the root element font-size , em is relative to the font-size of the own element or the last parent element (can be also the root element) with a font-size .

As em example: Only the body has a font-size: 16px; and the element got no font-size himself, then 1em equals 16px . If a parent of the element or the element himself got a font-size: 20px; , then 1em equals 20px . em units can also multiply upon themselves.

As rem example: The body has a font-size: 16px; , then 1rem equals 16px . Even if the element himself or a parent element got a font-size: 20px; , 1rem still equals to the body settings of 16px .

[. ] if ch is size of ‘0’ in font, why is not em the size of ‘M’ in font [. ]

em was originally based on the typographic measurement of the current font M character but that is already outdated. As you can see now, it always references to a «fixed start-value» and not the width of a character.

Recommended usage

As i said, from my perspective I would not recommend to use ch , em or rem for width or height properties. These units are more useful for «textual» properties.

  • All h2 should be four times as big as the text: font-size: 4rem;
  • All p should always have a margin of a half line: margin-bottom: 0.5em;
  • The line-height of elements should be 20% greater than the font-size : line-height: 1.2em;
  • A input for the year, should always have the width of four numbers: width: 4ch;
  • The text width of a p should always have a width of 80 characters per line including spacing: width: 80ch;

but pixels are not flexible when dealing with different devices

For this, as a conclusion, I would advise you to simply work with percentages width: 80%; or the viewport width and viewport height height: 100vh; width: 100vw; . Or at least always with a maximum value: width: 1000px; max-width: 100%; .

Here are a few snippets — just for the examples with width properties — for a better understanding:

em — Relative to the font size of the own element or the last parent element with a font size

Илон Маск рекомендует:  Создание сайта недвижимости (агентства недвижимости)

rem — Relative to font-size of the root element

ch — Relative to width of the «0» (zero)

7 единиц измерения CSS, о которых вы могли не знать

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

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

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

Сегодня я познакомлю вас с некоторыми CSS инструментами, о которых вы могли не слышать. Каждый из них является единицей измерения, такой как, например, пиксели или em, но о тех, что я хочу рассказать, вы могли даже и не слышать! Давайте начнем.

Начнем с чего-то, что вам может показаться отдаленно знакомым. em всегда равен font-size . Так что если вы зададите размер шрифта элементу body, значение em каждого вложенного в body элемента будет пропорционально меняться.

Вот, мы задали font-size контейнера div 1,2em . Это в 1.2 раза больше, чем любой заданный размер шрифтп, в этом случае 14px. Результат – 16.8px .

Но что случится, если вы вложите друг в друга контейнеры с размером шрифта, заданным в em? В следующем примере мы использовали тот же CSS код, что и в предыдущем. Каждый div контейнер наследует размер шрифта от своего родителя, тем самым каждый раз увеличая шрифт все сильнее и сильнее.

Когда в некоторых случаях это может быть необходимо, довольно часто хочется, чтобы значение, от которого отталкивается единица измерения, было одним. В такой ситуации подойдет rem . Буква «r» в rem означает root (корень); то есть размер шрифта задается относительно корневого элемента; в большинстве случаев это будет html элемент.

В каждом из трех вложенных элементов в прошлом примере, шрифт будет равен 16.8px .

Удобно в случае с сетками.

Rem удобно использовать не только для установки размера шрифта. Например, вы можете задать размер шрифта целой сетке используя rem , обращаясь к em в некоторых местах. Это даст вам более предсказуемое масштабирование.

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

Могу ли я это использовать?

vh и vw

Адаптивный веб-дизайн полностью полагается на процентные соотношения. Но использование процентов CSS не всегда является лучшим решением. CSS ширина всегда относительна ближайшего родительского элемента. Но что если вы хотите использовать ширину или высоту viewport вместо таковых родительского элемента? Это как раз тот случай, когда стоит использовать vh и vw .

1vh равен 1/100 высоты viewport. Например, если высота браузера 900px , 1vh будет равен 9px. Таким же образом, если ширина равна 750px , то 1vw будет равен 7.5px .

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

Представьте, что вам необходимо сделать заголовок, который займет всю ширину экрана. Чтобы сделать это, следует задать размер шрифта в vw . Этот размер будет увеличиваться вместе с размером экрана.

Могу ли я это использовать?

vmin и vmax

В то время как vh и vm всегда относятся к высоте и ширине viewport, vmin и vmax относятся к минимальной и максимальной ширине или высоте viewport, в зависимотсти от того, какая из величин больше, а какая меньше. Например, если ширина окна браузера задана в 1100px, а высота в 700px, 1vmin будет равен 7px, а 1vmax 11px. Но, если ширина будет установлена в 800px, а высота в 1080px, то vmin будет равен 8px, а vmax – 10.8px .

Итак, как можно воспользоваться этими значениями?

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

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

Совмещая эти правила можно получить очень адаптивный и зачастую необычный способ для изменения размеров вашего viewport.

Могу ли я это использовать?

ex и ch

Единицы ex и ch , по аналогии с em и rem , соотносятся с текущим шрифтом и размером шрифта. Но, в отличие от em и rem , они также соотносятся c font-family .

ch или character является продвинутой единицей измерения ширины от нуля, 0 . Наиболее интересные обсуждения того, что это может значить, можно найти в блоге Эрика Мейерса. Вкратце, если мы возьмем моноширинный шрифт, контейнер с шириной из N букв, тогда, например, width: 40ch; всегда будет содержать выражение из 40 единиц этого конкретного шрифта. Когда стандартным использованием этого правила является пример шрифта Брайля, возможности творческого подхода существенно расширяют его функционал.

ex обозначается как «x-высота текущего шрифта ИЛИ половина 1em «. x-height выбранного шрифта называется высота буквы x нижнего регистра этого шрифта. Часто эта высота оказывается срединной точки всей высоты шрифта.

X-высота; высота буквы x нижнего регистра (читайте больше про структуру веб типографики)

Для этой единицы измерения существует множество вариантов использования, большинство из них являются небольшими дополнениями к основной типографике. Например, элемент sup , который обозначает надстрочные символы, может быть приподнят относительно своей позиции, если ему задать position: relative и значение свойства bottom 1ex. Таким же образом вы можете опустить подстрочные буквы еще ниже. Стандартные настройки браузера использует свои правила vertical-align надстрочных и подстрочных символов. Но если вам нужна более тонкая настройка, вы можете сделать ее следующим образом:

Могу ли я это использовать?

Единица ex существует примерно со времен CSS1, а вот для ch такой поддержки вы не найдете. Для ознакомления со спецификацией по поддержке свойств, ознакомьтесь со значениями и единицами CSS в блоге Эрика Мейерса.


Следя за постоянным развитием и расширением CSS, важно быть в курсе всех возможностей, которые доступны на текущий момент. Возможно вам встретится нетипичная проблема, которая будет требовать от вас нетипичного решения с использованием одной из этих малопонятных единиц измерения. Самое время почитать про новые спецификации. Подписывайтесь на рассылки от таких замечательных ресурсов, как, например, cssweekly. И не забывайте подписываться на еженедельные обновления, курсы, бесплатные уроки, такие как этот, по веб-дизайну на Tuts+!

Ch в CSS

Ой, недалеки времена, когда введут единицу измерения, равную ширине слова в третьей строчке пятого абзаца :) Столько требующих изменений модулей, а они единицы измерения новые придумывают.


Ну вреда от новых единиц я точно не вижу :). Rem — просто прелесть, все плюсы em-ов без их главного недостатка, удобны во всяческой адаптивности (и работают во всём новом!). Vh и vw полезны для веб-интерфейсов, где элементы нередко должны занимать определенную часть экрана. У ch тоже навскидку просматривается куча полезных применений — форматирование столбцов чисел, поля форм, соответствующие максимальному кол-ву вводимых символов… да хоть просто прикольные эффекты типа :)

Вот бы еще всё это великолепие поддерживалось повсеместно и единообразно (а не как та же ch в IE9)… Но это общая беда любых CSS-новинок, по-моему.


Не мог понять, почему в первом примере, показывающем недостатки em ничего не плывет, сколько бы не нажимал ctrl+. Все-таки браузер по умолчанию масштабирует всю страницу целиком, а не только шрифт. А для масштабирования только шрифта нужно лезть в настройки (а есть ли у некоторых такая возможность, например в Opera?). Предупреждать надо ;)

psywalker (Автор записи)

Нет проблем, чуть поправил ;)


Часть про новые единицы измерений очень интересна!
И вообще, в целом, хороший блог.
Например статья про абсолютное позиционирование в таблицах тоже очень понравилась.

psywalker (Автор записи)

Спасибо, но вот сейчас уже, изучая новые материалы, возможно кое что в статье придётся изменить. Например, как оказалось, единицу vm тихо переименовали в vmin

В общем следите за обновлением.

Anton Diaz

Изврат, конечно. Пиксель — не пиксель, а пункт — не пункт. Хотя отношусь с пониманием, так как иначе всё выглядело бы нечитабельно мелким на высоких DPI из-за того, что разработчики не научились использовать пункты.

Ну а какого было мое удивление, когда обнаружилось, что пункт привязан к пикселю! И это было совсем не так давно. Кстати, пиксель всё-таки не совсем абсолютная величина, так как если размер реального пикселя на экране не слишком разительно отличается от 1/96 дюйма, то логический пиксель будет равен физическому. Оно и понятно, так как в противном случае в появилась бы адовая интерполяция, которую на повышенных DPI еще можно понять-простить, но при плотности близкой к 1/96 — ни за что. И в этом как раз и состоит неадекватность пункта. Ведь на одном экране ширина элемента, назначенная в пункта, будет выглядеть другой на другом экране (из-за привязки к пикселю и различия в их размере). Однако пункт всё-таки не всегда привязан к пикселю. Например если использовать пункты в условиях Media Qeries, то там пункт уже совсем другой (вероятно, настоящий, типографский).


Да, CSS-пиксель нельзя назвать «совсем абсолютным» в бытовом понимании (как точную копию некоего платинового эталона из парижской палаты), тут смысл в том, что на любом конкретном устройстве пиксели, пункты, миллиметры и дюймы связаны однозначно (и если искажаются — то все разом, одинаково). Насчет этой взаимопривязки в спеке есть отдельная ремарка (
«Для поддерживающего CSS устройства эти меры связаны 1) посредством соотнесения физических единиц с их физическими размерами, либо 2) посредством соотнесения пикселя с «референсным пикселем». Для печати и подобных устройств с высоким разрешением, единицей привязки должна быть одна из стандартных физических единиц (дюймы, сантиметры и т.п.). Для устройств низкого разрешения и устройств с нетипичными расстояниями просмотра вместо этого рекомендуется привязка через пиксель. Для таких устройств рекомендуется, чтобы единичный пиксель относился к целому числу пикселей устройства, которое наболее приближено к «референсному пикселю» (т.е. 1/96 дюйма).»
Так что с точки зрения спеки это не баг, а фича. Да и как быть иначе, если ОС просто не сообщает браузеру честного разрешения монитора?

А вот насчет пунктов в Media Qeries, сорри, я не понял, нельзя ли пояснить (желательно примером)? Читал только про специфику мобильных браузеров (, но там вроде как раз пиксели «особенные»…

Anton Diaz

Anton Diaz

*Хватается за голову*
Скроллбар-то тоже входит в ширину окна!
Ну тогда всё окей, я ошибся :)

Anton Diaz

Ну а теперь по статье.

> Пиксель определили как 1/96 дюйма при рассмотрении с расстояния вытянутой руки

Это как? Реальная величина 1 дюйма разве меняется в зависимости от расстояния, с которого на него смотришь? ;)

Em-ы ты обругал вообще несправедливо (надеюсь, можно на «ты»?). Особенно в начальной редакции (статью прочитал 1—2 дня назад, но прокомментировать всё никак времени не было). Em — великолепная единица. Конечно, ее надо использовать с умом. Но это касается не только em. CSS вообще не терпит небрежности. По поводу первого примера — он вообще сверстан недальновидно, это касается далеко не только em. Вся раскладка «деревянная». Особенно удручает фиксированно заданные высоты.

Кстати, я совсем не понял прелести того, что em такой сверхточный. Это попахивает попыткой подогнать строки к размеру чего-либо, что в корне неверно. Никогда нельзя верить тому, как отрисовались шрифты. Вдруг у пользователя не окажется нужной гарнитуры? Тогда она поменяется на другую, а у другой гарнитуры будет совсем другая ширина букв и высота строки (одинаковый кегль и интерлиньяж вовсе не гарантирует одинаковую высоту строки). Более того, у пользователя может оказаться другое количество строк текста, даже если ширина блока нерезиновая. Так что фиксированная высота элемента не оправдана никогда! Исключение будет, если разработчик задумал там скроллбар.


> Реальная величина 1 дюйма разве меняется в зависимости от расстояния, с которого на него смотришь?
Насколько я понял, CSS1 (и CSS2.x поначалу) пытались привязываться именно к угловому размеру, а не к линейному. И только потом, представив реальное кол-во граблей на этом пути, плюнули и сделали как проще (т.е. как сейчас) :)

> Em-ы ты обругал вообще несправедливо
А мне кажется — наоборот перехвалил :). Помню, как я по молодости пытался сверстать пиксель-в-перфект дизайн с базовым размером шрифта, кажется, 13 (в общем, простое число) пикселей, используя em-ы. Коэффициенты для пересчета оказывались совершенно неудобными, а IE7 не желал принимать третью и последующие цифры после запятой, тупо обрубая до двух. В итоге как раз вертикальный ритм мне выровнять так и не удалось — при самом удачном раскладе каждая десятая-одиннадцатая строчка оказывалась на пиксель выше, отчего строки в соседних колонках сползали друг относительно друга. Причем в разных браузерах слегка по-разному. Возможно, я тогда тупо не умел их готовить, но возился долго и безуспешно…

psywalker (Автор записи)

А вот мне как раз наоборот, в итоге удалось заставить вертикальный ритм подчиняться, и получилось это благодаря именно ЕМ-ам. :)

psywalker (Автор записи)

Em-ы ты обругал вообще несправедливо (надеюсь, можно на «ты»?). Особенно в начальной редакции (статью прочитал 1—2 дня назад, но прокомментировать всё никак времени не было). Em — великолепная единица. Конечно, ее надо использовать с умом. Но это касается не только em. CSS вообще не терпит небрежности. По поводу первого примера — он вообще сверстан недальновидно, это касается далеко не только em. Вся раскладка «деревянная». Особенно удручает фиксированно заданные высоты.

Не спорю, первый пример я верстал очень давно, но, на самом деле дело совсем не в вёрстке, я нарочито подобрал два разных примера, где можно было бы видеть разницу от применения ЕМ-ов. И по-поему мне это удалось ;)

Кстати, я совсем не понял прелести того, что em такой сверхточный. Это попахивает попыткой подогнать строки к размеру чего-либо, что в корне неверно. Никогда нельзя верить тому, как отрисовались шрифты. Вдруг у пользователя не окажется нужной гарнитуры? Тогда она поменяется на другую, а у другой гарнитуры будет совсем другая ширина букв и высота строки (одинаковый кегль и интерлиньяж вовсе не гарантирует одинаковую высоту строки). Более того, у пользователя может оказаться другое количество строк текста, даже если ширина блока нерезиновая. Так что фиксированная высота элемента не оправдана никогда! Исключение будет, если разработчик задумал там скроллбар.

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

Ну может быть где-то перехвалил конечно, но совсем чуть-чуть :)


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

psywalker (Автор записи)

Спасибо, примем к сведению!


Кстати вот, тоже был удивлён когда выяснилось что пиксель != физическому пикселю экрана. Но, вообще, удивлён не слишком, поскольку мне казалось что то, что я вижу на разных экранах как один пиксель — не так уж мало, и во-вторых, зная что у мобильного устройства разрешение full hd, меня удивляло, каким же образом, сайты открываются в явно адаптированном для маленьких разрешений варианте (и шрифты, при этом, не слишком маленькие, читаемые).
И вот, теперь, всё более-менее встало на свои места. Большое Вам спасибо!


Да, кстати, % и em, по видимому, не всегда совпадают и для vertical-align:

в случае em, у шрифта берётся его численное значение, а в случае %, у шрифта берётся толи размер его кегельной площадки, толи «литерной» площадки, то ли некий line-height шрифта по-умолчанию, в общем как назвать не знаю, но зависит это от конкретного шрифта.


Верно! Для vertical-align за 100% берется фактическое значение line-height. Если оно не задано, то берется значение по умолчанию из метрик шрифта — т.е., да, высота того, что браузер по умолчанию заливает фоном текста (сам не знаю, как грамотно это назвать: однозначно не «кегельная» площадка, потому что не равна кеглю, «литерная» — похоже, моя отсебятина и у нее мало смысла в цифровом наборе… наверное, лучше, чем просто «дефолтный line-height шрифта» не придумать:).


Да-да, я уже соотнёс Вашу ссылку и мою, забавный получился венигрет! :-)


«мудрые дядьки из W3C исходили из того, что, если, например, верхнее или нижние отступы задать как процент от высоты родителя, это может привести к бесконечному циклу» — мне кажется исходили они не обязательно из этого, а может быть из того, что в этом случае появляется возможность «за один проход» (мне кажется, CSS специально проектировалося так, чтоб рендеринг был, по возможности, «однопроходным»: прочитал — разрисовал, пошёл дальше), то есть, без использования скриптов, строить геометрические фигуры нужных пропорций. По-умолчанию, понятное дело, прямоугольники:

но их, как известно, можно по разному трансформировать.

Что же касается бесконечного цикла, то тут есть пару моментов:
Во-первых цикл будет сворачивающимся, то есть, каждую итерацию изменения будут меньше и меньше, и, при достижении определённого порога можно и остановится.
Вот, смотрите сами:
В Вашей же терминологии отступ это паддинг?
Ну, если box-sizing: content-box, то вообще проблем, насколько я понимаю, не будет, скажем высота у нас 100 пикселей, а паддинг 40% от этой высоты, в этом случае при изменении паддинга высота не меняется, поскольку она паддинг не включает. Поэтому просто считаем паддинг и всё. Между прочим, это значение по-умолчанию, а значит по умолчанию, цикла не будет.
Если же у нас значение box-sizing отличается от контент-бокс, то оно включает в себя и паддинги и сложности будут. Но, давайте посмотрим какие:

Вот у нас высота 100 и паддинг 40%. По сути получается 100px + 40% = 100%. Получается, 100px в переводе на проценты это 60%. Один процент это 5/3, а
100% это 500/3 = 100 + 200/3 = 100 + 198/3 + 2/3= 100 + 66 + 1.98/3 + 0.02/3,
ну то есть, с 2/3 ситуация аналогичная 200/3, а поскольку у последнего целая часть равна 66, то далее следует 6 в периоде. Итого 100% это 166.(6), соответственно паддинг получается 166.(6) — 100 = 66.7 округляется до 67 пикселей.
Итого для машины
1. считаем скольким процентам равна известная нам высота.
2. находим один процент.
3. прибавляем нужное количество процентов.

Если же считать итерациями, то получится тоже самое:
К 100 прибавляем 40 (140) умножаем на 0.4 (получаем «текущие» 40% — 56)
Получившийся результат снова прибавляем к 100 (156) и снова умножаем на 0.4 (62.4)
Если посмотреть внимательно, то мы увидим, что, по сути, мы к 100 сначала прибавили 40 (0.4 от 100), затем прибавили 0.4 от 40 (16), потом 0.4 от 16 (6.4), потом 0.4 от 6.4 (2.56), то есть, мы от всё меньших частей находим 40% и прибавляем их к общему результату, и видя значение очередного члена, мы начинаем понимать к чему движется общая сумма.
Буквально 6-8 итераций в нашем примере, выявят результат, а уж с точностью до пиксела, и того меньше.

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


А если у дочерних элементов проставлен марджинв % (который считается от высоты родителя), то получается следующая ситуация:
1. Считается высота контента с учётом всех фиксированных составляющих, если они есть (высота/поля/отступы/границы).
2. А дальше от получившейся величины, отстёгивается % нужным дочерним элементам
3. от этого увеличивается высота

Но и тут ситуация аналогичная предыдущей. Скажем у нас есть два марлжина один 4%, другой 3% значит оставшийся контент занимает 100% — (4% + 3%) = 93%. И с итерациями, последовательно умножаем каждый кусочек на 0.04 и 0.03 соответственно, получившийся марджин снова умножаем на тоже самое складываем и так далее, получаются сходящиеся ряды.
Но в любом случае это, конечно, это лишние операции. Да и для верстальщика, наверное, не слишком удобно, поскольку нужно в голове держать сколько % расходуется, сколько осталось, если скажем у нас 5 марджинов по 5%, и три по 10%, получается контент считается как 100% — (5х5% + 3х10%) = 100% — 25% — 30% получается 45% считать высоту контента + все фиксированные составляющие. Можно так и в минус уйти ненароком, если, скажем у нас не 5 блоков будет, а 15 с 5% марджином.
В общем, такая раскладка, возможно, даёт лишнюю работу и машине и верстальщику.

Илон Маск рекомендует:  Asp объявления <object>


мне кажется, CSS специально проектировалося так, чтоб рендеринг был, по возможности, «однопроходным»

Не кажется, так и есть:) Именно из этой тонкости и «растут» многие раздражающие проблемы «на ровном месте» в CSS, типа вертикального центрирования при динамической высоте (если неизвестно, где блок кончится, то непонятно, где его начинать, чтобы сверху и снизу осталось поровну места) и неопределенности поведения таблиц.

Вариант с «последовательным приближением», пока разница не станет невидимой, для веба не годится: физические пиксели всё мельчают, физические разрешения растут, а сложные раскладки бывают еще и глубоко вложенными, так что шагов понадобится не так уж мало. Если на каждом шаге перерисовывать интерфейс, он будет «дерганным», если отрисовывать только после финального шага — будут заметные лаги (особенно на мобильных устройствах, у которых разрешение ого-го, а видеокарты еле-еле:). Алгоритмы новых схем раскладки стараются строить так, чтоб можно было за один-два прохода всё отмерить и один раз отрисовать.


Если на каждом шаге перерисовывать интерфейс, он будет «дерганным», если отрисовывать только после финального шага — будут заметные лаги

Согласен с этим. Да и вероятность ошибок больше.

Именно из этой тонкости и «растут» многие раздражающие проблемы «на ровном месте» в CSS, типа вертикального центрирования при динамической высоте

Вот как раз сегодня почти весь день промедитировал над известной Вам темой:

После того, как Вы объяснили как браузер строит раскладку в этом случае, возникло два основных вопроса:
1. А можно ли в принципе сделать так, чтоб у резинового блока, отступы/поля были пропорциональны блоку.
И, второй, возможно, возможно, чуть более компромиссный:
2. Возможен ли двухколоночный макет где один блок (в нашем случае правый) широкий по содержимому, а другой блок (левый) занимает всё оставшееся пространство.

Сначала думал над первым вопросом и вчера ночью, мне почему-то показалось что я был близок к решению, но сегодня что-то ничего толком не получилось, перешёл на второй вопрос и тоже сходу что-то ничего не идёт. Флексы я пока не рассматриваю, они где-то, конечно, помогают, но интересно что вообще возможно в классическом CSS 2.1… У меня пока получается, что если родительский блок резиновый, то либо дочерний блок (псевдоблок) пропорциональных размеров, но тогда, чтоб он вышел за пределы родительского блока, его нужно так или иначе вывести из потока, либо если мы создаём что-то, что «чувствуют» окружающие (например отступ) — то это уже от размеров общего родителя. Интересно, есть ли какой-то принцип, за который можно зацепиться, и увидеть, насколько резиновой может быть раскладка… Может исхитриться и что-нибудь в label обернуть, чтоб создать обратную зависимость…
А второй вопрос тоже относится к резиновости, может ли блок занимать ровно столько место, сколько ему дали, не перепрыгивая на другую строчку…
Вот такие мысли, по-поводу динамической отрисовки.


У меня на мобильном устройстве физический пиксель равен примерно 0.069 (1080/75 и 1920/133), тогда как px равен 0.26458(3) (дюйм/96).
Если px разделить на физический пиксель получится 3.8345. Я так понимаю округляется до 4?
То есть разрешение 1920 x 1080 трансформируется в 480 x 270?


Нет, к сожалению, производители телефонов выбирают коэффициент пересчета из собственных соображений. Например, у айфонов ниже 6-го ширина экрана считается равной 320 CSS-пикселей (т.е. >3 CSS-дюймов, при всего 2 физических). У айфона 6 — 375 CSS-пикселей, а у 6+ — внезапно 414 (т.е. коэффициент пересчета 2.6 с копейками, вообще не целый — там картинка тройного разрешения искусственно чуть ужимается, чтоб вписаться в стандартную FullHD-матрицу). А у некоторых моделей Android-устройств встречается коэффициент 2.25. Универсального правила, увы, нет:(. Но чаще всего для FullHD-устройств встречается коэффициент 3, т.е. экран считается 360х640 CSS-пикселей.


Гм. А как вообще может быть дробный коэффициент?


Как при масштабировании растровой картинки. Фактически тот же Айфон 6+ отрисовывает интерфейс как картинку 2208×1242, а потом ужимает ее целиком до 1920×1080. Некоторые тонкие линии, конечно, при этой процедуре могут «мылиться», но поскольку физические пиксели очень малы, обычно это практически незаметно.


Ну то есть принцип такой: у нас есть CSS пикселя белого цвета и четвёртый пиксель чёрного. Допустим коэффициент 2.25.
Получается 3 х 2.25 = 6.75
А дальше возможны варианты: либо округляем до 7, либо и, что более вероятно, 7ой цвет 7го пикселя будет считаться, как переходный между чёрным и белым, но поскольку «чёрных долей» в ней в три раза больше (0.75 против 0.25), то и цвет его будет ближе к чёрному.
Вообще, судя по всему, не такая простая проблема, поскольку приведённый мною пример, скорее, предельно упрощённая схема.
Но, возникает вопрос, в целесообразности дробных единиц — зачем они, когда веб-графика, по большей части, растровая?
Не проще либо, в приведённых Вами примерах, 2.25 округлить до двойки, а интерфейс рисовать сразу для FullHD, что, вероятно, было бы и «дешевле» с точки зрения вычислительных ресурсов… Или очень важно соблюсти px = 1/96 дюйма? Но для этого можно сделать просто чуть поменьше/побольше разрешение. Какой смысл в большем разрешение, если оно будет «мылить» наиболее часто выводимый на нём контент?


Насколько я понимаю, оптимизируют не столько под графику, сколько под текст — чтобы он был не слишком мелкий, но и не плющился в узкую колонку в одно-два слова на строку. Растровая графика (без запаса по разрешению) с той самой бикубической интерполяцией будет «мылиться» при любом коэффициенте больше единицы, так что таким образом пытаются выбрать наименьшее зло.


Для растровой графики, насколько я понимаю, чем больше разрешение, тем лучше, поскольку при масштабировании, врят ли возможно избежать дробных значений, да и они не так важны, поскольку изображаются не объекты, а пиксели определённого разрешения, а значит при любом увеличении разрешения, нужно считать переходы (кстати, при уменьшении, тоже вопрос, вот было у нас три пикселя, белый-черный-белый, а теперь эти три пикселя нужно уместить в два. как это сделать без замыливания? :) )
А для векторной графики, насколько я понимаю, дробный коэффициент, как раз плох, поскольку, чем на большее количество физических пикселей, попадают опорные точки, тем больше мыла (или придётся вносить не заметные искажения, которые, вероятно, в некоторых случаях, могут стать заметными, и/или существенными, например при необходимости точного чертежа).
Скажем, линия 1px (или другая CSS-ед.) solid black это вектор, потому что можно точно вычислить её границы. С другой стороны, лично я, не знаю способов, нагнуть этот вектор таким образом, чтоб совсем избежать ступенчатости.
Шрифты, я почему-то думал, что в основном растровые, и только точно векторный SVG. Но поискав в интернете информацию, поэкспериментировав с масштабированием на мобильном устройстве (в том числе посмотрев на поведение шрифтов с засечками), вспомнив и сопоставив всю имеющеюся информацию, я пришёл к выводу, что шрифты, всё же, в основе своей, векторные. Впрочем это, по видимому, большая тема…
Получается для сайтов с вёрсткой и текстом, лучше кратные разрешения, для изображений и видео экстремального разрешения (и, наверное, для игр) — чем выше разрешение, тем лучше (может ли кратность как-то облегчить жизнь — не знаю, нужно лучше в этом разбираться, чтоб дать точный ответ).
С учётом легкости масштабирования, мне представляется, что разрешения действительно лучше делать побольше, при этом CSS-пиксели всё-таки делать кратными обычным пикселям, а в жертву принести точность 1px = 1/96 inch, тем более, в мобильном устройстве широко используется масштабирование контента.
В этом смысле, не очень понятно, то, что Вы пишите:

текст — чтобы он был не слишком мелкий, но и не плющился в узкую колонку в одно-два слова на строку

вот скажем у нас физическое разрешение FullHD, а CSS 360х640 (коэфф 3). При размере шрифта в 16px, в моём устройстве, где коэфф соответствия px = 1/96 inch, должен равняться 3.83, поскольку 3 меньше 3.83, текст будет чуть меньше, чем предполагалось при вёрстке (впрочем, мобильники мы обычно держим ближе к себе, чем расположен экран монитора, поэтому разглядеть буквы нам будет проще, да и легко можно масштабировать). Если бы коэфф. был, скажем, 2.83 (например, размер устройства был бы больше, при том же FullHD, соотв. плотность пикселей была бы меньше) и этот коэфф. округлили бы до 3, и буквы (по-умолчанию) стали бы чуть больше. В любом случае колебания размера текста было бы не значительным, врят ли больше настолько, чтоб это как-то сказалось на восприятии строки. Скажем на строке было 15 слов стало 13 или даже 11. Думаю, разница не так уж существенна…
Впрочем, использование на мобильниках разрешения больше FullHD вообще, по-моему, вопрос немного спорный… Не то что я сильно против, просто задач, где это реально могло бы сказаться, пожалуй, чуть больше чем нисколько…


Для растровой графики, насколько я понимаю, чем больше разрешение, тем лучше

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

шрифты, всё же, в основе своей, векторные

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

разрешения действительно лучше делать побольше, при этом CSS-пиксели всё-таки делать кратными обычным пикселям, а в жертву принести точность 1px = 1/96 inch

В основной массе стараются так и делать. Именно поэтому у 5-дюймовых FullHD-экранов логический размер 360х640 CSS-пикселей, а не 235×418 (по соотношению 1/96), и текст действительно получается в полтора раза мельче (что компенсируется тем, что мобильники, действительно, держат ближе к глазам). Для разрешения 2560х1440 (большинство нынешних флагманов) уже берется коэффициент 4, что дает те же логические 360×640 (текст того же размера, но еще чуть четче). Дробные коэффициенты — всё-таки скорее исключение. Но они бывают:)


Большое спасибо за разъяснения! :)


Извиняюсь, если вопрос банален, но уверен, Вы много раз с ним сталкивались, а потому, вероятно, Вам не составит труда на него ответить :)
Мы говорили о максимальных разрешениях, а на какое минимальное разрешение экрана стоит ориентироваться?


Мне кажется, «практический потолок», на который сегодня стоит ориентироваться — это 4k (3840×2160). Как минимум под Windows оно может учитываться как 1dppx. По физическому разрешению рекорд, пожалуй, у iMac Retina 5k с 5120х2880, но оно актуально только для растровых картинок, в CSS-ных пикселях там скорее всего будет 2560×1440 (2dppx).


Про максимальные разрешения я понял, а минимальные?


Ой, прошу прощения за невнимательность(. Думаю, стоит ориентироваться на минимальную ширину 320px.


Почему-то у последнего уровня дерева ответов, нет кнопки ответить, поэтому отвечаю тут…
Задал Вам вопрос, а сам подумал: мы говорили про большие разрешения смартфонов, а чего я не спросил про вообще большие разрешения? Так что, Вы, своим ответом, предвосхитили мой следующий вопрос :) Вот теперь, про диапазон разрешений ясно.
Спасибо! :)


Что-то я не пойму, при медиа-запросах значение rem всегда, значение по-умолчанию(16px)?
Это можно как-то изменить?


Да, в теории и em, и rem в медиазапросах должны брать начальный размер шрифта из настроек браузера (16px, если эти настройки не менялись). На практике был один нюанс в Safari (возможно, уже исправили).


Статья отличная, автор проделал эксперименты, с помощью которых, можно понять, как ведёт себя браузер, во всех основных сценариях применения (гифки у него, только, черезчур медленные, засыпаю, когда смотрю, а когда просыпаюсь, мою остановку уже проехали). Тем не менее, насчёт его выводов у меня есть сомнения.
Ок, давайте назначать медиазапросы в em. Но, тогда, позвольте, у меня все элементы должны зависеть от размера шрифта. А, на мой взгляд, это не вполне правильно — пользователю, в плане масштабирования даны две степени свободы: менять масштаб, и менять размер шрифтов. Не могу сказать что для меня очевидно, зачем менять только шрифты, но, интуитивно, полагаю, что это, в некоторых случаях, может быть уместно.
При этом, как мне кажется, что в rem-ах, имеет смысл ставить размеры только у тех элементов интерфейса, которые, так или иначе, связаны с оформлением текстового содержимого.
А раз так, то давайте прикинем, что будет, если мы будем менять размер шрифта.
Рассмотрим гипотетический пример:

padding: 10%
@media only all and (min-width: 1600px)

@media only all and (min-width: 100em)

Мы взяли, да увеличили размер исходного шрифта, с 16 до 22px.
В первом случае (px), у нас в правилах ничего не изменилось, но, зато мог изменится размер блока, за счёт того, что контент стал чуть побольше.
В результате, при страничке шириной 1600px у нас уменьшился отступ, но из-за того, что шрифт стал больше, возможно уменьшился он «слишком рано» и оформление могло немного съехать.
Во-втором случае (em), правила изменили размер странички, при которой будет применено новое правило (от 2200px). Но, в случае, если у нас есть большие куски оформления, не зависящие от шрифтов, то правило может быть применено «слишком поздно», актуальность изменения отступа возникнет раньше, чем окошко «дойдёт» до нужного размера.
Как же быть?
Можно написать что-то вроде:

@media only all and (min-width: 1600px) and (min-width: 100em)

В случае двух min-width берётся большее значение (во всех ли браузерах?) и в нашем случае, при увеличении шрифта с 16 до 22px ситуация будет развиваться по второму варианту.
Вопрос: когда это критично?
Если у нас есть дизайн, который работает на 300px (значение от фонаря), то, предполагается, что «тоже самое» будет работать и на 500px. Поэтому, если при увеличении окна «старое оформление» будет оставаться чуть дольше, по-идее, это, конечно плохо, но не смертельно. Поэтому, в этом случае em предпочтительнее.
Но что будет, если мы уменьшим шрифт? Может получится с точностью до наоборот. Вёрстка предназначенная от 300px переключится в новый режим от 250px и что-нибудь может съехать.
Но в случае, когда мы используем в медиа-запросе оба правила с em и px, то последний случай исключается.
Получается дублирование единиц измерения некий костыль, не дающий вёрстке съехать, в крайнем случае.
Вообще говоря, не совсем понятно, из каких соображений нельзя переопределять размер шрифта браузера для медиа-запросов. Как минимум, для прозрачности кода, мне представляется, лучше писать в примечании, что em зависит от браузера и по-умолчанию равно 16px (поскольку если в документе, по-умолчанию, оно везде равно 10px, то не мудрено, запамятовать).
Второе, а какое решение, предложили бы Вы?
Третье, какое, с Вашей точки зрения, решение, могло бы быть стремящимся к идеалу? (с учётом специфики CSS, то есть «однопроходной» логики, без циклов). Мне представляется, возможность использоваться функцию calc в самом запросе. С учётом возможности добавления дополнительных условий через оператор or, наверное, это было бы достаточно для большинства ситуаций, хотя, если честно, не до конца уверен, что достаточно представляю весь спектр возможных ситуаций…
ЗЫ: код вида:

.pixel <
background: red;
@media (min-width: 400px) <
opacity: 0.5

написан на каком-то препроцессоре?


Можно ли в вёрстке использовать линии, меньше чем 1px, рискуем ли мы получить «невидимые нити», в каких единицах измерения это лучше делать, скажем 0.3px или 0.03rem?
Всегда ли браузеры округляют до px или в некоторых случаях до физических пикселей, или даже до субпикселей?


Использовать можно, но желательно всё-таки тестировать:). Насколько я в курсе, до целых физических пикселей округляются значения тех свойств, которые так или иначе отображаются целыми пикселями, типа border-width или padding (но есть нюансы — например, как минимум в почти всех десктопных браузерах на Windows padding: .1px остается невидимым, но считается ненулевым и не дает схлопываться margin-ам!), а не округляются значения свойств, задействующих субпиксельный рендеринг (тени, letter-spacing и т.п.). А на невидимую линию можно наткнуться и с целыми пикселями, но при нестандартном масштабе в браузере (напр. 90%). Принципиальных различий между поведением разных единиц в этом плане лично я не замечал, но не исключаю, что они могут быть, буду благодарен за примеры.


Ну вот в смартфоне, с коэффициентом 1 к трём, в каком-то месте ширина width: 33.3% и, для простоты, предположим что 1% = 1px. Будет ли смарт задействовать свой «свободный» реальный пиксель для отрисовки 0.3% или округлит нафик? :) И, вне зависимости от, как Вы считаете, насколько оправдана подобная отрисовка?


Думаю, зависит от конкретного алгоритма отрисовки. По логике, должен задействовать. Но вообще надо тестировать (и, скажу по секрету, у нас в черновиках лежит заготовка небольшой отдельной статьи на эту тему:).



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


ну и в поисковике: всякие там % css precision, но, если честно, жаль много времени тратить на поиск тривиальной информации, наверняка она лежит в широко известных в узких кругах местах :-)


Про проценты не знаю, а про дробные пиксели для расчетов есть такая информация: в Edge минимальный «квант» длины — 0.01px, в Сафари и Хроме — 0.015625px (1/64), а в Firefox — 0.01666259765625px (1/60 с 32-битной точностью).

CSS 3 Timing Functions и с чем их едят

Хей народ, пристегните ремни и держитесь покрепче, ибо наступил действительно волнительный момент: вам предстоит разобраться в тонкостях чрезвычайно интересных временных функций CSS!

Окей, ваша кровь, конечно, вряд ли закипела от предмета данной статьи, но шутки в сторону: временные функции — своего рода скрытая жемчужина, когда дело касается CSS, и, вполне вероятно, вы удивитесь тому, сколько всего интересного с помощью них можно сделать.

Прежде всего, мы должны четко понимать, когда применяются временные функции в CSS. Так вот, данный функционал предназначен для работы с CSS анимацией: переходами (transitions) и покадровой анимацией (keyframes).

О временной функции в CSS

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

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

Заметка: свойства timing-function не существует. Называя это свойство, на самом деле я имею в виду transition-timing-function и animation-timing-function .

Прежде чем пойти дальше, давайте познакомимся с синтаксисом и посмотрим, как он вписывается в весь процесс определения CSS анимации. Простоты ради, давайте используем CSS переход и пропишем все transition-свойства по отдельности:

Сокращенная запись перехода не имеет строгого порядка значений, но требует, чтобы значение transition-delay находилось после значения transition-duration (не обязательно непосредственно после). Кроме того, значение transition-duration является единственным необходимым для определения функции. А поскольку значения по умолчанию у остальных параметров вполне приемлемы, для определения перехода вам редко понадобится нечто большее, чем:

Но это же скучно. Несмотря на то, что значений по умолчанию вполне достаточно для какого-нибудь обычного hover’а, когда вы работаете над чем-то более существенным, временные функции оказываются серьезным инструментом для тонкой настройки ваших анимаций!

Теперь, когда вы знаете, что делают временные функции, пришла пора узнать, как они это делают.

Заглянем под капот

Многие из вас наверняка не заостряли свое внимание на допустимых значениях свойства timing-function . Так вот, их пять: ease (по умолчанию), ease-in , ease-out , ease-in-out и linear . При этом данные значения — всего лишь короткая запись определения кривой Безье.

Вы можете быть незнакомы с данным термином, однако я держу пари, что в действительности вам доводилось видеть кривую Безье. Черт побери, если вы использовали какой-либо графический пакет, то наверняка даже сами создавали её! Именно так, ибо когда вы используете инструмент Pen или Path для создания гладкой кривой, то, что у вас получается, — и есть кривая Безье! В нашем случае она — «волшебство» временной функции, описывающее тип ускорения на графике.

Данная кривая Безье соответствует значению ease (изображение принадлежит Smashing Magazine)

Если ваша реакция на впервые увиденную кривую Безье была подобна моей, у вас наверняка возник вопрос: как вообще такая кривая может быть построена по четырем точкам на графике?! Вряд ли смогу я вам объяснить это на словах, однако у меня есть фантастическая гифка, которая поможет мне в этом:

Илон Маск рекомендует:  Таблица имен

Рисование кривой Безье (изображение взято из Википедии)

Поскольку данная кривая строится по четырем точкам, мы называем ее кубической (cubic) кривой Безье, в отличие от квадратичной кривой (quadratic, по трем точкам) и кривой четвертого порядка (quartic, по пяти точкам).

Функция cubic-bezier()

А вот сейчас вам станет еще интереснее, ибо я скажу, что вы можете задавать кубическую кривую с помощью функции cubic-bezier() , используя её вместо ключевых значений свойства timing-function . Полагаю, вам необходимо некоторое время, дабы сдержать волнение.

С помощью функции cubic-bezier() вы можете манипулировать кривой так, как вам заблагорассудится, задавая при этом абсолютно любые параметры ускорения вашей анимации! Так что давайте посмотрим, как эта функция работает и каким образом она позволяет создавать собственные кривые Безье.

Во-первых, мы уже знаем, что кубическая кривая строится по четырем точкам: 0, 1, 2, 3. Во-вторых, важно помнить, что первая и последняя точки (0 и 3) уже определены на графике, где точка 0 всегда имеет значение 0;0 (снизу слева), а точка 3 — 1;1 (сверху справа).

Данное условие оставляет нам всего две точки, которые необходимо разместить на графике, и сделать это можно с помощью функции cubic-bezier() ! Она принимает четыре аргумента: первые два — координаты x, y первой точки; вторые два — координаты x, y второй точки.

Чтобы вы освоили синтаксис и то, как эта функция создает кривую, а также её физическое влияние на анимацию, я покажу вам пять ключевых значений свойства timing-function , их эквивалент для cubic-beizer() и результирующий эффект анимации.


Давайте начнем с данного ключевого значения, поскольку и логику построения кривой, и переложение её на анимацию сейчас, вероятно, проще всего понять.

Совершенно симметричная кривая Безье, что означает, что ускорение и замедление анимации будет производиться с одинаковой скоростью (изображение принадлежит Smashing Magazine)

Точка 1 расположена на 0,42 по оси x и на 0 по оси y, в то время как точка 2 — на 0,58 и 1 соответственно. Результат — совершенно симметричная кривая Безье: ускорение и замедление анимации будет происходить с одинаковой скоростью. Отсюда и название ключевого слова.

Посмотрите на демонстрацию и вы увидите физический эффект значения ease-in-out , сравните его с другими значениями.

Данное ключевое значение является значением по умолчанию свойства timing-function . На самом деле, оно очень похоже на предыдущее, хотя ускорение анимации происходит быстрее, а замедление — более постепенно.

Кривая ease имеет крутое начало и много более плавное продолжение (изображение принадлежит Smashing Magazine)

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


Как не сложно догадаться, данные ключевые значения имеют противоположный смысл. ease-in плавно ускоряет анимацию развивая максимальную скорость к её завершению, в то время как ease-out плавно снижает изначально максимальную скорость перед завершением анимации. Следуя логике, ключевое значение ease-in-out , которое мы рассмотрели ранее, — отличная комбинация этих двух кривых Безье.

Кривые Безье: ease-in слева, ease-out справа (изображение пренадлежит Smashing Magazine)


Последнее ключевое значение, которое вообще-то к кривым не относится. Исходя из названия, значение linear свойства timing-function устанавливает одинаковую скорость в течение всей анимации, что означает, что вместо кривой Безье мы получим прямую линию. То есть в данном случае не имеется какой-либо модели ускорения для изображения на графике.

Значение linear подразумевает одинаковую скорость на протяжении всей анимации (изображение принадлежит Smashing Magazine)

Если вы вновь посмотрите демо в начале, то наверняка заметите, что несмотря на одинаковую общую продолжительность, некоторые из анимаций кажутся медленнее остальных. Почему же так происходит? Ну, например, у ease-in-out начало и завершение анимации проходит с оттяжкой. Поэтому, чтобы уложиться в заданную продолжительность, в основной части скорость анимации существенно выше. В виду такого поведения мы воспринимаем её и короче, и быстрее, тогда как, например, линейная анимация кажется нам длинной и растянутой.

Возможно, к этому моменту у вас уже возникло ощущение, что данная статья слишком уж медленно подходит к своей истинной сути, так что давайте прямо сейчас перейдем к рассмотрению функции cubic-bezier() и созданию собственных временных функций с её помощью.

Создание собственных моделей ускорения с помощью функции cubic-bezier()

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

К настоящему моменту предполагается, что вы уже умеете располагать точки 1 и 2 на графике с помощью функции cubic-bezier() , а также ясно представлять, каким образом это влияет на анимацию. Хотя, если вы делаете это «в слепую», не удивительно, что данное занятие может очень быстро надоесть.

К счастью, существуют на Земле такие люди, как Лиа Веру (Lea Verou), которые, вероятно, не успокоятся пока кодинг на CSS не станет еще легче! Ли разработала приложение «Кубический Безье» для создания собственных кривых Безье и сравнения их со стандартными. Так что вместо того, чтобы гонять туда-сюда циферки в cubic-bezier() , зайдите на Cubic Bézier, поиграйтесь с кривой да посмотрите на результат. Это куда круче!

Скришнот страницы сайта Cubic Bézier (изображение принадлежит Smashing Magazine)

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

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

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

Пример нестандартной кривой Безье (изображение принадлежит Smashing Magazine)

Основное отличие данной временной функции от значений по умолчанию состоит в резком отклонении кривой от шкалы «прогрессии» (по оси y). Это обуславливает быстрый старт и завершение анимации, но затяжную паузу в середине (в том месте, где кривая выравнивается). Данная модель резко контрастирует с той, к которой мы привыкли с обычными временными функциями, которые используют противоположный подход, замедляя анимацию в начале и конце, а не по середине.

А теперь проявим изобретательность

Да-да: кривые Безье становятся еще более захватывающими! И кто бы мог подумать? Тем временем, границы воображения расширяются с открытием того, что лишь шкала времени (по оси x) ограничена на графике промежутком от нуля до единицы, в то время как шкала прогрессии (по оси y) может выходить за его рамки как снизу, так и сверху.

Шкала прогрессии — это именно то, о чем вы подумали: нижний конец (0) являет собой начало анимации, а верхний (1) — завершение. Как правило, кубическая кривая Безье всегда следует снизу вверх по данной шкале с разной интенсивностью, пока не достигнет конечной точки анимации. Тем не менее, возможность располагать точки 1 и 2 вне промежутка 0-1 позволяет кривой выходить за его пределы, что вызывает движение в обратном направлении! Как обычно, лучший способ понять это — посмотреть:

Кривая безье со значениями за пределами 0-1 (изображение принадлежит Smashing Magazine)

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

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

Кривая Безье со значениями за пределами 0-1 (изображение принадлежит Smashing Magazine)

Теперь у вас должно быть вполне ясное представление о том, как значения cubic-bezier() за пределами 0-1 могут физически повлиять на поведение анимации. Мы, конечно, можем глазеть на перемещающиеся кубики целый день, но давайте таки закончим данный раздел примером, который ясно покажет изобретательский подход в использовании временной функции.

Всё верно: мы анимируем воздушный шарик! Чего. То ли это, что вам всегда хотелось делать с помощью CSS?

Суть анимации в «надувании» шарика по клику таким образом, что он взлетит к «потолку» и слегка отскочет от него, как по-настоящему. Значение cubic-bezier() за границей 0-1 и есть тот инструмент, который позволит нам создать этот эффект «отскока», повторяя реалистичное поведение. В представленном фрагменте кода показаны координаты, выставленные в функции cubic-bezier() , а далее показана полученная кривая.

Кривая Безье, эмулирующая «отскакивающий» шарик (изображение принадлежит Smashing Magazine)

Данный пример отлично показывает, как кривая трансформируется в итоговую анимацию, поскольку кривая отражает её практически идеально. Сначала кривая проходит от начала шкалы прогрессии по прямой, заставляя шарик двигаться от её начала до конца с одинаковой скоростью. Затем, подобно замедлению шарика, кривая резко изгибается в обратном направлении, прежде чем начать постепенно возвращаться к вершине. На самом деле всё очень просто!

Так что как только вы освоите кривую и искусство манипулирования ею, будете умницей!

Временные функции и покадровая анимация CSS

Перед тем, как мы пойдем дальше, следует упомянуть о поведении временных функций при использовании их в покадровой анимации. Общий смысл тот же (в сравнении с переходами [transition]), однако есть одно исключение, которое стоит запомнить: когда вы применяете временную функцию к нескольким кадрам, она выполняется на каждом отдельном кадре, нежели на протяжении всей анимации.

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

Исходная анимация на Codepen (гифка получилась кривоватой)

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

Если для какого-либо конкретного кадра вам необходимо определить собственную временную функцию, то определите её прямо в коде этого кадра, как показано в следующем примере:

Временная функция steps()

Вы думали, что на этом наши приключения окончены? Как бы не так! Я ведь уже говорил вам, что CSS не ограничивается встроенными временными функциями!

В данном разделе мы изучим концепцию «пошаговых» функций и заменим кривые прямыми линиями с помощью временной функции steps .

Данная функция весьма полезна, несмотря на свою специфичность. Она позволяет разбить анимацию на отрезки, что будет отличать её от обычного анимированного движения. Например, если нам надо переместить квадрат на 400 пикселей вправо за 4 шага в течение 4 секунд, то вместо плавного движения он будет «прыгать» на 100 пикселей каждую секунду. А теперь давайте взглянем на код данного примера. Он, должно быть, просто дуновение свежести после погружения в тонкости функции cubic-bezier() !

Как видите, все дело в определении количества отрезков анимации. Но имейте в виду, что оно не может быть отрицательным или десятичным числом. Есть и второй, не обязательный, аргумент, возможные значения которого — start и end (последнее является значением по умолчанию).

Значение start запускает анимацию в начале каждого шага, а end — в конце. Применительно к «движущемуся квадрату», данная картинка поможет лучше объяснить разницу между двумя этими значениями.

Различие значений start и end функции steps() (изображение принадлежит Smashing Magazine)

Как видите, со значением start анимация начинается немедленно, а при end — с задержкой в одну (в данном случае) секунду.

Ну, и ради пущей всеобъемлющности материала, отметим, что у функции step() есть два предопределенных аргумента: step-start и step-end , эквивалентные записи steps(1, start) и steps(1, end) соответственно.

Изобретательный подход к «пошаговым» функциям

Наверняка из повседневных задач вам вряд ли так уж часто будет выпадать анимация движущегося квадрата, тем не менее с помощью функции steps() можно сделать уйму других крутых штук. Допустим, если в вашем распоряжении имеется несколько мультяшных спрайтов, то вы можете использовать уже изученную технику для создания анимации, используя всего пару CSS свойств! Давайте посмотрим на демо и код.

Итак, у нас есть прямоугольник 125 пикселей в ширину с фоновым изображением на 2 000 пикселей, содержащим 16 кадров. Изначально это изображение расположено по левому краю прямоугольника, и всё, что нам предстоит сделать, — сдвигать его влево так, чтобы все 16 кадров прошли через маленькое «окошко» нашего прямоугольника. При «обычной» анимации кадры просто пролетели бы мимо, однако с функцией steps() фоновое изображение сдвигается влево ровно за 16 шагов, в достаточной мере показывая каждый кадр изображения. Вот так мы сделали мини-мультик всего лишь с помощью CSS анимаций!

Демонстрация способа смещения фонового изображения так, что каждый кадр пройдет через небольшое «окошко» (изображение принадлежит Smashing Magazine)

Еще одно забавное использование функции steps() я нашел благодаря Лиа Веру (кому же еще?), которая придумала весьма интересную анимацию компьютерного набора. О ней я вам сейчас и расскажу.

Для начала, вам нужен какой-то текст. А также, к сожалению, вам необходимо знать, сколько символов он содержит, ибо вам придется использовать это количество в CSS. Еще одно условие: шрифт должен быть моноширинным для того, чтобы все символы имели одинаковую ширину.

Наш текст состоит из 11 символов. Длину строки мы укажем с помощью единицы измерения ch , а для браузеров, не имеющих её поддержки, мы напишем другое значение. Далее по правой стороне строки мы поставим черную рамку, которая станет курсором. И теперь, когда всё на месте, нам нужно лишь анимировать текст, а это чрезвычайно просто.

Нам понадобятся две отдельные анимации: одна для курсора, другая для печати. Чтобы сделать курсор, необходимо всего лишь заставить мерцать черную рамку.

Как и предполагалось, рамка просто меняет свой цвет с черного на прозрачный и обратно. В данном случае функция steps() имеет определенный смысл: уберите её, и курсор, вместо того, чтобы «моргать», будет плавно появляться и исчезать.

Наконец, анимация печатания столь же проста. Всё, что нам нужно сделать, — уменьшить длину строки до нуля, а затем постепенно наращивать её за 11 шагов (по количеству символов).

Текст будет «раскрываться» по одной букве за шаг в течении восьми секунд, в то время как «курсор» ( border-right ) будет мигать постоянно. Техника проста настолько же, насколько и эффективна.

Теперь мы можем дополнить этот замечательный пример, попробовав обратный эффект — удаление текста. Для этого нужно изменить ключевое слово кадра с from на to и затем добавить параметр animation-fill-mode со значением forwards , чтобы удостовериться, что когда текст «удалится» (т. е. когда анимация завершится), он останется «удаленным». Посмотрите на демо.

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

Поддержка браузерами

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


Браузер С префиксом Без префикса
Internet Explorer Нет 10+
Firefox 4+ ( -moz- ) 16+
Chrome 4+ ( -webkit- ) 26+
Safari 3.1+ ( -webkit- ) 6.1+
Opera 10.5+ ( -o- prefix) 12.1+

Несмотря на то, что все новейшие версии браузеров откинули префиксы для переходов, все-таки было бы не лишним дополнительно прописывать свойства с префиксом -webkit- для поддержки устаревших мобильных браузеров. В то же время, с точки зрения прогрессивного улучшения, я думаю, что необходимость использования префиксов -moz- и -o- уже прошла.


Браузер С префиксом Без префикса
Internet Explorer Нет 10+
Firefox 5+ ( -moz- ) 16+
Chrome 4+ ( -webkit- ) Не поддерживается
Safari 4+ ( -webkit- ) Не поддерживается
Opera 12 ( -o- prefix), 15+ ( -webkit- prefix) Только 12.1 (не поддерживается после перехода на WebKit)

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

Так что же мы узнали о временных функциях CSS? Давайте подытожим.

  1. Они определяют, когда анимация ускоряется и замедляется
  2. Они гораздо круче, нежели набор предопределенных значений
  3. Вы можете создавать эффект «отскока» с помощью значений cubic-bezier(), выходящих за пределы промежутка 0-1
  4. Вы можете разбить анимацию на несколько шагов/отрезков
  5. Поддержка браузерами великолепна и только улучшается

И, несмотря на кросс-платформенность описанных технологий, это не было бы статьей о техниках CSS 3, если бы я не упомянул о прогрессивном улучшении. Всегда идите от простого к сложному: убедитесь, что ваша работа доступна на устройствах и в браузерах, которые не поддерживают данный функционал, перед тем, как создавать эффекты для браузеров, которые смогут их обработать.

А теперь вперед! Счастливых шажков и искривлений!

CSS Versicherung. Ihre Krankenkasse. Ihr Gesundheitspartner.

Die CSS Versicherung ist nicht nur eine Krankenkasse, vielmehr eine Versicherung für jede Lebenslage. Wenn es um die Gesundheit geht, vertrauen uns rund 1,7 Millionen Menschen. Wir begleiten Sie auf Ihrem ganz persönlichen Weg – sei dies beim gesund bleiben, gesund werden oder beim Leben mit der Krankheit.

Dank unserem breiten Angebot gehören wir in der Schweiz zu den führenden Kranken-, Unfall- und Sachversicherern. Neben der obligatorischen Grundversicherung und den freiwilligen Zusatzversicherungen schützen wir Sie mit unserer beliebten Reiseversicherung auch während Ihren schönsten Tagen des Jahres. Mit der Privathaftpflicht-, Hausrat- und Gebäudeversicherung erhalten Sie den optimalen dreifach Schutz.

Wir sind da, wo Sie sind!

Gerne nehmen sich unsere Kundenberater für eine persönliche Beratung Zeit. Finden Sie die CSS-Agentur in Ihrer Nähe.

Сокращения в CSS

Грамотное написание файлов стилей может разработчику значительно облегчить работу, сократив его объем до 2-х раз. Трудно оспорить, что работать с файлом в 1000 строк ощутимо проще, чем в 2000. Да и написать одну строку быстрей, чем четыре.

Так же не забываем, чем меньше символов в файле, тем меньше его вес. Чем меньше вес, тем быстрее грузятся страницы.

Не указываем единицы измерений для нулевых значений

Ноль в чем бы он ни был будет равен нулю. Поэтому

лучше написать как

Правила сокращений цветов background и color

Цвета можно задавать в шестнадцатеричном коде — каждый цвет описывается 6 цифрами в шестнадцатиричном формате. Например белый (white) = #FFFFFF, красный (red) = #FF0000. Код цвет можно сократить, если все 6 цифр одинаковы. Например,
#000000 = #000

Правила сокращений для background

Порядок свойств значения не имеет. Но следует учесть, что первое значение background-position — значение относительно левого края блока, второе — относительно верхнего края для случаев, когда позиция фона задана координатами:

Правила сокращений для border

Порядок строгий — ширина бордюра (border-width), тип бордюра (border-style), цвет бордюра (border-color). Аналогичное сокращение действует и для border-bottom, border-left, border-top, border-right. Например:

Правила сокращений для font

Порядок имеет значение — первыми идут font-style, font-variant, font-weight не важно в каком порядке, далее пара font-size/line-height, затем font-family.

Правила сокращений для list-style

Порядок значения не имеет.

Правила сокращений для margin и padding

Порядок жестко определен — margin-top, margin-right, margin-bottom, margin-left. Запомнить очень легко — начиная сверху по часовой стрелке. Для padding правило аналогино:

Если значения всех отступов одинаковы, можно сделать запись еще компактней.

Также возможны парные сокращения:

Не ставим точку с запятой для последних свойств элементов

Для последних свойств элементов (классов) не обязательно ставить точку с запятой. Без нее нормально работает и CSS проходит валидацию.

update 13.01.10 by dma84: Некоторые браузеры игнорируют последнее свойство, если закрывающая скобка отделена от свойства пробелом или переводом строки (если кто знает подробней об этой особенности, например, в каком браузере наблюдается — пишите).

Понравилась статья? Поделиться с друзьями:
Кодинг, CSS и SQL