Normalize headings about normalize.css HOT 27 CLOSED

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/

from normalize.css.

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.

from normalize.css.

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/

from normalize.css.

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.

from normalize.css.

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" />

from normalize.css.

@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 :)

from normalize.css.

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/

from normalize.css.

@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.

from normalize.css.

@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.

from normalize.css.

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.

from normalize.css.

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

from normalize.css.

@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/

from normalize.css.

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.

from normalize.css.

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.

from normalize.css.

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

from normalize.css.

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.

from normalize.css.

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

from normalize.css.

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 :)

from normalize.css.

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.

from normalize.css.

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

from normalize.css.

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.

from normalize.css.

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.

from normalize.css.

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.

from normalize.css.

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

from normalize.css.

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.

from normalize.css.

@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.

from normalize.css.

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

from normalize.css.