CSS Tip: An em isn't an "m", but an ex is an "x" (2012) | Hacker News Reader

CSS Tip: An em isn't an "m", but an ex is an "x" (2012)

blog.frankmtaylor.com

56 pointsthunderbong45 comments

Open articleView on HN

Side note: we have the `cap` unit now as well, the height of a capital letter (ignoring descenders).

Nice one, this was new to me. Looks like as em has rem, cap also has rcap for deriving the value from the root font.

Can't help mentioning this: https://tonsky.me/blog/font-size/

Font size is useless; let’s fix it (2021) - https://news.ycombinator.com/item?id=35929362 - May 2023 (8 comments)

Let’s fix font size - https://news.ycombinator.com/item?id=26633148 - March 2021 (347 comments)

Also: 1ch is the width of ‘0’

There's even an "eastern" equivalent. `ic` ("ideograph count") is the width of 水 ("water" in Chinese/Japanese/Korean).

Thank you. This is what makes i18n hard when you're not a native of the country you're designing for and you're not reading design blogs for other cultures. That property has never shown up on any of the sites I read.

for me the linked page does not load, but here's the archived version of the experiment

http://web.archive.org/web/20120226153810/http://www.ghodmod...

Since the definition of Em and Ex are circular, how do bowser implementers go about actually building them? Do the actual implementations differ from the spec in that regard?

They're not really circular. `1em` simply refers to the font size value. `1ex` is derived from the font size + font choice.

I remember seeing some video enumerating all the dozens and dozens of units CSS has now, but I'm a simple man, and I just use rems for everything.

I think I saw all of them in a CSS Tricks post, but I too took the "simple" way. At first, I marvelled at the complexity of CSS units, but it didn't take long for me to tire of them.

Some tricks are still useful though, like using `calc` with `v[w|h]`, `[r]em` and `%`, that yield favourable and interesting results; fortunately you only have to remember and understand a subset of units to take advantage of this.

The short answer: rem is for global sizing and em is for local or component level sizing.

Why would you deny your self font aware units (such as cap or ex) or inline relative units (such as ch)? Column width form example are very intuitive to see in ch units. 30-42 ch fits roughly 30-42 characters on a line and is nice to read. 120+ ch is too long and is perfect for max-inline-size of a container with a lot of body text. Specifying that in em is kind of just guessing.

Then there is viewport relative units such as vw and vh and the new container relative units cqw, cqh etc. and of course %.

Every time a new unit is added I find a use for it almost immediately to clean up my designs and clean up my CSS. I've practically rid myself entirely of media selectors for viewport sizes.

I agree with all of that; I was responding to a comment someone made about only using rems for everything. I probably posted it to the incorrect thread.

(2012)

I would rather using rem for line height instead. It is easier to maintain vertical rhythm.

Yes, prefer rem. em is fraught with peril especially once you get to deeply nested elements.

I mean, em and rem serve different purposes. Like let’s say you want to append a permalink icon to different headings, you can scale its size easily based on the size of the heading it’s attached to. This is when em comes in and rem makes no sense. Unless you want to keep the icon the same size regardless, in which case rem makes the most sense.

When the website loaded, my first action was to zoom out, because the author chose a humongous font size. Somehow, this set off a chain reaction of font size changes that took a few seconds to resolve; I don't know what goes on, but zooming out lowered the size of the body text, then after a noticeable lag the size of the header, which then increased again (?) and then the font size of the body increased again (???). I have trouble believing that a website with this kind of behavior would contain a useful "CSS Tip".

It's because all the font sizes in the page are relative to:

   html {font-size: calc(0.5vw + 1rem)}

In other words, the (user configurable) browser default size plus 0.5% of the viewport width, which is kind of insane. One (intended?) side effect is that the font size grows and shrinks as you resize the browser window horizontally.

There's a better way to do this:

    html { font-size: clamp(16px, 2vw, 20px); }

Pick a reasonable minimum and maximum, and between them a calculated value that scales with viewport width. (You can see this in action in the sites in my bio.)

Yes, viewport units (like vw) don't always respect user settings, such as zoom levels or custom font sizes.

It seems like a good idea at first (larger viewport? larger text!) but not a recommended practice.

There really is good info in the article. It’s less a tip and more detail on the spec that I didn’t know.

I think it's some CSS transition, not Javascript, but yeah that is really distracting..

The author is generally in no position to lecture anyone about css…

https://imgur.com/a/uEwI5mk

Exactly. Learning about layout from whoever created this page is like going up to Charlie Brown and asking him to teach you how to fly a kite.

The article doesn't talk about layout or design. Is there anything you object to in the information? Or is it just the 12+yr old design of a personal website you want to snipe about?

All I'm suggesting is that the general attitude embodied by that page ("Your browser developer doesn't know how to handle zooming. Here, let me show you how it's done") seldom makes the impression the author would like to achieve.

Self-awareness is important when you set out to teach others.

Now I want to see a CSS blog by Charlie Day of It's Always Sunny in Philadelphia.

Honestly, the typesetting on the entire page is an absolute mess.

On a mobile zoom seems to work normally, but pinch-zoom is not the same as browser zoom (ctrl + mousewheel).

Yes, mobile zoom is normally just cropping the viewport and showing only a part of the total website. Desktop browser basically adjust the font size of the root element to zoom, I think.

"Desktop browser" zoom changes the virtual screensize. 50%zoom gets you 2 times document.body.clientWith

So all the elements that refer to the screensize, will update automatically, but usually this is quite smooth.

But you can listen for the event and do all kinds of things manually (and maybe too much).

I wonder whether it worked well in 2012 when the article was written?

Likely an effect of the circular dependency of stuff. Even with javascript off it's weird, and even at 20% zoom level the font keeps growing up to something I would already consider as too large.

Oh well, css sucks, but it's at least funny to look at.

CSS is specifically designed so that are no circular dependencies (beyond a fixed number of required passes).

It is really fun to watch it as you zoom though!

But yeah, that is the worst reaction I've seen from a page when zooming.

Can confirm. But is it a bug or is it a feature?

If a page malfunctions in a way that 99.999% of sites don't, it's not a feature.

Clearly you haven't heard about the latest CSS feature: closed-loop font size control.

No joke, I've implemented closed-loop font-size control in updateTextSize(), https://www.nayuki.io/res/full-screen-clock-javascript/full-...

Clearly, we need automatic differentiation for DOM attributes, so that Newton-Raphson could be used in such cases.

The circular reference is because em and ex are relative to the font size of the surrounding context, and you need to pick a physical (or derivable-from-physical) unit for the root context. em and ex always refer to the M and x height because that's how fonts work in the old "lead type" world.

Reply on news.ycombinator.com