I used to be a big fan of the 8-point grid layout, but I think sticking to it too rigidly makes my pages feel too "perfect" and makes it less organic. A little bit of deviation from the grid makes the page more lively and approachable.<p>Luckily, it's easy to deviate, but just sharing my experience. :)
Why does this article use "points" instead of "pixels"?<p>And do font-sizes follow the same pattern as boxes? How tall should a font be in relation to the box it is in? 8pt smaller? 16pt smaller?
Reminds me of the old MCSD certification requirements you had to know: Every margin and standard height of WinForms controls in '95. It was constrained, but gosh it made for a consistent user experience.
In print design it’s very common to have a baseline grid, which is partially related to this. It really does wonders to the readability and giving a feeling of order to the page.<p>On the web it feels like such a pain to really implement something like that with dynamic page width and content. So in most cases i just nudge things and make sure they are nicely aligned where it makes sense.
> The majority of popular screen sizes are divisible by 8<p>Uh, divisible by 8 <i>pixels</i>, not 8 <i>points</i>.
On my screen 8 points is 10.67 pixels, which renders the author's arguments about resolution and odd numbers invalid.
Given that this article is talking about vertical alignment of, among other things, “text” and “buttons”, I was hoping they’d go into how to do proper alignment of <i>inline-block</i> elements of differing heights within the same inline reflow (e.g. text paragraph.)<p>I’ve yet to see a grid system that has guidance—let alone tooling!—for working with paragraphs of text which embed inline-block elements in them of “abnormal” block heights (= larger than the text’s own line-height) <i>without</i> somehow breaking the grid.<p>Picture, for example:<p>> You’re invited to [test-drive our new Beta]!<p>...where the text in brackets is a button, and this button has enough padding/border that it has, relative to the line height, ~1.5em of outer bounding-box height.<p>Before grid systems, this used to be a pretty classic appearance for a call-to-action!<p>I’d expect, if I were writing traditional bespoke CSS and not using a grid, that I could achieve all of the following at once:<p>1. the text inside the button is baseline-aligned with the text <i>beside</i> the button;<p>2. there isn’t too much or too little space between the edges of the button and the surrounding text—i.e. it feels like it’s “part of” the line of text, rather than feeling like the line of text and the button are two cells in a table;<p>3. the line of text that the button is a part of, within the paragraph of text, doesn’t awkwardly have different line-height than the other lines in its paragraph (which is what inline reflow chooses to do by default, unless you give all the lines in the paragraph that same line-height as a minimum.)<p>4. the paragraph doesn’t awkwardly have a different line-height than the other paragraphs on the page;<p>5. the paragraph doesn’t seem to have too much margin on the top/bottom edge compared to its immediate siblings (which usually happens, because line-height in CSS is applied per line, rather than being interspersed between the lines of a paragraph, meaning that it overpads the top line);<p>...but I have no idea how to achieve these properties together on a grid.<p>I feel like this is an important and oft-overlooked consideration, because “CTA button” here can be word-replaced with “emoji” or “highlighted reference to a username/tag” and you’ll end up with the same problems.
Obviously nobody would put random spacing between elements. Usually people just decide that on the whole page the spacing will be X pixels and stick with it.<p>It's nothing new. CSS has these properties for a reason.