Advanced options

[janwirth]

In my personal experience, there are two options to a typographic set I adjust almost everytime, that are not included here yet.

• letter-spacing
• transformation (uppercase)

Looking forward to any comments & thoughts on this.

[corysimmons]

Can you tell me more about how you use it?

To be completely honest, I rarely use my own tools for anything (I've been stuck in legacy code for much of my career).

I'd love to hear your thoughts on how we can improve this for the PostCSS version.

[corysimmons]

@FranzSkuffka ping. Teach me your ways. :P

[janwirth]

I did not forget you :* got this in my wunderlist.

Currently busy with a paper
The deadline is next week so I will give you a more detailed documentation of my ways afterwards if that's not messing up your schedule.

What I can say for now is that I have used typographic in two live projects successfully:

http://ufo-eberbach.de/
http://nos-seminare.de/

The latter uses uppercase type for h2 tags and I adjusted the letter-spacing to .2em with the purpose to let these letters breathe a little.

I want to thank you for this awesome tool! I actually am practicing design through code in an efficient way (the second site took me 7 hours with no framework code) and typographic is essential for this.
I have zero experience with writing postCSS plugins but I would love to contribute to postcss-typographic

The current draft of my paper is very drafty but you're more than welcome to take a look!

[corysimmons]

Wow your sites look great! I'm glad typographic helped you.

I was never a fan of my implementation of vertical rhythm so I never really used typographic after I made it. It's a lot of bullshit guess/check math. I'm going to completely revisit the technique behind our vertical rhythm with the rewrite. Once I have that, I'll tweak the settings a billion times in real world usage until it's as smooth as butter.

The next version should be bulletproof and awesome. I'll actually use the next version.

I see what you're saying about the uppercase/letter-spacing thing (I did it on http://stylus-lang.com) but I'm not aware of any mathematical principle on which to space letters out. I always just do it til it kinda looks right. Lemme know if you know of a formula and I'll see about adding it to the next version.

I wish I went to college for CSS. :D

Looks kinda fun.

[janwirth]

Pretty sure the spacing is, like for line-height font-specific and thus not solvable through a formula if you do not add metadata to the fonts. I was hoping to set a variable and then use a mixin provided.
Apar from that, I think some more granularity in the settings (e.g. the actual factor for the modular scale of each typographic entity) instead of imperative programming through mixins would help alot too.

I was kind of skeptic about your vertical-rhythm implementation but it still worked out :)

Thanks for the comments on design! If you add enough whitespace, I reckon, everything starts looking smooth.
Back in the days I was rather art / design-oriented but then fell in love with coding :D while dropping the designer's attitude towards coding with my design routines alltogether. BTW the logos are mine too. I just suck at colors, that's why I use colorhunt. :)

[janwirth]

BTW standard CSS looks interesting. That badge idea really caught me :D:D Are you planning to incorporate SUIT / Title CSS or ? Or is it just a styleguide?

[corysimmons]

Yeah I'm gonna redo the modular scale. I think I screwed that up too. =)

In fact, I screwed this whole thing up. The next version will actually be correct. 👍

It will just be a styleguide/linter but we can't implement it until stylelint gets some functional editor plugins. Who knows how long that will take? Months? Years?

[janwirth]

Let me know when you are starting on postcss-typographic. Have you decided on the JS flavor yet? (please say coffeescript :D)

[corysimmons]

Re: letter-spacing

Forgot we're having a convo about it over here: #43

[corysimmons]

How do you expect text-transform to work?

How could Typographic make it simpler than:

h6 {
  text-transform: uppercase;
}

?

[janwirth]

When applying this transformation, I also want it to respect a variable which is, let's say $uppercase-tracking. Then we could use t-uppercase(). However this can be considered an over-optimisation. Might be viable part of a full-blown typographic toolkit.

whereas letter-spacing = (tracking * 0.001)em so that a tracking of 100 translates to 0.1em

[corysimmons]

Hm. All this letter spacing stuff makes me worry it might be font-specific?

[janwirth]

FranzSkuffka commented 3 days ago

Pretty sure the spacing is, like for line-height font-specific and thus not solvable through a formula if you do not add metadata to the fonts.

yes.

I think there are no CSS hacks in place for finding out which font is actually used by the browser. Which means adding metadata is pretty useless. It follows that setting letter-spacing or tracking is up to the developer leveraging this library. He needs to decide which values are most suitable for his font stack.
Or we could write a helper that detects the fonts used and assigns classes to the body according to the results 😄 BTW I think all the stuff typographic does is font-specific.

[corysimmons]

I don't think we can write a reliable font family fetcher in anything other than JS.

Even if we fetched font families with PostCSS in a clever way, we wouldn't know what font the end user was getting in the stack. Like, letter-spacing might be different for Georgia and serif.

That said, there is such a unit as an ex unit which gets the x-height of a font. Maybe we should operate with that instead so everything typographic does is font specific.

http://codepen.io/corysimmons/pen/YwgqrZ?editors=1100

[janwirth]

I had to test this out for myself.

http://codepen.io/franzskuffka/pen/gPErev

You, sir, are completely right. I am pretty sure using x-height is the right way to go.

[corysimmons]

It kinda makes you wonder why anyone would ever use anything other than x-height for any sizing (since all sizing is "supposed to be based on content")...

[janwirth]

It kinda makes you wonder why anyone would ever use anything other than x-height for any sizing (since all sizing is "supposed to be based on content")...

indeed

[corysimmons]

This whole thing made me realize something though... Hang on a sec..

[janwirth]

Wrong meme

to some extent at least.

[corysimmons]

We're stupid. 1em == 2ex.

[janwirth]

I disagree. If you look at my pen:
http://codepen.io/franzskuffka/pen/gPErev

You can observe, that while em is constant for every font, ex is actually different. 1em is roughly 2 ext, but not exactly.

[corysimmons]

@FranzSkuffka I can't figure it out. I'm drunk and I hate Jade

[corysimmons]

Anyway, 1em !== 2ex, but it's pretty close.

1em is actually probably better to scale off of because it's the size of a uppercase char whereas 2ex is just the size of the x-height * 2.

http://codepen.io/corysimmons/pen/wMOzOe?editors=1100

[janwirth]

All that matters are the red boxes. You observe see that the ex-positioned boxes are shifted in relation to each other whereas the em-positioned are not. Follows that ex is actually different per font and em is not.

[corysimmons]

Ah I see what you're saying.

So 1em just === 16px?! It doesn't === the height of an uppercase character of the font?!?! The scandal!

[janwirth]

Yes exactly. It's just a reference to the parent element's font size basically.

[janwirth]

Welcome to teh webz.

[janwirth]

BTW that's exactly what I imagine my future as frontend engineer. monday, 6AM, drunk, lurking github 👍

[corysimmons]

...the em unit has a long-standing tradition in typography where it has been used to measure horizontal widths. For example, the long dash often found in American texts (--) is known as "em-dash" since it historically has had the same width as the letter "M". Its narrower cousin (-), often found in European texts is similarly referred to as "en-dash".

The meaning of "em" has changed over the years. Not all fonts have the letter "M" in them (for example Chinese), but all fonts have a height. The term has therefore come to mean the height of the font - not the width of the letter "M".

https://www.w3.org/WAI/GL/css2em.htm

[corysimmons]

BTW that's exactly what I imagine my future as frontend engineer. monday, 6AM, drunk, lurking github

Ah crap it's 6am and I'm drunk lurking github... wtf is wrong with me? I think yesterday was Valentines day or something too..

[janwirth]

Nothing. people suck

[janwirth]

Yeah I figured just because somewhere someone wrote something nice about typography I doesn't mean the browser devs adhere to it.

[corysimmons]

Nothing. people suck

100% agree.

I still think we're stupid about this 1em !== 2ex thing. 1em === the height of an uppercase letter. 2ex === the height of 2 * the x-height.

[corysimmons]

In fact, I think if we don't change anything, html { font-size: 16px; } is the browser default, and 1em === whatever font size it inherits right? So 1em === 16px.

[corysimmons]

Whereas 2ex could be anything just depending on where the x-height was (could be any random place depending on just how screwy the font in question is).

[corysimmons]

So I think em's are probably the best thing to size off of.

And to that point, 1rem === html default font size (which is usually 16px). So rather than getting font sizes unset with em's inheritance crap-assery, we can scale in rems for true ultimate power.

http://codepen.io/corysimmons/pen/obVxJW?editors=1100 (vertical rhythm in like 3 drunk hours or 10 sober minutes)

[janwirth]

I honestly have no idea what 1em really is. Not the height of an uppercase letter though. I think they have nothing to do with anything. ex seems legit though
http://codepen.io/franzskuffka/pen/mVoOeR
Yet still, neither rem nor em are font specific which is why ex seems to be the better choice for optimal results here. And I never had problems with em-crap-assery using this librayr

[janwirth]

I gotta write this paper now though. I shalt replace my presence with another German.
https://www.youtube.com/watch?v=j1FwlQhFLQQ

[corysimmons]

Nevermind, I think you're right.

1em doesn't have crap to do with the font face. It just grabs whatever font size it can inherit and applies that. So if html { font-size: 16px; } and body { font-size: 1em; } then body font-size === 16px.

The interesting part is that font-size 16px doesn't mean anything. The 16px doesn't mean the height of the tallest glyph, or the width of the widest glyph, or anything useful or meaningful. It just means "Meh. 16px'ish. Who knows?"

I've been googling for a while now and no one (not even the w3c) will straight up say wtf the size in font-size means.

In fact, w3cschools has no idea, MDN has no idea (and flat out gets some stuff wrong), and w3c doesn't specify so I'm assuming they have no idea.

Yay.

The upside is there is something called aspect size or something which is x-height / font size or something like that. Might be able to do something with that...

https://drafts.csswg.org/css-fonts-3/#propdef-font-size

Nevermind, can't use font-adjust because browser support and can't even calc because calc(1ex / 1em) breaks.

[janwirth]

Yeah font-size is something bounding-box-ish.

And I just figured that ex behaves just like rem. So no calculation PITA.
http://codepen.io/franzskuffka/pen/adMpWw

1ex is roughly 1em/3.6 for Arial. This means that all we have to do is give the html the font size we want and add 3.6ex to the body. However this makes the typography sensitive to differences in x-height between font sizes. The font stacks should be adjusted accordingly. If the difference is to big, we could still detect that with a polyfill and adjust the ex value on the body accordingly.

[corysimmons]

However this makes the typography sensitive to differences in x-height between font sizes

That's a huge gotcha and I don't want to make this reliant on a polyfill or anything.

[janwirth]

This could be optional. In addition to that, fonts of similar character have almost identical x-height. The font stacks in place should be fairly consistent.

[corysimmons]

I'd rather not for this next version anyway. Adding things like that leads down a dark and complicated path for very little payoff.

[janwirth]

okay 😢

[corysimmons]

I'll definitely work on some nice tracking stuff tho (probably with ch units).

[janwirth]

Bonus:

In computing, one use of x-height is as a unit of measurement in web pages. In CSS and LaTeX the x-height is called an ex. The use of ex in dimensioning objects, however, is less stable than use of the em across browsers. Internet Explorer, for example, dimensions ex at exactly one half of em, whereas Mozilla Firefox dimensions ex closer to the actual x-height of the font, rounded relative to the font's current pixel height. Thus, the exact ratio of ex to em can also vary by font size within a browser if the determined values are rounded to the nearest whole unit. For example, a browser calculating an x-height of 45% on a font 10 pixels tall may round ex to either 4 pixels or 5 pixels or leave it at 4.5 pixels.

https://en.wikipedia.org/wiki/X-height#Use_in_web_design

[corysimmons]

Internet Explorer, for example, dimensions ex at exactly one half of em

I wish I was on the IE team. You could just sit around all day and goof off. "Eh, 1/2 an em is close enough."

[janwirth]

I wish I was on the IE team. You could just sit around all day and goof off. "Eh, 1/2 an em is close enough."

kek

They are not even trying.

[corysimmons]

I really have no idea why anyone specifically develops for it anymore. They obviously don't care so why do we?

[janwirth]

I really have no idea why anyone specifically develops for it anymore.

$$$

makes sense for e-commerce and such. I read the following somewhere:

It's silly. I'm sure people on those older browsers either don't have the means or aren't tech savvy enough to upgrade their browser.

As long as they're tech savvy enough to spend money, it makes economic sense.

[corysimmons]

touche