> Let's start with the basics: if you write`font-size: 16px`then `16px` is the size of what? Sadly, the answer is "nothing in particular" -- this is a size of a virtual box around the glyph, but the box isn't tight, and the size of the glyph varies, depending on the font. Luckily, `font-size-adjust` property can fix it, and make `font-size` consistent across fonts.
All modern browsers default to 16px, but for accessibility and sanity reasons, we shouldn't use pixels.
By default, 16px = 1rem. You don't need to declare it; it just is.
Also by default, 16px = 100% if using percentage for font-size.
> Can you just set `font-size: 18px`or whatever works best for your chosen font? I think the answer is yes, but there are some caveats to keep in mind.
If you want to manually increase the base size, using relative units is the answer: `html { font-size: 1.125rem }`. Since by default, 1rem = 16px, 1.125rem is 18px.
> Setting `font-size` in your CSS disables that second approach.
Setting `font-size` in pixels disables changing the browser's default size; works fine with relative sizes.
If the goal is not having to learn the intricacies of CSS, just use the built-in type scale:
BTW, the main use case of `font-size-adjust` is for changing the font size of your fallback font incase your primary web font doesn't load or if it takes too long depending on what `font-display` is set to. You want the metrics of the fallback font to match the primary font so the text doesn't shift [1].
> > Let's start with the basics: if you write`font-size: 16px`then `16px` is the size of what? Sadly, the answer is "nothing in particular" -- this is a size of a virtual box around the glyph, but the box isn't tight, and the size of the glyph varies, depending on the font. Luckily, `font-size-adjust` property can fix it, and make `font-size` consistent across fonts.
> All modern browsers default to 16px, but for accessibility and sanity reasons, we shouldn't use pixels.
That's not what that means. font-size specifies the size of the font's em box, but the correlation between the em box and the visual size of the font is not consistent across fonts. font-size-adjust can adjust how a font-face responds to the font-size so that the sizing is consistent with other fonts of that size. For example, capsize is easier to implement that way.
Note: The following of course varies from site to site based on how design focused the site needs to be.
I had thought about writing some things about this, but I will put a quick observation here
>restrict yourself to using only markup-meaningful semantic tags, and then figure out CSS which works with the markup you have.
this used to be the best practice advice about 20 years ago. If you've been around long enough in programming, especially in web development, you will see cycles of best practice advice where the thing you were told as the best practice at one time becomes the worst practice later.
For example at one time it was considered "best practice" to put script tags at the head of the document.
Anyway this guy really isn't the person to give you best practice advice, as he notes.
The semantic tags advice is dear to my heart and I wish it were so, but it is wrong, unless the site you are working on is the online representation of a textbook or something highly structured like that, in which case it is spot on.
The reason why it is wrong is that most of the web is a design focused medium, as opposed to a meaning focused medium. In a meaning focused medium the semantics are the most important thing, because semantics are how we convey meaning. That's pretty much tautological there.
In a design focused medium obviously semantics of things are important, but so is arbitrariness. To see that arbitrariness is important, pick up any highly visual magazine that has been applauded for its design aesthetic. Obviously no magazine is completely arbitrary but even more structured ones like The New Yorker need to do somewhat arbitrary things with the layout and design to enforce the rules of taste which guide it.
It is not impossible for a design focused publication that in moving between articles that the look of headlines change (although always recognizably headlines), the necessity of splitting things up with visually arresting details that delight the reader is common place, typography and images are there to delight the visual sense, not to clarify a point being made in the article, as a common rule.
If you were to try to semantically describe all these effects and things with meaningful class names you would end with lots of drivel, essentially, or things that mixed presentation description with semantics like ".ArtDecoHeading" perhaps, and that is because the difference in presentation of many of these things communicate absolutely not semantic value but only that it looks cool or nice or whatever way you want to describe the effect of design on the target of the design.
This relates to lots of CSS frameworks where the names of classes describe not what the element is or means, but rather what the class does, because when design affects are placed in a somewhat semi-arbitrarily manner this is really the most sensible way to describe a lot of classes.
Again, as nothing is completely arbitrary you will find things that are a mix of semantic classes like
".productTitle"
Semantics and Presentation mixed
".bigHeader"
and pure presentation that is trying its best to seem semantic somehow
".sideBoxSlideIn .upDownJumper"
I mean definitely you have to identify what parts of your application have semantic meaning, where the design will not arbitrarily affect them, such as .productTitle, but I believe in most modern web development much of what you will be doing is not semantic styling, but design styling.
And when you are doing design styling you might find you're creating layers and layers of wrapper elements, because making wrappers is often one of the easier ways to solve arbitrary layout problems.
On edit: this was partially prompted by the guy claiming never to have written production CSS and saying he is not really the person to be giving advice here, and I agree because he does not understand the actual needs of web development as a design based medium. Which is why he suggests such previous best practices a...
I mean, this has a lot of out of date information which I guess is not surprising for someone who says I'm not an expert and don't do production CSS, but it is weird to get the suggestions that are pretty reasonable for 5+ years ago.
So many complaints about web technology, where is the replacement? I'd be interested to know if there was the one true layout system that everyone agrees on
To call a CSS pixel not an actual pixel but a measurement of an angle at a reading distance is... technically correct... but isn't really representative of how it's actually rendered. On a non Hi-DPI display at 100% scaling in the browser and OS, a px is a device pixel. An css inch is considered 96px, with the assumption that a CSS inch is an imperial inch on a 96 DPI display.
Yes, it's a bit fuzzy now with modern displays (especially when display scaling is not at a whole number haha) but it just kinda feels like searching for something to complain about. If your browser and OS doesn't get in the way you can get exact measurement. This also applies to almost any UI framework that has some integration with the OS.
> There isn’t a fully general solution to positioning and sizing GUI boxes.
flexbox. You can literally recreate any fully responsive desktop style GUI with it. You just need to layout your elements the same way you would in a GUI designer like QtCreator or Glade. Which means thinking in terms of divs with flex-grow set on them to get the automatic container expansion you get with "vertical boxes" or "horizontal boxes". These divs will sometimes be empty if you want a simple "expander" box.
Once you have it down you can look at any desktop GUI and just inherently understand how it maps into this flexbox model.
Yea, back in the day there was this h-box and v-box containers for the Widgets. I still think of my HTML that way, and div-soup to make them (is it soup tho?). Used to be TD soup.
Person who hasn’t spent enough time understanding web design feels entitled to make a CSS mark sheet.
Most of the “bad” is really “I haven’t worked with this enough and I will judge it from my limited point of view”.
What a waste of time
> If you “View Source” on any “real” website, you’ll notice that everything has layers and layers of wrapper elements, so you might be tricked into thinking that wrappers are how you solve layout problems. I can’t really agree or disagree here, as I never wrote “production” CSS, but, in my experience, it’s much easier to understand if you do the opposite — restrict yourself to using only markup-meaningful semantic tags, and then figure out CSS which works with the markup you have.
CSS isn't powerful enough by itself to create any layout you want without modifying the HTML. You almost always need wrapper elements to group elements you want to align together for presentation purposes only (e.g. "a vertically centered row containing one paragraph next to two vertically stacked images"), so there often aren't semantic HTML tags that would make sense.
It's similar to how you use numerous groups/frames in design apps like Inkscape and Figma to help align elements, where nobody would suggest you were a bad designer for using groups that don't have semantic meaning.
You can only really avoid wrapper elements for simple Markdown style pages with simple designs, where the CSS for that is straightforward.
I think in these discussions, it needs to be clearer how complex the page designs being discussed are. The CSS advice that makes sense for simple Markdown style pages is very different to what makes sense for a complex web app UI or a highly designed marketing page.
I think this has changed a lot since CSS Grid, especially. A lot of my HTML work has been removing "wrappers" either physically deleting them or in cases where they are "load bearing" due to some UI framework or component boundary making heavy use of `display: contents;` or `grid-template-${'columns' | 'rows'}: subgrid;`, depending.
> You almost always need wrapper elements to group elements you want to align together for presentation purposes only (e.g. "a vertically centered row containing one paragraph next to two vertically stacked images"), so there often aren't semantic HTML tags that would make sense.
I'd argue that a lot of times those groupings are meaningful.
> using only markup-meaningful semantic tags, and then figure out CSS which works with the markup you have
I agree with the approach you are suggesting, but the reason I find these wrappers pop up: it's VERY hard to make components composable without them.
Let's say you want to have a block that adds spacing between each item within it. Easy: it's flexbox with a gap. Oh no, but a child is displayed inline, and has weird vertical alignment. And another child has an unexpected align-self. Now you get wrappers on the children.
Maybe you want a button. It's got an icon with text. You need a wrapper on the text, because without a wrapper you basically can't get anything right (you can't rather bare text with CSS).
How about a checkbox? Should be easy. You want the component to have the checkbox on the left with the text on the right. You want to allow two rows of text, with the first being in bold (the label) and the second row being a description or help text. You wrap the whole thing in a label element because you care about accessibility. But you need a dummy div to render the checkbox, because you can't reasonably style checkboxes. And each row of text needs a wrapper, because bare text. And maybe another wrapper around the two rows, because while you can use CSS grid to position the two rows above each other, lord only knows what the checkbox is inside of and whether it's flexbox or grid, and the height of the label might be weird and jack up the positioning of your text. God help you if any of the rows have text that doesn't wrap and is wider than the width of the checkbox's container.
The unfortunate truth is that you probably don't need the wrappers, but there's an element of defensive coding that just makes it infinitely easier to get things right all the time with wrappers.
> Use CSS nesting to avoid writing “far reaching” selectors and style component-per-component
I view nesting as a footgun. I recommend trying to restrain all CSS to one selector, and to instead view additional qualifiers as an escape hatch where needed. Death to specificity.
26 comments
[ 5.0 ms ] story [ 57.3 ms ] threadUhmmm, ok
> Let's start with the basics: if you write`font-size: 16px`then `16px` is the size of what? Sadly, the answer is "nothing in particular" -- this is a size of a virtual box around the glyph, but the box isn't tight, and the size of the glyph varies, depending on the font. Luckily, `font-size-adjust` property can fix it, and make `font-size` consistent across fonts.
All modern browsers default to 16px, but for accessibility and sanity reasons, we shouldn't use pixels.
By default, 16px = 1rem. You don't need to declare it; it just is.
Also by default, 16px = 100% if using percentage for font-size.
See "The Ultimate Ideal Bestest Base Font Size That Everyone Is Keeping a Secret, Especially Chet" - https://adrianroselli.com/2024/03/the-ultimate-ideal-bestest...
> Can you just set `font-size: 18px`or whatever works best for your chosen font? I think the answer is yes, but there are some caveats to keep in mind.
If you want to manually increase the base size, using relative units is the answer: `html { font-size: 1.125rem }`. Since by default, 1rem = 16px, 1.125rem is 18px.
> Setting `font-size` in your CSS disables that second approach.
Setting `font-size` in pixels disables changing the browser's default size; works fine with relative sizes.
If the goal is not having to learn the intricacies of CSS, just use the built-in type scale:
By default, medium is 16px which is 1rem.You can write `p { font-size: medium }`.
BTW, the main use case of `font-size-adjust` is for changing the font size of your fallback font incase your primary web font doesn't load or if it takes too long depending on what `font-display` is set to. You want the metrics of the fallback font to match the primary font so the text doesn't shift [1].
[1]: https://www.w3.org/TR/css-fonts-4/#font-size-adjust-prop
> All modern browsers default to 16px, but for accessibility and sanity reasons, we shouldn't use pixels.
That's not what that means. font-size specifies the size of the font's em box, but the correlation between the em box and the visual size of the font is not consistent across fonts. font-size-adjust can adjust how a font-face responds to the font-size so that the sizing is consistent with other fonts of that size. For example, capsize is easier to implement that way.
https://seek-oss.github.io/capsize/
(I agree that specifying font size in pixels rather than rem is bad practice.)
I had thought about writing some things about this, but I will put a quick observation here
>restrict yourself to using only markup-meaningful semantic tags, and then figure out CSS which works with the markup you have.
this used to be the best practice advice about 20 years ago. If you've been around long enough in programming, especially in web development, you will see cycles of best practice advice where the thing you were told as the best practice at one time becomes the worst practice later.
For example at one time it was considered "best practice" to put script tags at the head of the document.
Anyway this guy really isn't the person to give you best practice advice, as he notes.
The semantic tags advice is dear to my heart and I wish it were so, but it is wrong, unless the site you are working on is the online representation of a textbook or something highly structured like that, in which case it is spot on.
The reason why it is wrong is that most of the web is a design focused medium, as opposed to a meaning focused medium. In a meaning focused medium the semantics are the most important thing, because semantics are how we convey meaning. That's pretty much tautological there.
In a design focused medium obviously semantics of things are important, but so is arbitrariness. To see that arbitrariness is important, pick up any highly visual magazine that has been applauded for its design aesthetic. Obviously no magazine is completely arbitrary but even more structured ones like The New Yorker need to do somewhat arbitrary things with the layout and design to enforce the rules of taste which guide it.
It is not impossible for a design focused publication that in moving between articles that the look of headlines change (although always recognizably headlines), the necessity of splitting things up with visually arresting details that delight the reader is common place, typography and images are there to delight the visual sense, not to clarify a point being made in the article, as a common rule.
If you were to try to semantically describe all these effects and things with meaningful class names you would end with lots of drivel, essentially, or things that mixed presentation description with semantics like ".ArtDecoHeading" perhaps, and that is because the difference in presentation of many of these things communicate absolutely not semantic value but only that it looks cool or nice or whatever way you want to describe the effect of design on the target of the design.
This relates to lots of CSS frameworks where the names of classes describe not what the element is or means, but rather what the class does, because when design affects are placed in a somewhat semi-arbitrarily manner this is really the most sensible way to describe a lot of classes.
Again, as nothing is completely arbitrary you will find things that are a mix of semantic classes like ".productTitle"
Semantics and Presentation mixed
".bigHeader"
and pure presentation that is trying its best to seem semantic somehow
".sideBoxSlideIn .upDownJumper"
I mean definitely you have to identify what parts of your application have semantic meaning, where the design will not arbitrarily affect them, such as .productTitle, but I believe in most modern web development much of what you will be doing is not semantic styling, but design styling.
And when you are doing design styling you might find you're creating layers and layers of wrapper elements, because making wrappers is often one of the easier ways to solve arbitrary layout problems.
On edit: this was partially prompted by the guy claiming never to have written production CSS and saying he is not really the person to be giving advice here, and I agree because he does not understand the actual needs of web development as a design based medium. Which is why he suggests such previous best practices a...
Yes, it's a bit fuzzy now with modern displays (especially when display scaling is not at a whole number haha) but it just kinda feels like searching for something to complain about. If your browser and OS doesn't get in the way you can get exact measurement. This also applies to almost any UI framework that has some integration with the OS.
https://css-tricks.com/inheriting-box-sizing-probably-slight...
flexbox. You can literally recreate any fully responsive desktop style GUI with it. You just need to layout your elements the same way you would in a GUI designer like QtCreator or Glade. Which means thinking in terms of divs with flex-grow set on them to get the automatic container expansion you get with "vertical boxes" or "horizontal boxes". These divs will sometimes be empty if you want a simple "expander" box.
Once you have it down you can look at any desktop GUI and just inherently understand how it maps into this flexbox model.
Spoken like someone that hasn't been handed designs and expected to 'just figure it out' for a living.
CSS isn't powerful enough by itself to create any layout you want without modifying the HTML. You almost always need wrapper elements to group elements you want to align together for presentation purposes only (e.g. "a vertically centered row containing one paragraph next to two vertically stacked images"), so there often aren't semantic HTML tags that would make sense.
It's similar to how you use numerous groups/frames in design apps like Inkscape and Figma to help align elements, where nobody would suggest you were a bad designer for using groups that don't have semantic meaning.
You can only really avoid wrapper elements for simple Markdown style pages with simple designs, where the CSS for that is straightforward.
I think in these discussions, it needs to be clearer how complex the page designs being discussed are. The CSS advice that makes sense for simple Markdown style pages is very different to what makes sense for a complex web app UI or a highly designed marketing page.
I'd argue that a lot of times those groupings are meaningful.
I agree with the approach you are suggesting, but the reason I find these wrappers pop up: it's VERY hard to make components composable without them.
Let's say you want to have a block that adds spacing between each item within it. Easy: it's flexbox with a gap. Oh no, but a child is displayed inline, and has weird vertical alignment. And another child has an unexpected align-self. Now you get wrappers on the children.
Maybe you want a button. It's got an icon with text. You need a wrapper on the text, because without a wrapper you basically can't get anything right (you can't rather bare text with CSS).
How about a checkbox? Should be easy. You want the component to have the checkbox on the left with the text on the right. You want to allow two rows of text, with the first being in bold (the label) and the second row being a description or help text. You wrap the whole thing in a label element because you care about accessibility. But you need a dummy div to render the checkbox, because you can't reasonably style checkboxes. And each row of text needs a wrapper, because bare text. And maybe another wrapper around the two rows, because while you can use CSS grid to position the two rows above each other, lord only knows what the checkbox is inside of and whether it's flexbox or grid, and the height of the label might be weird and jack up the positioning of your text. God help you if any of the rows have text that doesn't wrap and is wider than the width of the checkbox's container.
The unfortunate truth is that you probably don't need the wrappers, but there's an element of defensive coding that just makes it infinitely easier to get things right all the time with wrappers.
I view nesting as a footgun. I recommend trying to restrain all CSS to one selector, and to instead view additional qualifiers as an escape hatch where needed. Death to specificity.
However, no one will admit this because:
. many people don't know them (the techs) well enough because they're so abstruse. Some people would argue this a necessary feature.
. many people only know them and so can't compare them to something else
. people that do understand them typically have financial or ego reasons to look the other way
. people that do understand them AND are rich and happy are afraid of all the other ppl in this list.
Generalization: any widely use tech must be extremely complex or extremely simple (eg TCP).