I never quite
get the reasoning behind changing box-sizing. My gut feeling is that most places that benefit from switching it to border-box were doing the wrong thing anyway, and that content-box really is the way you
should be thinking—design the layout in terms of the
content where possible, rather than other parts of the layout. To use his own example: `width: 100%`, that
specific value is completely superfluous, just remove the line; and if you were talking about stacking things side-by-side, where historically you would have done things like `width: 50%` or `width: 33.3%` and hope the pixels line up well enough and it doesn’t wrap, then you should use flexbox instead.
Certainly there used to be a couple of major exceptions to my feeling that content-box is a better way of thinking, but this is the main one. Now I can only think of one significant exception: that `html, body { height: 100% }` needs border-box on body if you introduce padding or don’t zero margin, and that if you have an element inside the body that constrains the whole page’s width with max-width and also has margin or padding, same situation.
—⁂—
> The WCAG criteria states that line-height should be at least 1.5.
This is being completely misread. The criterion says that no loss of content or functionality must occur if the user overrides line-height and sets it to at least 1.5. It doesn’t say you should be setting it to at least 1.5—or else it would also say you should be setting letter-spacing to at least 0.12em, which would be awful.
—⁂—
On `-webkit-font-smoothing: antialiased`:
Neither screenshot exhibits subpixel antialiasing. I’m guessing (as a non-user of macOS) based on the appearance that `-webkit-font-smoothing: antialiased` might actually be disabling that thing that macOS misnames “font smoothing” which is actually glyph dilation (about which I have written here on HN before). If it’s doing that, then hey, that could actually be useful for adjusting font grades.
> MacOS is the only operating system to use subpixel-antialiasing, and so this rule has no effect on Windows, Linux, or mobile devices.
This is not true: on Windows, ClearType (enabled by default, I think? but certainly not always) does subpixel antialiasing, and you can definitely choose to go with subpixel antialiasing under Linux. It’s just that those platforms don’t provide a CSS knob to twiddle, perhaps because they saw how much it was abused on macOS.
—⁂—
p, h1, h2, h3, h4, h5, h6 {
overflow-wrap: break-word;
}
Why apply it to paragraphs and headings alone? Would it not be better to just apply it to the root element? Let it cascade, it’s an inherited property. That way also you don’t get anomalous behaviour when you write lists without wrapping each item’s contents in <p>.
Certainly there used to be a couple of major exceptions to my feeling that content-box is a better way of thinking, but this is the main one. Now I can only think of one significant exception: that `html, body { height: 100% }` needs border-box on body if you introduce padding or don’t zero margin, and that if you have an element inside the body that constrains the whole page’s width with max-width and also has margin or padding, same situation.
—⁂—
> The WCAG criteria states that line-height should be at least 1.5.
This is being completely misread. The criterion says that no loss of content or functionality must occur if the user overrides line-height and sets it to at least 1.5. It doesn’t say you should be setting it to at least 1.5—or else it would also say you should be setting letter-spacing to at least 0.12em, which would be awful.
—⁂—
On `-webkit-font-smoothing: antialiased`:
Neither screenshot exhibits subpixel antialiasing. I’m guessing (as a non-user of macOS) based on the appearance that `-webkit-font-smoothing: antialiased` might actually be disabling that thing that macOS misnames “font smoothing” which is actually glyph dilation (about which I have written here on HN before). If it’s doing that, then hey, that could actually be useful for adjusting font grades.
> MacOS is the only operating system to use subpixel-antialiasing, and so this rule has no effect on Windows, Linux, or mobile devices.
This is not true: on Windows, ClearType (enabled by default, I think? but certainly not always) does subpixel antialiasing, and you can definitely choose to go with subpixel antialiasing under Linux. It’s just that those platforms don’t provide a CSS knob to twiddle, perhaps because they saw how much it was abused on macOS.
—⁂—
Why apply it to paragraphs and headings alone? Would it not be better to just apply it to the root element? Let it cascade, it’s an inherited property. That way also you don’t get anomalous behaviour when you write lists without wrapping each item’s contents in <p>.