I need to know the current em, based on the context, inside of a css style sheet. Is that possible?
I want to calculate the number of pixels for two items: one is in pixels and the other is em:
--item-min-width: 250px;
--gap: 3em; (note: this might be different and is not known until runtime)
--max-number-items: 3;
Now I need the total width of those three items, plus the gap. Something sort of like this (which of course won't work because I can't add pixels (item-min_width) and em (gap)):
#media (min-width: calc(
var(--max-number-items) * var(--item-min-width) + var(--gap)
))
The goal is to convert the gap (3em) to pixels dynamically. Is it possible to figure out the current em of an element?
You don't need to convert units, calc can handle that:
calc(100% + 10px)
calc(2rem - 1%)
calc(var(some-var) + var(another-var))
https://developer.mozilla.org/en-US/docs/Web/CSS/calc
To get the em value in px. Set default font size for the body (browsers have the default font size of 16px).
EM value compound with nesting of elements, refer the MDN docs(link given below).
So, let say you have set the default font size of 16px.
1 em = 16px.
Now you have a gap of 3em. So 3*16px = 48px.
3*250px + 48px = 798px.
Please have a look at this article from MDN: https://developer.mozilla.org/en-US/docs/Web/CSS/font-size#Ems
and this article from w3schools(Set Font Size With Em): https://www.w3schools.com/css/css_font.asp
Related
Let us suppose we have a project where font size is calculated dynamically using calc CSS function. Moreover we want to have a border which width is going to be expressed in rem (relative to font size).
In some cases pixel size of the border width is less than 1px therefore it's impossible to render.
How to set the border width to be not less than 1px?
Generally, setting a min() isn’t fully supported in most modern browsers, but looking at the CSS 4 spec; there are functions for max and min.
https://www.w3.org/TR/css-values-4/#calc-notation
Example:
.type {
/* Set font-size to 10x
the average of vw and vh,
but don’t let it go below 12px. */
font-size: max(10 * (1vw + 1vh) / 2, 12px);
}
Alternatively you can use a CSS preprocessor or perhaps even a post processor to min the value from the calc;
I have two sites on which the font is set by
* {
font-family: "Varela Round", sans-serif;
}
Since the font-size is not specified, the browser use his standard values for each element. But if I set the size to 0.9em the size is really small. The output of window.getComputedStyle(element).fontSize also shows different px values. If I set font-size: 13px the size is everywhere the same.
But if I set the size to 0.9em the size is really small.
Yes, it is a relative size.
The body becomes 90% of the font size of the html.
A section inside the body becomes 90% of the body (so 81% of the html).
A p inside the section becomes 90% of the section (so 72.9% of the html)
And so on.
If I set font-size: 13px the size is everywhere the same.
Absolute units do not vary based on the font size of the parent element.
This explanation is summarized from the site Css Font Size
The reason for this is the fact, that px is not relative to other elements. % and em instead are relative to their parent which results in the following effect:
Since 100% = 1em the two units can almost (see % vs em) be used analogously.
One solution is to use rem, which acts similar to em but does not inherent the value from the parent.
An other is to set a default size for the main element e.g. body and then set the font-size relative to the parent for all elements.
I'm using a technique for scaling text based on view width, here. It uses a simple formula to smoothly scale within a set range (min/max) of font sizes, depending on view width within a set range (min/max). It works very well.
But I'm confronting an issue with this and other techniques for fluid font size. If I set letter spacing to constant value, it may breaks down visually. 1px letter spacing for a font displayed at 20px might not be ideal for when it displays at 50px.
There are also situations where a user might change the font size. It would be the same issue.
Is there a solid way to deal with this issue that is fluid, to make letter-spacing proportional to the font size?
Try using em units to control the the spacing.
here is a possible reference: https://cssreference.io/property/letter-spacing/
I tried using calc, along with view width:
letter-spacing: calc(1px + (10 - 1) * ((100vw - 320px) / (1440 - 320)));
It works, but I think using ems is better.
Recently I've discovered this site: https://varagon.com/
They are using some interesting calc formula for calculating window size based font size. Formula is as following:
font-size: calc(22px + 54 * ((53vw + 53vh) - 600px) / 820);
For screen dimensions 1920x1126 px computed font-size value is 88.8006px.
Could you explain what every value in formula is for?
EDIT:
Maybe I didn't express my question properly - I know what VH and VW are, my question is about whole calc formula. Ie. why are they adding 22px to sum of half of heigh and width, etc. :)
I tried to reverse engineer/math it, unsuccessfully for now.
In the site, they have used Viewport-percentage lengths.
To read about this click here.
The values are:
vw (1% of the initial containing block width)
vh (1% of the initial containing block height)
vi (1% of the viewport size in the direction of the root element's inline axis)
vb (1% of the viewport size in the direction of the root element's block axis)
vmin (the smaller of vw or vh)
vmax (the larger or vw or vh)
If we take a vw, if the width of the viewport is 200mm, the font size
of h1 elements will be 16mm (i.e. (8×200mm)/100).
h1 { font-size: 8vw }
From this, we can see that, when the viewport width increases the font-size increases.
The font-size of the website has been calculated from the above-mentioned concept.
I found possible answer - this formula is some kind of 'vmax' polyfill (as for lack of IE11 support for this value).
Polyfill that I found looks very similar formula I was asking about:
https://gist.github.com/uto-usui/ea9836aa92d334e7694fb31d8e93a4f4
1) I came across THIS ARTICLE today, which states:
The most popular method in working with em values is to set the
font-size on the body to 62.5%. Because the default browser font-size
is 16px, this makes it 10px (without hard-setting it to 10px, which
wouldn't cascade).
What I just quoted (above) essentially means that, I CAN'T set the font-size of the body to 10px directly and then define the font-sizes of other elements in em or % based on that. Isn't it what it meant, or did it get it wrong?
For example, I have body {font-size: 10px;}. And now I set p {font-size: 1.4em;}. Doesn't it mean, the font-size of p is actually 14px? Isn't that cascading? (or is this going to cause me problems on other devices? - - mobiles, tablets, etc.)
2) For any given element, defining its font-size as 1.8em or 180% makes no difference what-so-ever, right? I mean precisely, for an element (whose size we are defining), an em is essentially a decimalized form of %, isn't it?
EDIT: 3) 'em' is often referred to as a very mobile-friendly sizing unit. How about %? Is it just as good, considering Q2?
1) The article is wrong when it says that font size in pixels “wouldn’t cascade” (and this reflects a misunderstanding of what the cascade is). You can use em or % for the font sizes of inner elements if you like. You would be setting font size in pixels for them, just indirectly. The flexibility you get is that things will be easier if you later change the base font size set in pixels. On the other hand, em or % settings may imply rounding that will be treated differently by different browsers in some cases.
If you set body {font-size: 10px;} p {font-size: 1.4em;}, then (unless other style sheets interfere), the font-size of p will be 14px. But this has nothing to do with the cascade. It’s a consequence of basic definitions for units and font-size.
2) For font-size, 1.8em and 180% have the same meaning by definitions. There used to be reasons to favor one or the other, due to browser bugs with the other, but these considerations have lost significance.
3) Yes, using % is just as good.