Why is the em unit defined in terms of the font actually used to render the text, and the ex unit using the first available font?
To me, that looks like the font used to compute the height of ex can be different from the font actually used to render the text.
Quoting the specs:
The first available font, used for example in the definition of font-relative lengths such as ‘ex’ and ‘ch’ or in the definition of the ‘line-height’ property, is defined to be the first available font that would match the U+0020 (space) character given font families in the ‘font-family’ list (or a user agent's default font if none are available).
Why does the algorithm look for the space to compute the height of the letter 'x'? An explanation in layman terms would be very appreciated.
Why is the em unit defined in terms of the font actually used to render the text, and the ex unit using the first available font?
This shouldn’t be the case: both units are intended to be relative to the current font. The definition you provided mentions “font-relative lengths such as ‘ex’,” which also includes the ‘em’ unit.
That said, it seems like the authors agreed that the definition of “first available font” should be clarified: https://github.com/w3c/csswg-drafts/issues/4796
The section you quoted seem to imply that if the first font in the font-family list exists, but the U+0020 (space) character isn’t in the font, then the next font should be used. In practice, it sounds like browsers weren’t doing this anyway, and that probably wasn’t the original intent.
You can see the change that is being made to the definition here, as summarized in that issue: https://github.com/w3c/csswg-drafts/commit/7c2108c1764f328e0b60fffed47d3885a3dc7c11?diff=split
Why does the algorithm look for the space to compute the height of the letter 'x'? An explanation in layman terms would be very appreciated.
For the purpose of collecting and calculating font metrics, the U+0020 space is most likely the earliest and most common code point that could contain that information and would make sense to check. Many metrics are being calculated then, like the line height and em unit, not just the ex unit.
Beyond that, CSS ex unit section gives more detail on how that value is determined:
The x-height is so called because it is often equal to the height of the lowercase "x". However, an ex is defined even for fonts that do not contain an "x". The x-height of a font can be found in different ways. Some fonts contain reliable metrics for the x-height. If reliable font metrics are not available, UAs may determine the x-height from the height of a lowercase glyph. One possible heuristic is to look at how far the glyph for the lowercase "o" extends below the baseline, and subtract that value from the top of its bounding box. In the cases where it is impossible or impractical to determine the x-height, a value of 0.5em must be assumed.
Related
My question is, simply, how many (non-zero) decimal places can I include in a value I use in a CSS stylesheet before the browser rounds the number when interpreting it?
NOTE: I am aware that any decimal pixels are rounded (differently by different browsers) because the screens cannot display sub-pixel units. What I am asking is before that rounding takes place, what number of decimal places will be retained to begin performing the final browser rendering calculations/roundings.
Be it truncation or rounding, in an ideal world, neither of these things should happen. The spec simply says that a numeric value may either consist of
one or more digits, or
any number of digits, followed by a period for the decimal point, followed by one or more digits.
The spec even accounts for the fact that the leading zero before the decimal point in a value that's less than 1 is not significant and can thus be omitted, e.g. opacity: .5. But there is quite simply no theoretical upper limit.
But, due to implementation limitations, browsers will often "round" values for the purposes of rendering. This is not something you can control other than by changing the precision of your values, and even so, this behavior can vary between browsers, for obvious reasons, and is therefore something you cannot rely on.
While studying this document on the Evolution of JPEG, i came across "The law of the eight" in Section 7.3 of the above document.
Despite the introduction of other block sizes from 1 to 16 with the SmartScale extension, beyond the fixed size 8 in the original JPEG standard, the fact remains that the block size of 8 will still be the default value, and that all other-size DCTs are scaled in reference to the standard 8x8 DCT.
The “Law of the Eight” explains, why the size 8 is the right default and reference value for the DCT size.
My question is
What exactly is this "law of the eight" ?
Historically, was a study performed that evaluated numerous images from a sample to arrive at the conclusion that 8x8 image block contains enough redundant data to support compression techniques using DCT? With very large image sizes like 8M(4Kx4K) fast becoming the norm in most digital images/videos, is this assumption still valid?
Another historic reason to limit the macro-block to 8x8 would have been the computationally prohibitive image-data size for larger macro-blocks. With modern super-scalar architectures (eg. CUDA) that restriction no longer applies.
Earlier similar questions exist - 1, 2 and 3. But none of them bother about any details/links/references to this mysterious fundamental "law of the eight".
1. References/excerpts/details of the original study will be highly appreciated as i would like to repeat it with a modern data-set with very large sized images to test the validity of 8x8 macro blocks being optimal.
2. In case a similar study has been recently carried-out, references to it are welcome too.
3. I do understand that SmartScale is controversial. Without any clear potential benefits 1, at best it is comparable with other backward-compliant extensions of the jpeg standard 2. My goal is to understand whether the original reasons behind choosing 8x8 as the DCT block-size (in jpeg image compression standard) are still relevant, hence i need to know what the law of the eight is.
My understanding is, the Law of the Eight is simply a humorous reference to the fact that the Baseline JPEG algorithm prescribed 8x8 as its only block size.
P.S. In other words, "the Law of the Eight" is a way to explain why "all other-size DCTs are scaled in reference to 8x8 DCT" by bringing in the historical perspective -- the lack of support for any other size in the original standard and its defacto implementations.
The next question to ask: why Eight? (Note that despite being a valid question, this is not the subject of the present discussion, which would still be relevant even if another value was picked historically, e.g. "Law of the Ten" or "Law of the Thirty Two".) The answer to that one is: because computational complexity of the problem grows as O(N^2) (unless FCT-class algorithms are employed, which grow slower as O(N log N) but are harder to implement on primitive hardware of embedded platforms, hence limited applicability), so larger block sizes quickly become impractical. Which is why 8x8 was chosen, as small enough to be practical on wide range of platforms but large enough to allow for not-too-coarse control of quantization levels for different frequencies.
Since the standard has clearly scratched an itch, a whole ecosphere soon grew around it, including implementations optimized for 8x8 as their sole supported block size. Once the ecosphere was in place, it became impossible to change the block size without breaking existing implementations. As that was highly undesirable, any tweaks to DCT/quantization parameters had to remain compatible with 8x8-only decoders. I believe this consideration must be what's referred to as the "Law of the Eight".
While not being an expert, I don't see how larger block sizes can help. First, dynamic range of values in one block will increase on average, requiring more bits to represent them. Second, relative quantization of frequencies ranging from "all" (represented by the block) to "pixel" has to stay the same (it is dictated by human perception bias after all), the quantization will get a bit smoother, that's all, and for the same compression level the potential quality increase will likely be unnoticeable.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 9 years ago.
Improve this question
As the title says, I want to know what exactly the CSS unit 'em' stands for.
As in 'cm' stands for centimeter.
I am not asking what 'em' is or how it is used!
I couldn't find an answer on W3C.
The Wikipedia article was already saying "something":
The name of em is related to M. Originally the unit was derived from the width of the capital "M" in the given typeface.
My interpretation of the first sentence would be that 'em' is the pronunciation/phonetic for the letter 'M'.
But reading the second sentence, it seems that the 'e' in 'em' stands for something regarding the width of the letter 'M'.
So I'm still lost, what 'em' really stands for!
That is a historical definition; in modern usage it simply refers to the size of the font, with the word "em" itself no longer having any practical or relevant meaning. As a matter of fact, the same Wikipedia article expands on this evolution in its usage and meaning in a later section:
One em was traditionally defined as the width of the capital "M" in the current typeface and point size, as the "M" was commonly cast the full-width of the square "blocks", or "em-quads" (also "mutton-quads"), which are used in printing presses. However, in modern typefaces, the character M is usually somewhat less than one em wide. Moreover, as the term has expanded to include a wider variety of languages and character sets, its meaning has evolved; this has allowed it to include those fonts, typefaces, and character sets which do not include a capital "M", such as Chinese and the Arabic alphabet. Thus, em generally means the point size of the font in question, which is the same as the height of the metal body a font was cast on.
Particularly in terms of CSS, an "em" doesn't necessarily refer to the width of the capital M for a particular font; it's just a relative quantity.
If you're asking about the etymology of the word "em", Wikipedia itself only contains a reference to the Adobe Glossary, which has little more to say about it:
A common unit of measurement in typography. Em is traditionally defined as the width of the uppercase M in the current face and point size. It is more properly defined as simply the current point size. For example, in 12-point type, em is a distance of 12 points.
It's not explicitly mentioned anywhere authoritative that it's a phonetic representation of the capital M, but considering its namesake definition I wouldn't rule out such a possibility.
In my opinion em stands for nothing but just pronunciation/phonetic for the letter 'M'. Similarly we have ex, one ex is the x-height of a font (x-height is usually about half the font-size).
Just a quick question to clear up some confusion that I have regarding units on CSS perspective.
On the CSS Transforms spec it references it with px e.g. perspective: 1000px; but I have used and in many other places others have used it without px e.g. perspective: 1000; such as on W3Schools.
Is either way more preferred? Does it matter?
Just want to clear this up, thanks.
Just because it's accepted by (some) browsers doesn't mean it's correct.
Specifying a unit of measurement is required by the CSS spec, unless the value is zero.
The spec says:
Lengths refer to distance measurements and are denoted by <length> in the property definitions. A length is a dimension. A zero length may be represented instead as the <number> ‘0’. (In other words, for zero lengths the unit identifier is optional.)
A dimension is a number immediately followed by a unit identifier.
(emphasis mine)
See the Distance Units and the Other Units for examples.
Also see the MDN discussion of length
px (or other absolute unit) is the correct way. Here is documentation (better than w3 schools) :)
https://developer.mozilla.org/en-US/docs/CSS/perspective
Can I change the default unit from pixel to mm?
For example I want when move an element left and top to be in mm not in pixel?
There is no 'default unit'. The CSS spec requires that a length (other than zero) that is missing a unit be treated as an error (and thus ignored).
In quirks mode (and you should almost never be using quirks mode, it makes life more difficult), most browsers will perform error recovery and assume you meant pixels (despite the spec forbidding this).
From the standard:
A <quirky-length> is syntactically identical to a <number-token>, and is interpreted as a 'px' length with the same value.
(In other words, Quirks Mode allows all 'px' lengths in the affected properties to be written without a unit, similar to unitless zero lengths.)
If you are working with screen media — avoid physical units. Most systems are not calibrated to calculate the DPI correctly (so when converting from physical units into something a monitor understands (pixels) they get it wrong).
Specifying CSS units is a requirement for non-zero values. Browsers may try to guess what you meant, but it would still be a broken stylesheet according to the standard.
I.e. there is no "default unit" in CSS2, it's just that the browser may try to help you out, although it may as well just ignore your statement that doesn't specify units as an invalid one.
No, you can not change the default unit, but it shouldn't be too much to just put the units there:
#foo {
left: 22mm;
top: 20mm;
}
You should always specify the unit nevertheless, because it is required and browsers might interpret unitless values differently.
As there's no "default unit" and you need to provide the unit when positioning an element, you can just use "mm" instead of "px".
AFAIK if no explicit unit was specified (like 'em' or '%') then "px" is concatenated to the value and there is no way to override this default behavior.
Yes, You can do this indirectly by assigning variable for unit:
--unit: 1mm;
--value: 10;
--variable: calc(var(--unit) * var(--value));
No, that's not possible since different screens might have different sizes while still having the same resolution. Ultimately leading to pixel or relative notations.