Font-families
Melindrea opened this issue · 52 comments
Hey,
This is looking mighty fine, but I'm curious on the rationale behind not making the font-family adjustable? I mean, it's easy enough for me to just go with adding the font-family in html in my own sheets, but why allow to adjust if the base family is serif or sans-serif, but not allow to set the base family to whatever font you're using?
Keep up the good work, I'm mainly interested in hearing the why's behind that.
Right now Typeplate compiles to this. Of course I'm up for suggestions to make it better.
html {
font: normal 112.5%/1.65 serif; /* the serif value depends on the boolean passed */
}Deciding the serif vs. sans-serif is there for a fallback. Most authors are gonna change to a custom font anyway so in this case the OS can choose the best displaying font for either cases. Macs will get awesome Helvetica by default. On PC's, even if they have Helvetica it can look worse than Arial for whatever reason, so this way they get Arial by default. And you're still covered by the generic keyword. Shorter, easier, yay.
IE, your expectation is that I in my own scaffolding file redeclare the font-family?
I think I was expecting the !default flag on those too, so that it gets declared immediately in your html, though either way works for me!
So you want something like this?
$font-face: "custom font family goes here";
$font-family: $font-face serif !default;
$font-family-sans: $font-face sans-serif !default;Yeah, pretty much. Or just $font-family: serif !default;, though I can buy the argument to have a sensible default as the final in the list.
I'm a bit confused. We already have this $font-family: serif !default;
though I can buy the argument to have a sensible default as the final in the list.
What do you mean by that? Sorry if I'm slow.
...I'm also very confused. Where?
On line 41-42 of https://github.com/typeplate/typeplate.github.io/blob/master/typeplate/scss/_typeplate.scss#L41 I see the declaration of $font-family as the following:
$font-family: serif;
$font-family-sans: sans-serif;
I just updated to the latest version, using bower.
LOL! ha. Yeah so I guess we only have it on the boolean
$serif-boolean: true !default;=) So, is that something you can fix, and/or want me to give you a PR on?
It doesn't really make sense to have
$font-family: serif !default;
$font-family-sans: sans-serif !default;because we're controlling it with the boolean.
$serif-boolean: false; // overrides !default
$font-family: serif;
$font-family-sans: sans-serif;
$serif-boolean: true !default;We need to rewrite the logic in some way and really figure out what we're actually after here.
Well, what did you have in mind when you wrote it that way?
And huh, that's an interesting way you've declared the font-face on the site (I was examining it to figure out how you solved the issue I was running into). Is that something from typekit, or...?
Well, what did you have in mind when you wrote it that way?
My idea was to allow authors control the serif/sans-serif fallbacks with the boolean.
And huh, that's an interesting way you've declared the font-face on the site (I was examining it to figure out how you solved the issue I was running into). Is that something from typekit, or...?
yeah I dont know how the 'serif' part got into the body font declaration on the site. I'll definitely remove that just so we have the Typekit font declaration.
So, we have typeplate compiling down into the font: normal 112%/1.65 serif; on HTML, and then the author would set either before or after:
html {
font-family: MyCustomFont;
}
Yup exactly. We would have this...
html {
font: normal 112%/1.65 serif;
}
html {
font-family: MyCustomFont;
}or
html {
font: normal 112%/1.65 serif;
}
body {
font-family: MyCustomFont;
}Then my final comment on it will be that you may want to document that somewhere to stop more issues being brought up, since I doubt I'll be the last person wondering about it =)
Once again, very nice job. This is likely to be my go-to alongside Normalizer for starting any project. I credited you on my site as well.
👍 will do. Which site of yours are you using it on? This one? http://mariehogebrandt.se/
I looked at the style sheets and you still have the comments in your CSS due to not removing them from your compiling of Sass.
/* line 404, ../../app/components/typeplate/scss/_typeplate.scss */
pre code {
word-wrap: normal;
}If you're using Compass along Sass just set this line to false in your config.rb
# Enable or disable line comments
line_comments = falseI actually generally minify it with grunt (as part of my build step), but cheated to get it out quicker and just went with the one compiled when I do the frontend with grunt server. It's all fixed now, though =)
cool! you're also on our “In the Wild” Wiki now. Thanks again for the suggestion above. I'll definitely put that in the docs fo sho. 🤘
Oh! PS you gotta keep the comments at the top for copyright when using Typeplate.
/*!
*
.||..||..||..||..||..||..||..||..||..||..||..||..||..||..||..||..||..||..||.
. '|| .
.||. .... ... ... ... .... ... ... || .... .||. ....
|| '|. | ||' || .|...|| ||' || || '' .|| || .|...||
|| '|.| || | || || | || .|' || || ||
'|.' '| ||...' '|...' ||...' .||. '|..'|' '|.' '|...'
.. | || ||
'' '''' '''' A Typographic Starter Kit
URL ........... http://typeplate.com
VERSION ....... 1.1.0
Github ........ https://github.com/typeplate/typeplate.github.io
AUTHORS ....... Dennis Gaebel (@gryghostvisuals) & Zachary Kain (@zakkain)
LICENSE ....... Creative Commmons Attribution 3.0
LICENSE URL ... http://creativecommons.org/licenses/by/3.0
.||..||..||..||..||..||..||..||..||..||..||..||..||..||..||..||..||..||..||.
*
*/Not enough to credit you in http://mariehogebrandt.se/colophon ?
Alright, I'll fix that, though I can't promise I'll be able to get it
done until I get back from vacation, which is end of July. I hope that's
not an issue, I just can't remember off the top of my head how to add a
banner to the CSS using Grunt =)
On 06/29/2013 07:11 PM, Dennis Gaebel wrote:
Oh! PS you gotta keep the comments at the top for copyright when using
Typeplate.—
Reply to this email directly or view it on GitHub
#117 (comment).
Yeah that's fine. Thanks. Appreciate it.
@Melindrea Would you like to become an org contributor? We can add you to the org if you'd like. Thought I would ask seeing as you have given us such great feedback.
I would love to!
Great! You're in! You only have pull access right now. In time we hope to give you push and pull access.
Also, it finally just dawned on me how awesome this bit is, and how it works the best. Very good work.
👍
I came here to suggest this, too. I added those !default flags myself. I expected to be able to set a variable to specify my desired font family. I think the serif flag is unexpected. Why not just have a family var and let us define that instead?
Here's my initial setup:
@import url(http://fonts.googleapis.com/css?family=Lato:300,400);
$font-weight: 300;
$header-font-weight: 300;
$font-family-sans: Lato, sans-serif;
$serif-boolean: false;
@import "typeplate/typeplate";
I would prefer just:
$font-family: Lato, sans-serif;
I also added $header-font-weight to the type scale mixin and set it to bold by default--the user agent was defining it bold by default anyways, but I just wanted to override that in this case.
Part of how to get this to work is to not need to declare the sans-serif backup font. I agree that it should either be renamed or not be a variable, but the idea is that you have $my-font-family: Lato declared and then used wherever you're needing to set the font.
In my experimental branch I've removed the serif/sans-serif boolean in favour of a single font-family variable... I think that's the way to go because it removes confusion and it isn't really necessary, as we've kinda seen in this thread.
Thoughts on just removing it entirely, like Melindrea says? I'm down.
Cool. Yup, I agree about removing it.
If it does get removed we need to understand the following...This can and will break backwards compatibility for those using 1.1.0 even though this is something on a smaller scale. All our decisions need to follow this thought process and understanding. If things are removed we must make it easy for users to find the portion we removed and explain what to do in order to keep their sanity.
@zakkain Can you post what you have so far in this thread?
FFFF- you're right, backwards compat. is a bitch. Though there is an argument that Typeplate is meant for using on a project and extending and making your own, so you wouldn't often drop in the latest because it would break your existing modifications... no?
*Re: experimental version: * I'll post what I have, its just bits and pieces that I'm actually using in a real project right now, and I'm tryin to port it back. here goes
This is vars.scss:
// font stacks
$freight: "freight-sans-pro";
$garamond: "garamond-premier-pro";
$din: "din-condensed-web";
// base typographic styles
$base-font-size: 106.25; // percentage value (16 * 106.25% = 17px) // 19px @ 300 weight is nice too
$base-font-size-px: 16 * ($base-font-size/100); // converts our percentage to a pixel value
$base-line-height: 1.411764706;
$rhythm: $base-line-height * 1em;
$base-font-weight: 300;
$measure: $base-line-height * $base-font-size-px; // converts our line height to a pixel value
$measure-px: $measure#{px};
// typographic system: 17 & 47 @ 2:3 perfect fifth scale (fudged for sharpness)
// http://modularscale.com/scale/?px1=17&px2=47&ra1=1.5&ra2=0
$tera: 86.063;
$giga: 70.5;
$mega: 57.375;
$alpha: 47;
$beta: 38.5;
$gamma: 31.333;
$delta: 22;
$epsilon: 20;
$zeta: 17;
$type-system: tera $tera '',
giga $giga '',
mega $mega '',
alpha $alpha h1,
beta $beta h2,
gamma $gamma h3,
delta $delta h4,
epsilon $epsilon h5,
zeta $zeta h6;
And this is part of typeplate.scss:
@import "vars";
// takes a pixel size and calculates appropriate relative sizing and margin units values
@mixin type-scale($size, $base:$base-font-size-px, $measure:$measure) {
// font-size: $size#{px};
font-size: context-calc($size, $base);
margin-bottom: measure-margin($size, $measure);
@if $size >= $alpha {
padding-bottom: measure-margin($size, $measure);
}
}
// divide a given font-size by base font-size & return a value in relative units
@function context-calc($scale, $base) {
@return ($scale/$base)#{em};
}
// divide 1 unit of measure by a given font-size & return a relative value
@function measure-margin($scale, $measure) {
@return ($measure/$scale)#{em};
}
// generic heading class shared by all titling elements
%hN {
text-rendering: optimizeLegibility;
line-height: 1.1; // to prevent large gaps between lines of wrapping text
margin-top: 0;
font-weight: 300;
}
@each $scale in $type-system {
.#{nth($scale, 1)}, #{nth($scale, 3)} {
@extend %hN;
@include type-scale(nth($scale, 2), $base-font-size-px, $measure);
}
}@zakkain hrmmm... Where's the part we're discussing?
I believe the part in question is this:
$font-family: serif;
$font-family-sans: sans-serif;
$font-properties: $font-weight, $line-height, $font-size, $font-family;
//the serif boolean var can be redeclared from another stylesheet. However
//the var must be placed after your @import "typeplate.scss";
$serif-boolean: true !default;
// $Mixin $Body-Copy
// -------------------------------------//
@mixin base-type($font-weight, $line-height, $font-size, $font-family...) {
@if $serif-boolean {
font: $font-weight #{$font-size}%/#{$line-height} $font-family;
}@else {
font: $font-weight #{$font-size}%/#{$line-height} $font-family-sans;
}
}
// $Styles $Globals
// -------------------------------------//
html {
@include base-type($font-properties...);
}Oh whoops! Sorry it was broken off into a different file in this case. Here we go:
I got rid of that mixin entirely since I removed the font-family boolean:
html {
font: $base-font-weight #{$base-font-size}%/#{$base-line-height} $font-family;
}I threw this right on the html selector, because there's actually no reason to have it as a mixin—you shouldn't be repeating the base-type mixin. Instead, using the other mixins like type-scale I pasted above is making more sense to me right now:
.page-title {
@include type-scale($alpha);
}or more likely just doing this:
.page-title {
@extend .alpha;
}Ok so, obviously this only cool for scenarios where you wanna carpet bomb your entire site copy with a custom font...
// included in the vars file
$custom-font-boolean: true;
$custom-font-family: PacificoRegular;
$base-font-family: Georgia, serif;
// default in typeplate.scss
$base-font-weight: normal !default;
$base-font-family: serif !default;
$base-font-size: 112.5%;
$base-line-height: 1.65;
$custom-font-boolean: false !default;
html {
@if $custom-font-boolean == 'false' {
font: $base-font-weight #{$base-font-size}/#{$base-line-height} $base-font-family;
} @else {
font: $base-font-weight #{$base-font-size}/#{$base-line-height} $custom-font-family, $base-font-family;
}
}Output
html {
font: normal 112.5%/1.65 PacificoRegular, Georgia, serif;
}Personally what I think I'd like to see is to remove the $base-font-family variable altogether. Having an output along the lines of
html {
font: normal 112.5%/1.65 serif;
}
in typeplate, and then leave any other notions of font to the user. That way, keeping the $serif-boolean to be able to set if you're wanting the serif or sans-serif fallback, and the user can set a $base-font-family to their own stack without needing to worry about it.
@Melindrea Yes I agree and this is exactly what the output is right now as we speak. Trying to meet both sides here I guess, but I feel you and I are on the same page. Lets look again at what we actually have right now.
// $Variable $BaseType
// -------------------------------------//
$font-weight: normal !default;
$line-height: 1.65 !default;
$font-size: 112.5 !default; // percentage value (16 * 112.5% = 18px)
$font-base: 16 * ($font-size/100) !default; // converts our percentage to a pixel value
$measure: $font-base * $line-height;
$font-family: serif;
$font-family-sans: sans-serif;
$font-properties: $font-weight, $line-height, $font-size, $font-family;
//the serif boolean var can be redeclared from another stylesheet. However
//the var must be placed after your @import "typeplate.scss";
$serif-boolean: true !default;
// $Mixin $Body-Copy
// -------------------------------------//
@mixin base-type($font-weight, $line-height, $font-size, $font-family...) {
@if $serif-boolean {
font: $font-weight #{$font-size}%/#{$line-height} $font-family;
}@else {
font: $font-weight #{$font-size}%/#{$line-height} $font-family-sans;
}
}
html {
@include base-type($font-properties...);
}Output
html {
font: normal 112.5%/1.65 serif;
}I am missing the value of this:
$font-family: serif;
$font-family-sans: sans-serif;
If it is meant to be the generic/built-in serif/sans default, what's the point of the variable? If it's not meant to be that fallback, then I want to override it. In any case, I see more value in specifying base font family for my whole site and/or a display type face and a text type face.
I also don't get why I would want to have a toggle for serif/sans in this way. Why not just let me set the face myself, and I can put my own fallbacks in it?
I am not a type person, so it's entirely possible I'm missing something..
Ambrose is right—I think there should be a $font-family variable that is
meant to be overrided with the user's base font choice. No switching, no
conditionals.
@ambroselittle
The value of the serif boolean is to set the default for body copy. Some authors use serif and some use sans-serif. This can be overridden in the vars file or from the default project Sass file.
Anyone wanna take a crack with a code example to post? Love to see what other come up with besides myself. I kinda like what I had going here
Also be aware there is a CSS port which doesn't have the luxury of changing things like we can in Sass so they will need a default value for this anyways : \
@grayghostvisuals, thanks. I still am not sure I see the value in being locked into only choosing between the user agent default for serif and sans-serif as opposed to just letting me specify the family (with my own fall backs) as per usual in CSS. (At least, what I am used to, FWIW.)
@ambroselittle Do you have an example to share? I'd like to see what your solution is if you don't mind.
@grayghostvisuals Now that I've looked it over closer, I think I like it, though not quite sure why go with a boolean to use a custom font or not, what do you see that it has an advantage over
// included in the vars file
$base-font-family: PacificoRegular, Georgia, serif;
// default in typeplate.scss
$base-font-weight: normal !default;
$base-font-family: serif !default;
$base-font-size: 112.5%;
$base-line-height: 1.65;
html {
font: $base-font-weight #{$base-font-size}/#{$base-line-height} $base-font-family;
}
Is there something I'm missing?
Sure, here's what I had suggested:
#117 (comment)
@ambroselittle Shit! sorry about that. This thread is getting messy. Totally missed it. Ok so here's my proposal which includes what @ambroselittle had. We're also gonna need to go with a default for the CSS port.
// included in the vars file. showing just for demo purposes atm
$custom-font-boolean: true;
$custom-font-family: PacificoRegular;
$base-font-family: Georgia, serif;
// default in typeplate.scss
$base-font-family: serif !default;
$base-font-weight: normal !default;
$base-font-size: 112.5% !default;
$base-line-height: 1.65 !default;
$custom-font-boolean: false !default;
html {
@if $custom-font-boolean == 'false' {
font: $base-font-weight #{$base-font-size}/#{$base-line-height} $base-font-family;
} @else {
font: $base-font-weight #{$base-font-size}/#{$base-line-height} $custom-font-family, $base-font-family;
}
}Output
html {
font: normal 112.5%/1.65 PacificoRegular, Georgia, serif;
}Default Output for CSS Port Output
html {
font: normal 112.5%/1.65 serif;
}@Melindrea Sorry did not see your comment until I posted. I guess the advantage is allowing this to be declared and separated in its own var over declaring it on one line, but I guess it really doesn't matter huh?
np. that would work for my needs.
@ambroselittle Yeah that's cool, but we have to think of others needs too. More than 1 person uses this so our decisions need to reflect this somehow.
Actually, thinking about it, there is one point where it might not be a bad idea to have that boolean, namely to have one "no-fontface" stack, and then the actual font. Either or works for me in the end, though perhaps change it a touch, code will be further down.
I do like having a base font-weight in there, to cater to fonts that has several weights.
// included in the vars file. showing just for demo purposes atm
$custom-font-family: PacificoRegular;
$base-font-family: Georgia, serif;
// default in typeplate.scss
$base-font-family: serif !default;
$base-font-weight: normal !default;
$base-font-size: 112.5% !default;
$base-line-height: 1.65 !default;
$custom-font-family: false !default;
html {
@if $custom-font-family == 'false' {
font: $base-font-weight #{$base-font-size}/#{$base-line-height} $base-font-family;
} @else {
font: $base-font-weight #{$base-font-size}/#{$base-line-height} $custom-font-family, $base-font-family;
}
}
Rather than declaring a custom font family in one line and a boolean in another, let the custom font family be false by default, and use that as a boolean.
@jhogue Would you mind giving us your input on this for a moment?
Thanks for the include. I was reviewing this yesterday but didn't have much to add. This thread has gone all over the place, and I agree to a point that most designers will use Typeplate as a jumping off point, and need to have as much ability to customize as possible.
I think @Melindrea has it correct in her example. This is a simpler set up with the ability to easily add a layer for a custom font.
I personally, more often than not, use two contrasting typefaces in my designs, so there is always another $alt-font-family variable stack floating around in my code, but I apply it directly to specific elements. For setting a default base font on the HTML, I think this latest approach makes the most sense. Simple, easy to understand what is happening, and easy to customize it to make it my own.
Hope that helps. This is coming from someone who is somewhat cold on the matter. I saw this thread yesterday and was asked to comment today, so this opinion reflects my newness to the issues at the core that started this whole thread in the first place. From what I have read (and I read it all), I think the latest code snippet is the way to go.
We got this one everybody! thanks to @Melindrea