Site measures - Does a em grid makes sense?

Hello all,

On my css layouts, I tend to use em for font size and px for all the rest.
However, I wish not to follow this path any longer, since I wish to embrace the em for [almost] all the development.

Problem: we use a 960px grid for styling most of our pages, so the margin or paddings and widths are given on px, and if we convert those, sometimes, we will get weird stuff like: 0.345 em.

Question: Will it make sense to create a grid based on .em ?

The point is to allow us to start drawing more user friendly measures like .5em or .4em and avoid .453 em stuff.

What do you think ?

Note: This is just a question, if it does make sense to you, just tell me and explain me why so that I could understand and I can leave with that. :wink:

K. Regards,
Oikram

em makes sense for some features more than others. The biggest problem with making a grid system that is entirely based on ems is that as the font size grows and shrinks, so does the overall size of the grid – on the one hand, that gives a good ‘zoom’ like feature where the whole grid is kept in proportion with the text, which should lead to a good balance – but on the other hand, it can quickly lead to a grid that doesn’t fit the page, and breaks out into a horizontal scrollbar, which is something to try to avoid at all costs.

I would generally use ems to size small objects such as boxouts/pullquotes, sidebars, menus etc, where you want to try to keep the object in proportion with the text therein – but I wouldn’t use it for macro-dimensions such as the whole page width, for the reasons I’ve given above. But then again, I have never come across a situation where I would even contemplate using a grid system.

Thanks a lot Steve D.

I wished to understand if making a em grid will be of such a horror idea or if, well, on certain circumstances, we would like to have one.

As for the horizontal scroll issue, perhaps we can define a max-width property so that, the width can’t go wider then a certain value but still allow the font resize according to user preferences at some extension ?

What do you think ?

Regards,
Oikram

That’s a good way of designing the site in general terms, but I’m not sure how it would work with a grid system…

A grid system is a proportional ratio anyway, all these “XXpx” are really restrictive simplifications created for(and perhaps by) people who dont wanna do the math.

It might also help to keep in mind that where your measurements come from and how they affect your target. when you set an element’s size in ems… it is scaled proportionally to the size of the text it contains ( literally). This is what makes an em grid really complicated, because you can inadvertently make it too small or too big for its PARENT… which is NOT affected by the font size of its children. This also means that either you are really disciplined with your content text-size and hierarchy OR you rely on wrapping all actual content in an extra element (each) so that you can control the text size w/o affecting the layout.

And that’s the reason why you don’t see many if any em based grids.

@dresden_phoenix

rem is on is way to solve those issues I believe. :slight_smile:

@All:

In the meanwhile I’m still not getting this:

Sorry for not saying this earlier. I’m not taking into consideration handled devices nor netbooks and mobiles.
Only pc and laptop monitors.
I understand that this only is… weird. Anyway.

a) The layout is planned for a given minimal resolution (1024), centered.
b) If the user has a very wide screen and very hight resolution the layout should not stretch to much.
c) If the user has a low resolution and a 14’’ monitor the layout should not present and absurd horizontal scroll.
d) The layout should keep (the best we can) their proportions.

For d) we will use em or % or a mix. Ok.

For c) we can make use of min-width so that it shrinks to (750px) but not more than that.

For b) we would have to make use of max-width - so that, even if the user as very large screen the layout will not stretch to much to the sides.

For a) I don’t see what can we do.

I mean if we have something like:

#container {
margin: 0 auto;
max-width: 1260px;
min-width: 780px;
}

If so, how can I declare those base 60em as stated on a) ?

You can still decalare the width in ems.

e.g.


#container {
margin: 0 auto;
max-width: 1260px;
min-width: 780px;
width:60em;
}

The width will be 60 em unless the layout is greater or smaller than the min and max widths. You could then size the inner elements in percentages which means they keep track with the parent when fonts are resized.

With ems and percentages you will get rounding errors so pixel perfection should not be the goal and therefore allow breathing space in the design.

You should avoid em margins as they will vary for each element depending on the parents font-size and aren’t really much use in a complicated page.

Borders should really be in px for consistency but does mean that you should avoid using them where percentage widths are also involved on the same element.

Hmm… I’ve been told to use two containers … but I don’t understand why, care to have a look:
http://cssdesk.com/a6xaQ

The point would be to use em so that, all layout stays proportional regardless users preferred font size.
Are you suggesting to drop this, and use % for margin and paddings ?

At a first glass, I’m concerned about what is worst:
Having to deal with the compounding difficulties.
Or
Understand how to read something with some width in em and their margin and paddings in % (isn’t this a hard task to have in mind ?);

I’m a little confused about this. Why? I mean, when we define a border in px aren’t we talking about is line height ?
If we have an element what has is width in % it will expand and contract proportionally, and so will his border line, or not ?

That’s incorrect for many reasons.

You have a max width on the body of 60em and then a max-width on the container of 960px. That’s 2 elements with different dimensions. How will they ever match up.

Besides you should avoid setting widths on the body as it causes too many bugs in older browsers and actually throws IE’s zoom feature out of synch which is the reason for doing ems anyway.

You can do it all in one go as I said above:


#container {
margin: 0 auto;
max-width: 1260px;
min-width: 780px;
width:60em;
}

Leave the body alone.

The point would be to use em so that, all layout stays proportional regardless users preferred font size.

We already sorted that with the outer element sized in ems which takes care of font-resizing so now just use percentages for the inner elements and their margins and they will scale up and down with the layout.

If you use em for margins then the margin will vary for each element depending in its font-size. Imagine you wanted a number of elements aligned the same x distance from the left edge and you said.

p{margin-left:10em}
h1{margin-left:10em}

Those elements would not be aligned in the same place and you have to work out some difficult calculations to get them all aligned equally.

You could use em margins on the main div containers assuming that you haven’t changed the font-size of those divs and that they match the font-size of the parent container. And if that is the case then it is exactly the same as using percentage anyway except that the percentage will not accidentally get changed if someone added a font-size to the div in error.

Are you suggesting to drop this, and use % for margin and paddings ?

At a first glass, I’m concerned about what is worst:
Having to deal with the compounding difficulties.
Or
Understand how to read something with some width in em and their margin and paddings in % (isn’t this a hard task to have in mind ?);

If you use percent then you can use percentage padding and margins and width and they can all add up.

However I hate percentage padding as they grow too big and too small in most cases and I usually use pixel padding which you can do by just adding the padding to the inner elements and not the container. (Older IE also has problems with working out what a percentage of an element is when that elements width is also defined as a percentage of something else.)

I’m a little confused about this. Why? I mean, when we define a border in px aren’t we talking about is line height ?
If we have an element what has is width in % it will expand and contract proportionally, and so will his border line, or not ?

Percentage values aren’t allowed for borders and as borders are 99% of the time 1px borders it makes no sense to try and equate that into ems which will likely be rounded up and down by various browsers so some will get 1px and some will get 2px. Where possible apply your borders to the inner elements so that you don’t have to calculate the box model (or in css3 you can use box-sizing to change the box model but support is only modern browsers).

Please have patience. :slight_smile:
I’m trying to understand not to “prove any point”. :slight_smile:

By looking into the layout I have in hands:

  1. I will never need to place side by side (with equal horizontal spaces) a p and a heading.
  2. I will strictly use font-size property to style p, anchors, span (and other text related) but NEVER containers - with one exception: html will have a font-size defined of 100% to take care of em resizing bugs on IE (at least I used to do this regarding that propose some years ago);

By taking this into consideration, one can securely use margins with em’s - since we will not follow on your “issue case”;
Or your issue case was only one of many possible traps ?

By taking this example I have two questions:
http://cssdesk.com/PBbWK

  1. Let’s suppose I would drop the em for margin and padding, what values in % should I place there instead to preserv the same look and feel ?

  2. I’m trying to stress test a little and see the so called compounding effect - but no luck so far. What am I missing? (yes I want to provoke it so that, if it arrives during the development I can deal with it.) :slight_smile:

[QUOTE=oikram;4990125
By taking this example I have two questions:
http://cssdesk.com/PBbWK
[/quote]

That is invalid and you can’t nest p element so there will be no compounding. As long as you are careful and don’t apply the font-size to elements that can be nested then you should be ok.

  1. I’m trying to stress test a little and see the so called compounding effect - but no luck so far. What am I missing? (yes I want to provoke it so that, if it arrives during the development I can deal with it.) :slight_smile:

Well here’s where your method will fall down. At present you have one element across but imagine you had another element floated next to it width an em width to fill the whole gap more or less. If you then resize the text via the browsers a few times both columns will expand but when the container reaches the max-width the columns still continue to expand and will overlap or drop down the page thus breaking the layout.

Here’s an example:


<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<title>Untitled Document</title>
<style>
html {
	background: #ccc;
	font-size: 100%;
}
body { }
#container {
	background: blue;
	width: 60em;
	max-width: 1260px;
	min-width: 780px;
}
#hello,#hello2 {
	background: red;
	width: 24em;
	padding: 2em;
	border: 2px solid;
	float:left;
}
#hello2{float:right}
#child {
	background: green;
	padding-left: 2em;
	padding-right: 2em;
}
/* Until here*/
  #hello p { font-size: .6em; }
#child p { font-size: .85em }
#footer { clear:both }
</style>
</head>

<body>
<div id="container">
		<div id="hello">
				<p>this is a test. :)</p>
				<div id="child">
						<p>And i'm a child Element.</p>
						<p>Will I get bigger</p>
						<p>And bigger?</p>
						<p>And bigger? </p>
						<p>No. So, where is the so called <strong>compounding effect</strong> ?</p>
				</div>
		</div>
		<div id="hello2">
				<p>And i'm a child Element.</p>
				<p>Will I get bigger</p>
				<p>And bigger?</p>
				<p>And bigger? </p>
				<p>No. So, where is the so called <strong>compounding effect</strong> ?</p>
		</div>
		<div id="footer"></div>
</div>
</body>
</html>


If you use my suggestion of using percent:


#hello,#hello2 {
	background: red;
	width: 40%;
	padding: 4%;
	border: 2px solid;
	float:left;
}

Now when you change the text size the columns still expand until the max width is reached but once the max width is reached they do not increase any more and the layout stays intact. (back tomorrow if anyone else want to jump in now :))

I see.

So if we disable max-width the layout will not break but, the user will have a huge horizontal scroll do deal with.

% of the child elements are always related with the parent, not with a root base value - so, if we have a nested of nested of a nested elements, we should be careful to understand what are we talking about when we define the horizontal padding or margin in % - yes ?

For vertical spaces, we will not not use % - we can either use em or px here - yes ?

Even if we adopt the rem measure unit, it seems that it will not solve the break issue that you presented. So rem as nothing to do with this here, the only thing it brings is that, with it, we will avoid the compound difficulties that we may have with both: % and em because they both rely on prior parent dimensions. Is this correct ?

Yes the layout will just keep getting bigger and bigger which is not usually very nice so you need to cap it at some stage.

% of the child elements are always related with the parent, not with a root base value - so, if we have a nested of nested of a nested elements, we should be careful to understand what are we talking about when we define the horizontal padding or margin in % - yes ?

Percentage margins relate to the width of the parent. A 50% left margin pushes the element 50% across the width of its parent.

For vertical spaces, we will not not use % - we can either use em or px here - yes ?

No you can’t use percent for vertical space because vertical margins still refer to the width of the element and are not really of any use. You could use em or px as vertical spacing is never really an issue (unless you are trying for a vertical rhythm and then it gets very complicated).

Even if we adopt the rem measure unit, it seems that it will not solve the break issue that you presented. So rem as nothing to do with this here, the only thing it brings is that, with it, we will avoid the compound difficulties that we may have with both: % and em because they both rely on prior parent dimensions. Is this correct ?

Yes both em and percent will relate to something else and even if you had a div with a percentage margin and then nested that div several times then the margin would get smaller and smaller but in most cases that would be what you wanted. If it was a fixed width margin it wouldn’t fit.

In the end the only benefit of percentage over em is when you want to use max-width and not have the columns break out. In practice that probably isn’t an issue unless the max-width is very small and there was no breathing space for the em elements.

There are some em grids around and one I’ve seen is em-tastic but I’ve no idea if it is any good as I avoid grids like the plague. However it may give you some pointers.

I think you’ll just have to knock up a demo and stress test it with your data to see how it works for you. As per your original question you will have to use odd measurements for em and bear in mind that some browsers will round them earlier than others so always allow breathing space and don’t make edges meet exactly or you will be a few pixels out.

I will start small first.

So here is a em version.
It’s not YET with max and min widths;
It’s not YET with % applied;
(it should have both)

http://cssdesk.com/KrDWX

5 issues / questions:

1)
The margin-top of #header p don’t seems to visually return any effect. Why ?
It’s not inline is it?

2)
the margin top applied to the #footer doesn’t seem to take any visual effect neither. Why?

3)
On the news element - why if we put width: 100% it breaks the container ?

4)
.moreDetail should be always x units up counting the bottom of their parents #news-block-a and #news-block-b

5)
should we use min-height instead of height on those three blocks:
#newsletter-block
#news-block-a
#news-block-b

Please advice, and sorry for all those questions… :confused:
oikram

You don’t seem to have set a margin-top for the p element so I assume you mean the default top margin that some browsers apply (and you shouldn’t rely on). The margin is indeed having and effect and should you add #header p {margin-top:0} you will see what the difference is quite clearly.

The top margin on the p element collapses onto the header element and becomes the margin for the header element itself and moves the whole header element downwards. This is how collapsing margins work. If you added a 1px padding top to #header the margin collapse would stop. The same effect will happen at the bottom edge of a container should the margin poke through and if you want to contain margins within an elements container then add a 1px top and bottom padding (or a border) to stop this.

BTW you should use heading tags for headings anyway :slight_smile:

2)
the margin top applied to the #footer doesn’t seem to take any visual effect neither. Why?

The element above the footer is floated and as floats are removed form the flow the margin top slides under the float all the way back to the containing block so has no effect because the footer is already miles further down the page than the margin you applied due to float clearance.

You need to apply a margin-bottom to the floated elements above instead or float the footer at 100% width and the margin will take effect (but that can be a little risky to float everything).

3)
On the news element - why if we put width: 100% it breaks the container ?

Because you have added padding to the width. Padding + border + width + margins must all fit inside the 100% space.

4)
.moreDetail should be always x units up counting the bottom of their parents #news-block-a and #news-block-b

That’s not a viable plan for a fluid layout. You would need to set position:relative on the parent and then absolutely place the more-details at the bottom of the container. Then you would need some padding-bottom to the container to stop the content above over-writing the more-details. Of course this makes it liable to break on resize although you could set everything in ems.

Best to let the more-details follow normally after the content.

5)

should we use min-height instead of height on those three blocks:
#newsletter-block
#news-block-a
#news-block-b

Please advice, and sorry for all those questions… :confused:
oikram

Avoid heights on containers and let the content dictate the height. If you want equal columns then you could use a min-height to get the initial height but still allow each column to grow if needed although independently. Otherwise you would need to use the display:@table and table-cell properties (ie8+) to create equal table like columns or use a faux column approach with a background image to create the columns.

Ok. Clear.

Is that the way we normally do ?
(asking this for respect to others that my work on this code);

Are you talking HTML 5 ?

How can we tell that padding, border and width and margins fit the 100% space ?

Ok. Despite your explanation you disapprove this option, regarding that:

so, you conclude:

Ok. But if we look into News Block A and News Block B, we will notice that the text height is different.
And the point was to, regardless the text height the “More Details” on News Block A and News Block B should be equally vertical aligned.
But of course, the user that has a font-size bigger, should also benefit from this.

Regarding this, how can I let it follow the content and, at the same time, have them visually v-aligned ?

I will the only reason the other height was there, was only to provide us, a look and feel for what we want to accomplish.

So, with min-height we will gain two things:

  1. It will have the same height initially;
  2. It will grow regarding the user font preferences;

It’s just still not perfect because we will need:
3) It should keep the same equal height AFTER the resize;

In order to accomplish 3) we may:

Not yet unfortunately.

I will leave this for is own post.

Collapsing margins are simply he way that css works so you have to accommodate them into your design in some manner.

There are other methods of un-collapsing margins other than using padding and you could use overflow:hidden on the container assuming you don;t need visible overflow or you could float the container and the margin wouldn’t collapse (or use inline-block or any other element that creates a new block formatting context.)

The easiest method is simply to have a 1px top and bottom padding on the container and all margins will be contained within.

Are you talking HTML 5 ?

I never talk html5 :slight_smile:

I’m talking real html and you should always use the appropriate element for the task in hand and which for headings should be the correct heading tag in a logical progression.

How can we tell that padding, border and width and margins fit the 100% space ?

If you mean how can you make sure that padding margins, border and width fit then you have to be careful how you apply them. Ignoring margins for the time being you could apply the width to an outer element and then add border and padding to the inner element and not affect the overall width.

If you are mixing em, px and percent with padding, borers amd margins on the same element then it becomes very difficult to make it fit exactly.

Ok. Despite your explanation you disapprove this option, regarding that:
so, you conclude:
Ok. But if we look into News Block A and News Block B, we will notice that the text height is different.
And the point was to, regardless the text height the “More Details” on News Block A and News Block B should be equally vertical aligned.
But of course, the user that has a font-size bigger, should also benefit from this.

Regarding this, how can I let it follow the content and, at the same time, have them visually v-aligned ?

This is another case of letting a design dictate the content when it should be the other way around. Although it may be visually pleasing to line things up exactly, it’s just not natural for this to happen on a fluid webpage. The moment you force elements into positions they don’t naturally occupy the more you open yourself to something breaking at a later stage. The main purpose of web page is to provide information and if a visual aspect harms that intent then you need to think seriously whether its a good idea.

Notwithstanding the method I outlined with absolute positioning is about the only way you can do it and will probably stand up quite well if you use em measurement for the protected space (assuming the text in the protected space is at the same font-size as the parent container so that they grow uniformly).

I will the only reason the other height was there, was only to provide us, a look and feel for what we want to accomplish.
So, with min-height we will gain two things:

  1. It will have the same height initially;
  2. It will grow regarding the user font preferences;

It’s just still not perfect because we will need:
3) It should keep the same equal height AFTER the resize;

In order to accomplish 3) we may:
Not yet unfortunately.
I will leave this for is own post.

CSS doesn’t naturally do equal columns (apart form display:table) and why should it? This is another designers choice rather than a content choice and as far as web pages are concerned content is king.

However, there are hacks such as faux columns, and absolute overlays but I’ll leave you to research those :slight_smile:

I’ve read and read (or better re-read). But I unfortunately cannot test all the possibilities here, and we have a lot.

I’ve made some decisions, however, and before I dig in, I wish to read your opinion, before I get myself into such a headache. :nono:

I’ve decided to give display: table; a go, after reading that it doesn’t compromise semantically (despite some screen readers still miss understand that); And also, targeting 13% of the market (on this case) is NOT a concern (yes it’s a considerable but, since it’s not a catastrophe if columns don’t get equal for some users, I would use that technique to avoid troubles when the layout get’s bigger;

By looking into the layout that I have in hands do produce:
http://help.nuvemk.com/css/layout_structure_home.pdf

I would like to ask:
1) We will need three equal height columns techniques here, right ?

[INDENT]1.1) One to equal the two blocks: “Newsletter Subscription” and “News From Sector”
1.2) Another to equal the two blocks INSIDE “news from sector”
1.3) Another to equal the column A (that will contain: “Upcoming trainings” and “Events”) and column B (that will contain “Organizations” and "Social Network stuff);[/INDENT]

Is this precise ?

2) I’m thinking to:

[INDENT]2.1) place the container with a given max-width in em; a width in % (100%); and a min-width in px 580 (why in px here? It’s faster then converting 580px into .em - is this ok? (perhaps I will had overflow:hidden; as well to help contain the floats and make sure that horizontal bar don’t appear);
2.2) All inside blocks will have their margin left and right, padding left and right and width in %;
With 2.1 and 2.2 I get a centered layout with no horizontal scroll bar. (hopefully).
2.3) vertical measures (margin and padding top and bottom) will be in em;
2.4) form widths and height can be defined in em (I see on my older sites that I used px, perhaps due to rounded issues…);[/INDENT]

Does this makes sense, or am I putting myself on a lot of trouble here ? (:

3) Can I use that display:table; technique and still add the border shadows ?

4) Can I use that display:table technique and still have a fluid layout ?

5) More as a note, not sure if it plays a role: I wish use some html5 marktup like header footer section article and aside; (with the proper display:block; declaration for IE7 (yes here I wish to support it because, having those inline even for 13% of the users, it’s to bad); even for 1 is bad. So, at least, I wish to make my efforts to avoid that.

I would love to have someone to actually talk about those matters - sorry for bugging you with so specific questions that interests more myself then the community perhaps… :frowning:

My browser won’t let me visit that link. It says this.

Are you sure its safe?

It could be due to the fact that I’m linking to a pdf file directly or something.
I will convert it to an image and re-upload to the shared host.

Thanks a lot,
mem