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".
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.
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.
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.
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.
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.)
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.
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.
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.
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 %.
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.
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 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.
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?
52 comments
[ 0.21 ms ] story [ 114 ms ] threadBut yeah, that is the worst reaction I've seen from a page when zooming.
Oh well, css sucks, but it's at least funny to look at.
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).
https://imgur.com/a/uEwI5mk
Self-awareness is important when you set out to teach others.
It seems like a good idea at first (larger viewport? larger text!) but not a recommended practice.
http://web.archive.org/web/20120226153810/http://www.ghodmod...
Then there is viewport relative units such as vw and vh and the new container relative units cqw, cqh etc. and of course %.
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.
Let’s fix font size - https://news.ycombinator.com/item?id=26633148 - March 2021 (347 comments)