Intro to The 8-Point Grid System (2016) | Hacker News Reader

Intro to The 8-Point Grid System (2016)

builttoadapt.io

66 pointsafrcnc20 comments

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.

Luckily, it's easy to deviate, but just sharing my experience. :)

I agree but to add to this: Deviation from a system is not the same as not using a system. The former is as you said much easier and it is in a sense consistent as well.

Why does this article use "points" instead of "pixels"?

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?

It would make more sense if it used em’s when focussing on the web. I’m not the author but maybe the author has a background in print (and used illustrator to work this out with the default metric in points...)

em's are container font size dependent, for consistent grid one should use rem's.

Points are used as a measurement to simplify designing for high resolution displays. A standard resolution display has a 1:1 pixel density, 1 pixel is equal to 1 point. High resolution displays have a higher pixel density where a scale factor of 2.0 or 3.0 is used (iPhones in this case).

Not entirely sure if the article is aimed at a web audience, but if it is, this would be an awkward justification because the unit "pixel" in CSS is normalized w.r.t DPI.

In browsers yes for the most parts but not with images (like high dpi images needs to be specifically named and sized) but for example in android development the standard unit is dp aka. density-independent points and for ios development the unit is also points which is relative to the dpi used.

Ok, but what does 16pt (in the article) mean? I can't tell if it refers to an amount of pixels or an amount of mm.

In the first case the amount of mm would be different for each display. In the second case the amount of pixels would be different for each display.

Perhaps this quote from the article provides a hint:

> Ok, I get the even number thing, but seriously, why not 6, or 10? The majority of popular screen sizes are divisible by 8 which makes for an easy fit.

From this I'd say it is about pixels. But why call it "pt" then? And yes, how does this give useful results on high resolution displays?

I think the article is really confusing.

16 pt = 16 * ~0.353 mm = 5.644 mm

https://en.wikipedia.org/wiki/Point_(typography)

You missed the point/pt ;)

The point is that the author says that the screen size in pixels should be an integer multiple of 8pt, which doesn't make sense.

A point is a classical typographic unit [1]:

In typography, the point is the smallest unit of measure. It is used for measuring font size, leading, and other items on a printed page. The size of the point has varied throughout the history of printing. Since the 18th century, the point's size has varied from 0.18 to 0.4 millimeters. Following the advent of desktop publishing in the 1980s and 1990s, digital printing has largely supplanted the letterpress printing and has established the DTP point (DeskTop Publishing point) as the de facto standard. The DTP point is defined as 1⁄72 of an international inch (about 0.353 mm)

So if you have a 72 dpi monitor, then as it happens, a point is a pixel.

[1] https://en.wikipedia.org/wiki/Point_(typography)

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.

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.

Yeah, you can calculate the vertical rhythm, but it can be a bit of pain if you can't rely on CSS4 vars or preprocessing (SASS/LESS/PostCSS and such).

Still, nowadays this is much easier than even 3-4 years ago.

    /* _variables.css */

    --font-size: 12px;
    --ru: 1.5;


    /* _typography.css */

    p {
        font-size: 2rem;
        line-height: calc(var(--ru) * 2rem);
        margin: calc(var(--ru) * 1rem) 0;

        &.small {
            font-size: 1.5rem;
            line-height: calc(var(--ru) * 1rem);
        }
    }

nice! thanks for sharing :)

> The majority of popular screen sizes are divisible by 8

Uh, divisible by 8 pixels, not 8 points. 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 inline-block elements of differing heights within the same inline reflow (e.g. text paragraph.)

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) without somehow breaking the grid.

Picture, for example:

> You’re invited to [test-drive our new Beta]!

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

Before grid systems, this used to be a pretty classic appearance for a call-to-action!

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:

1. the text inside the button is baseline-aligned with the text beside the button;

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;

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

4. the paragraph doesn’t awkwardly have a different line-height than the other paragraphs on the page;

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);

...but I have no idea how to achieve these properties together on a grid.

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.

It's nothing new. CSS has these properties for a reason.

Clearly you haven't worked with corporate design departments. The last mock I saw from one particular company had every single font size ranging from 10px to 20px until we worked through it. The spacing was even more lackluster. I think this mostly stems from similar issues as spaghetti code often does — unreasonable deadlines, multiple teams sprung into action in parallel with little to no coordination and so on.

Usually people claim to know how these things "should" be done, but there's always a "but".

Reply on news.ycombinator.com