Could someone explain this bit of code to me?

[jjshell]

Hello,

Taken from html5boilerplate:

62./**
063. * Font normalization inspired by YUI Library's fonts.css: developer.yahoo.com/yui/
064. */
065. 
066.body { font:13px/1.231 sans-serif; *font-size:small; } /* Hack retained to preserve specificity */
067.select, input, textarea, button { font:99% sans-serif; }
068. 
069./* Normalize monospace sizing:
070.   en.wikipedia.org/wiki/MediaWiki_talk:Common.css/Archive_11#Teletype_style_fix_for_Chrome */
071.pre, code, kbd, samp { font-family: monospace, sans-serif; }
072. 

What does it do? What is font normalizatinon? What are the issues if you don’t have that in your .css?

Regards,

-jj.

[PaulOB]

Hi

body { font:13px/1.231 sans-serif; *font-size:small; } 

That sets all browsers to have a base font size of 13px and a line height of 1.231 rather than the various defaults that they all have.

The “*font-size:small” is a hack for IE6 - 8 to set the font-size to “small” which is equivalent to 13px but still allows for the text to be resized via the browser controls (unfortunately IE5 is one size out and will get the wrong size with that)

The following code does the same for form elements which in some versions of IE do not inherit the font size or family.

select, input, textarea, button { font:99% sans-serif; }

The following code makes sure that a monspace font is used for elements that require that look.

pre, code, kbd, samp { font-family: monospace, sans-serif; }

Without the above you are left to the browser defaults which may vary.

However how many times have you used “pre, code, kbd, samp” in your pages? If the answer is none then you should question why you are adding it to every page you use.

[jjshell]

Thanks Paul, again.

@Paul_O_B

However how many times have you used “pre, code, kbd, samp” in your pages? If the answer is none then you should question why you are adding it to every page you use.

True

Now, the other bits of code seem fairly useful to me.

Just a question, I thought default size for fonts was 16px. Why set it to 13px here? It also biases all claculations for relative units (as in fluid layout), doesn’t it?

[dresden_phoenix]

Default font size vary by browser and by user setting. In what many forum experts might consider a bd method, they are forcing the user to have a base font of 13px, no matter what browser or what the user has set it to be.

it does bias relative calculation. the “advantage” ( not the quotes) is that t essentially makes relative calcs not relative and alowus you to trace the size of the font in pxs,

this is I admit , is hand IF you are lining up fonts to background images.

[jjshell]

So you wouldn’t normalize fonts?

Off Topic:

What’s a bd method?

[PaulOB]

@jjshell

So you wouldn’t normalize fonts?

Off Topic:

What’s a bd method?

It’s a typo - I think Ray meant bad

It’s a bad method because it changes the default that the user may have set as their preferred reading size.

If you had left the base size alone (save for body {font-size:100%} to avoid IE scaling bugs) and then just size all your text in ems/percentages then the visitor will see a layout that is scaled to size based on their preferred settings. If they like large text then they get a proportionate large scaled layout.

Once you change the base to 13px then a visitor will see a layout based on a 13px starting point rather than whatever they have set as their default or whatever the browser has set as default.

It’s not as bad as some other methods that set the body to a really small percentage and indeed the 13px still leaves some scope for the page to be scaled up reasonable well and text will also resize in IE because the keyword was used. The bad is that it disregards what users have wanted for their default.

[system]

What is it? A steaming pile of /FAIL/ at accessibility and just more proof that all this HTML 5 bull is a steaming pile of manure tossed together by people who apparently have no business even writing websites in the first place.

“Boilerplate” – you mean half assed framework defeating the point of using CSS, being the antithesis of separation of presentation from content, and combined with HTML 5 setting coding practices BACK a decade or MORE.

Do yourself a favor, forget that malarkey even exists.

Setting px on body – mein gott… WHISKEY TANGO FOXTROT ROMEO CHARLIE!!!

If you need enough proof not to use that garbage – there it is!

[jjshell]

I expected you would make a strong point.

And you convinced me.

Does it also apply to the bit related to inputs?

[brgemborys]

Paul, I have seen a few of your replies on this font sizing topic before. You seem to have a good grasp on this, and I am currently a bit lost. I am currently working with the html5 boilerplate, and once I came to this section, even I was confused. I am used to setting font size: 62.5%. Although from [URL=“http://www.sitepoint.com/forums/showthread.php?565469-Relative-font-sizes&p=3923587#post3923587”]your post you seem to express a desire to use either 75% or 85% instead. Straight up if you were going to replace this exact piece of the boilerplate code for yourself, how would you write it? I’m a bit lost. Any help or clarification would be nice. Thanks in advance.

Would it look like this?
body { margin: 0; font-size: 80%; line-height: 1.231; }

[PaulOB]

@brgemborys

Would it look like this?
body { margin: 0; font-size: 80%; line-height: 1.231; }

The 1.231 is a bit overkill and I would usually go up in units or half units at the least. 1.2 or 1.3 etc (or at a push 1.25, 1.3).

Jason (DS60) is the expert on font-sizing and has some nice examples of how things render on different machines. To be honest it doesn’t matter whether you use 80% or 100% or 62.5% because they still won’t equate to an exact pixel size as that is determined by the browser and user settings. You just define a relationship between the elements on your page and whatever the user has set for their base size will affect how your layout appears - which is what they want. If you set 62.5% because you think it will match a certain pixel size then that is unlikely to be true in many situations.

These days I usually leave the body at 100% and then apply rules to content as required but avoid making the text too small. For line-height I like about 1.4 as I like spaced out lines but you should set what ever you think best for your design but 1.2 is probably a minimum.

Pixel perfection is not a possibility with percentages so you should let go of total control a bit.

[system]

@Paul_O_B

The 1.231 is a bit overkill and I would usually go up in units or half units at the least. 1.2 or 1.3 etc (or at a push 1.25, 1.3).

Whereas I’d be aiming for 1.4 to 1.6, but that’s because I find taller line heights make it easier to read wider lines.

@Paul_O_B

To be honest it doesn’t matter whether you use 80% or 100% or 62.5% because they still won’t equate to an exact pixel size as that is determined by the browser and user settings.

Which is why the “62.5% == 10px” Bull is exactly that, 100% grade A manure shovelled out by people who don’t understand the ENTIRE REASON FOR USING %/EM IN THE FIRST PLACE… that being it is NOT a fixed relationship to PX and instead is based off whatever the end user has set for preferences either in their browser or in the host OS. (in the browsers that actually take the SHOCK time to pay attention to it like Opera and IE)

@Paul_O_B

These days I usually leave the body at 100% and then apply rules to content as required but avoid making the text too small.

I like to set whatever font size is being used for most of the content (my paragraphs) and then base everything else off of that… so that could mean anywhere from 75% to 120% depending on what actual font is in use.

Something I repeatedly point out is that the same font-size does NOT actually render the same if you change the face:

The top half being what 100% will typically give you on 96dpi systems, the lower half being what 120dpi systems (like the workstation I’m on) deliver at 100%. The first two lines of each – times and arial, showing why usually I use 85% for Arial/sans-serif (the extra bit is rounded down at 96dpi to 14px and up at 120dpi to 17px, which is perfect) and 100% for times/serif… and why I HATE Verdana since it’s ridiculously oversized compared to other serif fonts. (making fallbacks end up too big)… I honestly think most people who think verdana is “more legible” probably just need to increase how big they’re trying all the other serif fonts! I mean, it’s bigger than Dejavu Sans or Dejavu Serif, two fonts that ‘in the old days’ were pissed on by font experts for being “too big proportionally to other fonts”.

Just like as I point out on an old test page of mine, %/EM/PT have different default sizes based on the system and browser they are used on:
http://battletech.hopto.org/html_tutorials/fontCompare/template.html

Also notice down towards the bottom of that page the bit about line-heights.

@Paul_O_B

For line-height I like about 1.4 as I like spaced out lines but you should set what ever you think best for your design but 1.2 is probably a minimum.

1.2 is typically (not always) the default – the specification actually suggests a browser default of anywhere from 1.1 to 1.3… (likely explaining why Gecko based browsers like the sweetly retarded cousin of Nyetscape 4 they are seem to roll a d6 to determine line-height)… Again, I prefer a wee bit more so I set it to 1.4 to 1.6, again depending on the face, and where on the page it is… and as I always say, you change the font-size, you change the line-height.

Oh, and some people will tell you skipping adding a metric (px,em,%,pt,etc) will work properly on line-height-- those people have never used large font machines and usually have pages that are broken for me. It’s more BS much akin to the 62.5% malarkey.

@Paul_O_B

Pixel perfection is not a possibility with percentages so you should let go of total control a bit.

It’s NEVER possible in the first place since you can NEVER rely on font engines kerning text to the same widths, having the perfect font you want actually available, etc, etc… It’s why the mere notion of fixed sized (particularly heights, or really narrow widths… or multiple narrow widths as sections across the page) is a miserable /FAIL/ at web design, and a hefty part of what I’ve come to call the “But I can do it in Photoshop” idiocy.

To go hand in hand with the idiocy of drawing a pretty picture in Photoshop before you even have semantic markup and layout done in CSS, and then having the cojones to call one’s-self a “designer” – basically shooting one’s-self in the foot before you even begin the code.

[imaginekitty]

deathshadow60

[brgemborys]

Wow. I can honestly say that I now feel enlightened. So many things make sense to me all of a sudden. Let’s see if I’m getting this right.

To start, my current body copy is 16px, with a 24px line-height. So obviously to make things simpler i should be basing my body around the font size that I am most often using, my paragraph.

Thus I should now set:

body { margin: 0; font-size: 100%; line-height: 150%; } 

Correct?

And yes deathshadow60, I have learned that regardless of the situation, I am not establishing a pixel size of 16px and a line-height of 24px, but rather a relationship stating that no matter how fonts are resized, they will generally appear to use the same ratio. However, for users that don’t define their font am I establishing 16px on average, seeing as 100% = 1em = 16px? Possibly give or take a few exceptions like IE?

@deathshadow60

It’s NEVER possible in the first place since you can NEVER rely on font engines kerning text to the same widths,

This made me think about something in my own code. Would you suggest staying away from settings such as the following? Is it bad practice, or is it still acceptable?

letter-spacing:.05em;

And finally my last realization came when I started thinking about the following sentiment:

@deathshadow60

It’s why the mere notion of fixed sized (particularly heights, or really narrow widths… or multiple narrow widths as sections across the page) is a miserable /FAIL/ at web design, and a hefty part of what I’ve come to call the “But I can do it in Photoshop” idiocy.

I have recently reviewed quite a few articles with regards to responsive design and the like, but given the scale/allotted time span of our current project at work. I determined it would be something to best address at the next phase when we were able to see a more significant use of our website by mobile and tablet users. So I thought I’d put that aside, until now.

I had always worked with fixed widths and even heights, and I was going to continue those ways until this outspoken opinion of yours. By this downplaying of fixed size, are you suggesting that the best route would be to used a fluid grid layout, or are you suggesting another alternative?

What I gathered/guessed from this was that you recommend a fluid layout, and after this conversation on ems, reading this post as well, and rereading [URL=“http://www.alistapart.com/articles/fluidgrids/”]fluid grids, I can finally say that I am beginning to get it. I’ve been able to get from opinionated boilerplate, to px, to ems, to understanding fluid grids all through this conversation. . . And I thank you all very much.

[PaulOB]

@brgemborys

Wow. I can honestly say that I now feel enlightened. So many things make sense to me all of a sudden. Let’s see if I’m getting this right.

To start, my current body copy is 16px, with a 24px line-height. So obviously to make things simpler i should be basing my body around the font size that I am most often using, my paragraph.

Thus I should now set:

body { margin: 0; font-size: 100%; line-height: 150%; } 

Correct?

You are correct that for you it will be 16px and others users will get whatever is their default is which may or may not be 16px but doesn’t really matter. The approach however is correct and will save you fiddling around with multiple rules.

I have to disagree with Jason on the unitless height and I have never seen a real problem with them but more often see more problems with percentages/em (e.g. line-heights far too tall for small text). There may be minor differences under stress testing or extreme situations but unitless line-heights make for a more readable and sensible structure they proved a better mechanism that using percentage line-heights. To be honest most people don’t understand the difference.

Unitless line-heights pass a scaling factor down to their children so if you have text at a smaller size within a context then its line-height will be smaller and more appropriate. When using percentags/em for line height a fixed computed pixel size is handed down to the children so you end up with small text having a large line-height.

Obviously you can avoid this issue by always declaring a suitable line-height when you declare a font-size (as Jason suggests) but in my mind that’s extra code that is for the most part unnecessary. However I know Jason disagrees on this so make your own mind up.

I had always worked with fixed widths and even heights, and I was going to continue those ways until this outspoken opinion of yours. By this downplaying of fixed size, are you suggesting that the best route would be to used a fluid grid layout, or are you suggesting another alternative?

Height is rarely needed for elements that hold text and if you must have elements at a certain height then be sure to ems so that they can scale properly. 99% of the time elements that hold text content should not have height defined

Fixed width sites are easier to design but are not best for all your visitors. A fluid width (min/max) approach is usually the way to go but you need to plan carefully and expect that everything will move to another line. Don’t try to squash menus into one line and always allow room to breathe. There are plenty discussions on the forum about them (as you have found):).

[brgemborys]

Thanks, I should have specified. The only height I have used so far on this particular project is for a “banner” with an image background. I am currently working to create it using as much css as possible and thus having to avoid using an image at all except for as a backup for browsers that do not support CSS3.

I have however used it in the past, but i have learned the error of my ways. I have been working primarily on email design for the past year and half, so it’s nice to finally return to a sane(r) world.

[PaulOB]

@brgemborys

I have been working primarily on email design for the past year and half, so it’s nice to finally return to a sane(r) world.

Uggh - I hate html emails Perhaps you can spread a few email tips around as I’m sure others would be interested.

[brgemborys]

Not a bad idea. Thanks.