Typography

[sfrisk]

Assuming we want to cover typography along with form elements in the first release, the following items need to be considered:

What font do we want to use? Do we want to allow for different fonts, and allow user to choose? Font color?

We need styling (font, font size, line-height, font-weight, etc) for most if not all of the following elements:

• Headers (<h1>, <h2>, <h3>, <h4>, <h5>, <h6>)
• Classes meant to mimic headers, but not semantically mean the header they're mimicking ( For example, a .h1 class to use on an <h2> that someone wants to appear like an <h1>.
• Paragraphs (<p>)
• Inline text elements (<mark>, <del>, <s>, <ins>, <u>, <small>, <strong>, <em>, <b>, <i>)
• Lists (Ordered, Unordered, Definition)
• Block quotes? Addresses?

Also do we want any utility typography classes, for text alignment or text transformation?

[jslegers]

IMO, a good way to start, would be a project that combines the features of Normalize.css and Blueprint. Any HTML5 element should be supported, albeit with a focus on HTML4 elements.

Users should be able to cherrypick which features they want and/or customize them on a per feature basis, using SCSS.

Also, you don't want CSS classes to mimic HTML elements. Instead, define SCSS placeholders to define the behavior of HTML elements and allow any CSS selector to inherit from those placeholders.

EDIT ( @arschmitz ): Moved code sample to gist for better issue readability
https://gist.github.com/arschmitz/e1d217b6659ba2f48025

[arschmitz]

@jslegers I think typography and normalizations are different issues see #7 for normalizations.

[jslegers]

@arschmitz :

Maybe I'm misinterpreting the OP, but it does appear to involve both normalization and customization of HTML4/HTML5 elements, albeit only with respect to those elements that are specific for typography.

[arschmitz]

@jslegers Perhaps Ill let her speak to that i was mostly going of the title, and that we already had a normalization specific issue.

[sfrisk]

I suppose you could argue parts typography falls under normalization, but from the design perspective, there are probably a few different stylistic variations of the above items we'll want to support. For example, inline list elements (specifically those belonging to definition lists), vs block list elements. You'll want different styling for each case, that goes beyond the basic element styling that comes from normalization. Same with utility typography classes, to help deal with text alignment issues for example. Items that would allow potential content managers to format the text in the format they need to, without resorting to inline styling.

If you look at the typography section in bootstrap (http://getbootstrap.com/css/#type), it goes beyond the basic requirements of normalization and deals with more of the design requirements of typography.

[jslegers]

@sfrisk :

I guess the question here is whether you want to Normalize the behavior of HTML elements to behavior very similar to the default behavior of browsers (the Normalize.css way) or whether you want to normalize it to a custom look-and-feel (the Blueprint way).

Both normalize the behavior of HTML elements, but they choose to do it in a different way.

[sfrisk]

I would argue Blueprint example you linked to goes more into styling than basic normalization. Otherwise you wouldn't have classes associated with form elements to indicate what size they should display at, or classes associated with divs to indicate what color to make them.

Also I'm not sure how I feel about their decision to use <br /> to decide if an element should appear inline or not. It has a slight tendency of cluttering up html.

[jslegers]

@sfrisk :

I don't think Blueprint would be a great example to follow from either a graphic design POV or a technical design POV. As a framework pre-dating both Bootstrap and Foundation, it has become a bit dated in both areas.

When I using Blueprint as a reference, I'm using it mostly as an example of which features to offer for a first version (custom normalization for basic HTML elements + a few basic modifiers). Graphic design wise, I'd go for a minimalistic look-and-feel inspired by Github and from a technical point of view, I think OOCSS frameworks are better projects to look at. Here's some examples :

• Nicole Sulivan's original OOCSS project (the one that launched the term "OOCSS")
• Nicole Sulivan's more recent SCSS version (still in development?)
• Harry Roberts's Inuit.css (since v4.0.0)
• Vetrenko Maxim's MarmertKit
• Chris Chambers's basicss
• Florenz Heldermann's Shepherd Framework
• my own Cascade Framework

[sfrisk]

If this topic is going to move in the direction of what is and isn't covered in normalization, then I suggest we move this discussion to the normalization thread rather than here.

[cbracco]

I think I would like to see utility classes for text alignment, heading styles, and more general font sizing.

[cbracco]

Also, I think it is important that we allow users to set variables for base font size, line height, etc. for their projects, with the default being something common/sensible like font-size: 16px; and line-height: 1.5.

[MichaelArestad]

Mind if I take a stab at mocking up some of the typographic elements and base elements?

Also, I know I love my base settings map that looks something like this in atoms/typography/variables.scss as per #29 (comment) (with more or less settings per project):

$root-font:(
    color: #222,
    font-size: 20px,
    line-height: 1.5
);

This makes it pretty easy to change your base settings in one spot.

[sfrisk]

Sure, if you have something in mind, feel free to mock it up.

[MichaelArestad]

Initial mockup: http://codepen.io/MichaelArestad/full/abbe07c15c81010d04473f341dbcc137/

• I chose Source Sans Pro as the primary font. It has a pretty nice variety of weights.
• ul and li still need styling and I haven't done anything with the text-level elements yet.
• I went with a larger base font size of 20px. It's much more pleasant for reading content, but since everything will be defined in em units (hopefully), changing it will be trivial for interfaces that require a smaller base font size.