4 ms·

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

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>.

ollerac 5y ago
I ran into so many issues with content-box a decade back I never thought about it again and always defaulted to border-box. I think it's absurd that I can set a div to a specific width (100px, 200px, whatever) and the padding or border will make the div larger than that width. It makes it so hard to think about designing a page when you have to continuously add together padding, margin, and border with the width to get the actual width. You're right about flexbox and grid solving most of these issues -- and responsive design has pretty much done away with using exact pixel widths for anything, but I still run into some cases (especially around creating grid layouts that automatically reflow) where CSS columns and floats are the best approach (not often, but it still happens...) and then you need to rely on the width being the actual width, you know?
- chrismorgan 5y ago
  I’ll try framing and explaining it a slightly different way: It’s about the difference between layout and content concerns. Margin and padding should generally be layout concerns. Explicitly-set width and height should generally be content concerns. This means it should exclude margin and padding, so content-box is the most appropriate model. Before flexbox came along, it was necessary to use width and height for layout concerns quite extensively, which is why people started recommending border-box. But now, the root elements are pretty much the only places that may (or should) use width and height for layout concerns. So I say specify border-box for them if you need, but leave it at content-box everywhere else. Just like gap (flex/grid/column) isn’t part of width or height—it’s a layout rather than content concern. I’m saying that you’re thinking the wrong way: don’t try to squeeze your content into the layout, but define your content first of all and let the layout exist around it.
  - rp1 5y ago
    Why should width and height be content concerns? Typically the measured width and height are the most important pieces of information needed by a layout engine.
  - visarga 5y ago
    Maybe height should be a content concern, but width? who makes websites expand horizontally in a content driven way?

ollerac 5y ago

I ran into so many issues with content-box a decade back I never thought about it again and always defaulted to border-box. I think it's absurd that I can set a div to a specific width (100px, 200px, whatever) and the padding or border will make the div larger than that width. It makes it so hard to think about designing a page when you have to continuously add together padding, margin, and border with the width to get the actual width. You're right about flexbox and grid solving most of these issues -- and responsive design has pretty much done away with using exact pixel widths for anything, but I still run into some cases (especially around creating grid layouts that automatically reflow) where CSS columns and floats are the best approach (not often, but it still happens...) and then you need to rely on the width being the actual width, you know?

chrismorgan 5y ago
I’ll try framing and explaining it a slightly different way: It’s about the difference between layout and content concerns. Margin and padding should generally be layout concerns. Explicitly-set width and height should generally be content concerns. This means it should exclude margin and padding, so content-box is the most appropriate model. Before flexbox came along, it was necessary to use width and height for layout concerns quite extensively, which is why people started recommending border-box. But now, the root elements are pretty much the only places that may (or should) use width and height for layout concerns. So I say specify border-box for them if you need, but leave it at content-box everywhere else. Just like gap (flex/grid/column) isn’t part of width or height—it’s a layout rather than content concern. I’m saying that you’re thinking the wrong way: don’t try to squeeze your content into the layout, but define your content first of all and let the layout exist around it.
- rp1 5y ago
  Why should width and height be content concerns? Typically the measured width and height are the most important pieces of information needed by a layout engine.
- visarga 5y ago
  Maybe height should be a content concern, but width? who makes websites expand horizontally in a content driven way?