Normalize headings #41

Closed
necolas opened this Issue Sep 14, 2011 · 27 comments

Projects

None yet

10 participants

@necolas
Owner
necolas commented Sep 14, 2011

I'm considering normalizing headings in some way after all. Mainly because I caught myself out while developing a project which used HTML5 elements, because of the way modern Firefox and Chrome resize h1 (coincidently to the size I needed) when nested within sectioning elements...while other browsers do not.

It would be pretty simple, just use the existing defaults and it will override the -webkit-any() / -moz-any() rules and kill off h1 resizing in sectioning elements. But then one might as well normalize all the headings and margins too, I suppose. It's likely that every project is going to modify these styles to match the design.

Thoughts?

h1 {
    font-size: 2em;
    margin: 0.67em 0;
}

h2 {
    font-size: 1.5em;
    margin: 0.83em 0;
}

h3 {
    font-size: 1.17em;
    margin: 1em 0;
}

h4 {
    font-size: 1em;
    margin: 1.33em 0;
}

h5 {
    font-size: 0.83em;
    margin: 1.67em 0;
}

h6 {
    font-size: 0.75em;
    margin: 2.33em 0;
}
@necolas necolas was assigned Sep 14, 2011
@vladocar

If you normalizing the headings then you need to offer complete typography solution for all the other elements. I think heading size shouldn't be a part of Normalize.css.

You can create complete typographical framework based on some scale. Example I used Fibonacci sequence for building http://code.google.com/p/azbuka/ and http://code.google.com/p/better-web-readability-project/

@gosseti
gosseti commented Sep 15, 2011

Agreed. I think the consistency is important, but perhaps it’s still a good idea to include a style that mimics the -webkit/moz-any resizing. I find it a good way to establish typographic hierarchy without switching to a h2.

@necolas
Owner
necolas commented Sep 15, 2011

If you normalizing the headings then you need to offer complete typography solution for all the other elements.

I don't see how one follows the other.

There's no special reason to use the Fibonacci sequence

perhaps it’s still a good idea to include a style that mimics the -webkit/moz-any resizing.

There is no practical way to do this. Nicole's recent article is also worth baring in mind - http://www.stubbornella.org/content/2011/09/06/style-headings-using-html5-sections/

@gosseti
gosseti commented Sep 15, 2011

It depends whether you’re using h1s outside of section elements or not. Fibonacci sequence creates too much size difference in my experience (and is a bit gimmicky). Heading sizes should try to fit the baseline grid where possible.

@i-like-robots

I would also include matching class names (h1, .h1 { * }). Obviously font-size is not always relevant to importance of content which is a common problem when working with some designers who insist each page having 3 headings (yeah, really).

Adding these classes eases the pain on (or helps less experienced) developers so that the markup always maintains content importance even if the design does not. EG. <h1 class="h3" />

@necolas
Owner
necolas commented Sep 15, 2011

@i-like-robots Yeah that is one approach (which Nicole describes) that I see value in when developing a site. But it is not within the scope of normalize.css. People might want to edit the file to include those classes at the same time as they customise the heading styles, but the project isn't going to impose that approach or start including classes :)

@vladocar

Sorry maybe my answer was misleading.I'm not saying you should use Fibonacci. I'm just saying headings size you should make a meaningful scale for other elements. Every designer has its own scale. Here is a good article about that http://www.alistapart.com/articles/more-meaningful-typography/

@necolas
Owner
necolas commented Sep 15, 2011

@vladocar That isn't within the scope of normalize.css, which is to normalize browser defaults. So the styles at the start of the issue are based on modern browser defaults. All other elements do the same.

@vladocar

@necolas I love the idea behind normalize.css. I'm actually working on something that will be mix of normalize.css and my http://www.vcarrer.com/2010/05/css-mini-reset.html ( I will send you all the details when is done ). My general concern with that people will never bother to change the settings inside normalize.css they will simply overwrite everything into another CSS file.

@necolas
Owner
necolas commented Sep 15, 2011

Cool.

If people want to write their CSS on top of normalize.css, that is their choice, even if it is usually unnecessary. It is a pattern that is common among reset users.

@jitendravyas

Almost every project needs different styling for heading so I also use my own styling for font-size, margin and padding for headings

@Keyamoon

@necolas I prefer to write my own font-size classes. It is similar to the font-size: 13px for body which I think you fortunately removed it from normalize.css (still present in h5bp). In my opinion, adding such rules just makes using normalize.css harder as people will have to remove/modify these extras.

By the way, I suggest using the golden ratio for the scales you're using (instead of 2em, 1.5em, etc.). I use modular scale: http://modularscale.com/

@necolas
Owner
necolas commented Sep 16, 2011

Yeah, most people are going to modify the styles (as they might others). But I don't see how it makes it harder for people to change them.

Why would I want to use the "golden ratio"? The browser defaults are not related to it.

@Keyamoon

Well, yea it doesn't exactly make it harder but every time people want to use normalize.css, they will have to either remove these rules or change them. Whereas for most of the other rules in normalize.css, we can just forget about them, knowing they are some good defaults that we want to keep them. I write my css in a modular way and I like to be able to @imoprt and use normalize.css in different projects without changing it each time. So I believe adding heading rules or link colors makes normalize.css less modular. Yeah if you ask me, color rules should not be included either. Generally, adding any rule that most of the people want to change makes normalize.css less modular.

As for why use golden rations, well it's a design best-practice I suppose. Also, not every browser default is the best (that's why we use normalize.css in the first place :P).
Watch this talk by Tim Brown if you haven't already.

@necolas
Owner
necolas commented Sep 16, 2011

If you're setting link/heading styles in every project anyway, surely it doesn't matter if normalize includes defaults that mirror some browser defaults. It's got nothing to do with modularity.

The golden ratio isn't design best-practice, just something that people commonly use because they believe that it is at the root of pleasing proportions in nature and the structures of ancient civilizations. However, there is no evidence that it is. It certainly has no place in normalize.css

@Keyamoon

If I can use normalize.css as is, without changing it, it's considered to be modular, right? If I don't change/remove these defaults that are present in normalize and only override them, I'm adding a few extra bytes to my final css file. If I care about these few bytes (which I personally do), then I have to remove all the styles from normalize that I have overridden in my other files. This means I cannot use normalize without changing it.

@necolas
Owner
necolas commented Sep 16, 2011

It is similar to the font-size: 13px for body which I think you fortunately removed it from normalize.css (still present in h5bp)

It was never part of normalize.

If I don't change/remove these defaults that are present in normalize and only override them, I'm adding a few extra bytes to my final css file.

That's already going to happen for fieldset, lists, etc. I'm not concerned about it at the moment. Doesn't effect modularity

@Keyamoon
That's already going to happen for fieldset, lists, etc.

That's right; except that they are some good defaults that people mostly agree on and rarely change; whereas headings and colors always get changed. In the end, it's a judgment call what to include in normalize. In my opinion, only the styles that rarely get overridden should be included.

I assumed that font-size: 13px was part of normalize because h5bp has it as part of normalize. I didn't know it's a modified version.

But anyway, thanks for the discussion necolas :)

@necolas
Owner
necolas commented Sep 16, 2011

Yeah this is why I didn't include the headings in the first place. But the nesting behaviour in Gecko/WebKit is something that can catch you out. Another option would be to normalize just the h1 font-size, because the other headings aren't affected by the nesting behaviour and it's not really that important/relevant to have every browser rending heading size/spacing in an identical way in the normalization.

@rigelglen

People mostly use their own Header and Font Sizes, and adding them to Normalize would just mean an increase of file size because people have to adapt it to their needs

@peterwilsoncc

My preference is for all to be added, h1 at the very least.

The suggested use case is for end users to edit the file on a per project basis, so including them will alert users there are cross browser differences.

@zzzzBov
zzzzBov commented Sep 26, 2011

I think adding those styles would help normalize the heading elements while still allowing any developer to easily override the behaviors.

Many users will override the default header styling, but for those who don't, the headers should be standardized.

(-moz|-webkit)-any are syntactic sugar which have to be overridden long-form to support other browsers anyway.

@necolas necolas added a commit that closed this issue Nov 4, 2011
@necolas Normalize h1 font-size. Close #41
h1 nested in 'section' and 'article' elements has a smaller
font-size in Firefox, Chrome, and Safari. This introduces browser
consistency.
e9e2874
@necolas necolas closed this in e9e2874 Nov 4, 2011
@csnover
csnover commented Jan 30, 2012

Hey necolas, I imagine you’re probably satisfied with this solution but I also just run into this inconsistency. I don’t know if it is worth revisiting or not; it certainly caught me out, and it seems kind of antithetical to the idea of normalisation to say that it doesn’t matter that headers are not identical everywhere.

@necolas
Owner
necolas commented Jan 30, 2012

@csnover So you don't usually specify your own heading styles when building a site/app?

@zzzzBov
zzzzBov commented Jan 30, 2012

Because it seems people are split on this, I think it would be good to put the basic h1-6 styles in the stylesheet commented out with some text explaining why. Users who want the basic normalization can uncomment it, and users who don't can leave it commented out.

CSS compressors should strip out the comments for production anyway, so it's not like the extra length will be a significant issue.

@csnover
csnover commented Jan 30, 2012

@necolas I do, but if the default sizes in a browser get me to where I want to be, then I don’t change them…except once I get to IE, which has different defaults, and things look bad, and I end up having to go look up what the reference browser defaults are and manually fix it.

@necolas necolas reopened this Jan 30, 2012
@necolas necolas added a commit that closed this issue Jan 31, 2012
@necolas Normalize headings
There are various inconsistencies surrounding headings that make
this change worth trialing. The font-size of headings in IE6/7
isn't relative to the root font-size (see #61). Modern browsers
set the `h1` font-size based on the depth of nesting in certain
HTML5 sectioning elements. This change overcomes both the issues.

At the same time, the margins are being normalized so that they
are consistent and `em`-based. If people need to customise the
heading font-size and margin, they can either edit normalize.css
directly or override later in the source. But at least any non-
customised headings will behave consistently now.

Close #41
1dea394
@necolas necolas closed this in 1dea394 Jan 31, 2012
@necolas
Owner
necolas commented Feb 3, 2012

Thanks everyone. I've added some heading normalizations to avoid some of the issues discussed here and in other issues.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment