Snakes In The Ball Pit > Announcements

If you have opinions about typography...

<< < (2/2)

Macho Masc Sangy Savage:
As far as the episode pages go, it doesn't feel like something that will really be noticed, unless you fullscreen your browser window on a large monitor. Even then, the album image is there to balance out the extra white space. The submit page and the merch copy really highlight the changes. On one hand, it really makes the margin on the left look really tight by comparison. On the other hand, neat blocks of text are a hell of a lot easier to read. The FPlus website isn't a place where people will be reading large blocks of text for long periods of time.

I just looked down and saw Radical Anarchy's post all stretched the fuck out in one thin line and was instinctively angry, so my vote is to keep the changes.

Dr. Buttplug:
Does the line spacing and tracking scale with screen size as well? I have two screens to look at it on right now, my cellphone and the low res monitor I use at work. For some reason I can't articulate I feel like it looks better on my cellphone. Feels like the line spacing is off on the monitor maybe? It might just be that the lines are less crisp on this cheapo monitor. I'll have to check it on my nice one when I get home.

Lemon:
Does the line spacing and tracking scale with screen size as well?
Jackal Flapnasty, January 16, 2018, 11:49:53 pm
--- End quote ---

Hmmm, it should, but I just realized that I never explicitly gave those sections a line-height, which means they end up as browser defaults, which could change. I'm gonna play with that variable a bit today.

Dr. Buttplug:
If I remember correctly from typography class however many years ago, line spacing doesn't scale at the same rate as font size. Anyway I got home and took a loot at it on my 4k 27 inch monitor. It is legible but since the art is a static size the it creates this odd gap between the text and the image.

Down10:
I do have strong opinions on CSS and typography, but if I recall correctly, you weren't thrilled to hear them.

...

Still here? Okay!

Since desktop browsers mostly round off sliding unit values to the nearest pixel, you are going to have wild results when applying uncommon units like vw to font sizes, which will reflow the text in unexpected ways. My technique for sites these days is to stick normalize.css at the top (for browser consistancy and to spare some headaches), create a root em unit value for the BODY element, and then assign rem units to font sizes and—well, anything else that calls for a width or height.


/* Initial base font size: 1rem == 1em == 10px */

html { font-size: 62.5%; }
body { font-size: 10px; }
html body { font-size: 1.0rem; }

body {
    font-size: 1.6rem; /* 16px */
    line-height: 1.5; /* 24px */
}

--- End code ---

The above css will scale down 16pt browser default text to 10px, then redefine it as a single rem unit. Now every text element can be size in a metric (aka sensible) way: 1.6rem is 16px, 0.9rem is 9px, etc. The main advantage to rem is that once it's defined, it will behave predictably in nested elements* when scaling the width of the viewport or when zooming in and out with the browser. You can redefine the root em for different media or different screen widths, and not have to redefine the font size every other nested element, as long as you stick to the rem plan.

I would use vw for sizing the dimensions of DIVs and floating blocks, like you've done with the episode blocks, but not for font sizes. Browsers are still not all there yet.

Further reading: https://css-tricks.com/font-sizing-with-rem/, https://css-tricks.com/rem-global-em-local/

* That's the C in CSS, after all

Navigation

[0] Message Index

[*] Previous page