I think http://www.sitepoint.com/forums/4832810-post15.html is pretty explanatory about what I mean. That’s what happens when using em for fixed heights: broken layout.
For those wondering, this would be IE. And it includes the just-released IE9, a brand new browser.
I use em/% for my boxes as well as my text. It does mean you have to be careful in how you lay things out, though.
As far as I knew ems were used more for liquid layouts rather than pixels.
Hi,
It is great for me to read your various updated approaches.
here is a link for the layout i’m working on.
thought of replacing the px to em of the header and footer-parts heights.
Do you think it can be a good use here?
No.
For the header, it will not break your layout, but you have some fixed height social icons on the same line with some text, and the icons would look out of place next to a possible overgrown em text. Try some 5em font size for #header ul li a.
For the footer, try putting the font-size at 5em for the p elements in it. You do have a partly fixed height on the footer, making it difficult to use em.
The extreme 5em font size only makes more vivid the impact of uncontrolled em sizes on fixed heights.
There are two basic choices for how you want your web page to work.
You can have things resize based on the size of the browser viewport by using %. This is called a fluid layout.
You can have things resize based on what size your text by using em. THis is called an elastic layout.
Most properly designed web sites compromise somewhere between these two depending on what they define using % and what they define using em.
All web layouts can break if your visitor’s settings are outside the range you allow for - it is almost certain it will break if you try to fix any sizes using px and far less likely to break if you use em and/or %.
If a website was designed just using pixels is the process of conversion to % and em’s quite simple…? Is it just a case of calculating and replacing…?
First off, a flexible layout (fluid or elastic) needs two things: min-width, max-width. These two, at the moment, can only be provided in px. No % (since % is unknown), no em (since em is unknown), no pt (since pt is not for display, is for print). And possibly other two: min-height, max-height with the same needs.
Secondly, unless you go with SVG, some graphic layout will only be viable with fixed height: like the post-it, even rotated, as a twist. This too will need px for font, as it will break like this:
where the text is not in visual concordance with the graphics.
Thirdly, based also on the menu in the screencap above, for a horizontal menu having em as size, it’s possible it will not fit on one line or it will overlap another element on the same line that was taken out of the normal flow: the search bit there.
I restate this: px has its use, em/% is not fitted for all jobs. Just because 13px is causing reading problems on some wide screens, don’t blame px, blame 13. Just because IE doesn’t enlarge px text, blame it on IE (and act accordingly) and possibly blame it on 13 again.
You are all right…
Maybe the key is to try to find the middle path… and all your points-of-view help.
noonnope,
About the header,
the designer designed it with small fonts, that many people will find hard to read.
The question is if i prevent them from seeing the other items which are font based, because the icons are not becoming bigger?.. I don’t have a real answer for this.
It seems that it is kind of tradeoff between keeping the proportions and letting as much as possible information be accessible.
and also giving the fact that in non-ies it can be configured to be disproportionate w/o using ems…
about the footer,
this is why i wanted to use ems for the divs height…
it is not perfect, but gives a wider range of font sizes than px.
felgall,
I would realy want to use more %,
but it seems that designers tend to prefer fixed width. to prevent too long text rows etc.
min/max width might be useful here.
do you use % without min/max widths?
Fixed width can have lines of text end up too long or too short just as using % does since the ideal line length is around 30 - 35em and so is different depending on the size of the text.
The reason the form is overlapping the menu isn’t because the menu is in em, it’s because they put the form over the menu. SitePoint’s fault, not em’s.
If the form had been just after the menu and also floated left, it would not have been allowed to cover the last menu item. I think that a good developer would have tested his/her layout with text-enlarge to see how that would have played out (now maybe for other reasons they still decided not to build that section in a large-text friendly way, but they should have checked).
There are issues with elements like <pre> for example.
Secondly, unless you go with SVG, some graphic layout will only be viable with fixed height: like the post-it, even rotated, as a twist. This too will need px for font, as it will break like this:
This (raster images) is probably the biggest problem with em-sized boxes. When there are images involved, that’s one of the few times I’m using px for sizing any boxes (or even text), because there’s little else you can do.
Since I use Gilder-Levin image replacement for things like logos, text-enlarge (but not zoom) will eventually make the text behind the image pop out and look weird. Overflow: hidden could stop this, but then you’re limiting the size/viewability of that text because there’s an image… which not everyone will necessarily load/see anyway.
Maybe the key is to try to find the middle path… and all your points-of-view help.
I believe there is a middle path. Each design has its own issues. A good developer, in my opinion, checks out his/her design under many conditions. You maybe can’t please everyone but you can make the page work with as many visitor types as possible.
I never said em is to blame. I said you just can’t use em in certain situation, and it happend SitePoint had a page exemplifying just that.
And the overlapping reason is em. Because of this:
#header #navigation a, #header #navigation a:visited {
[...]
font: 1.2em tahoma,arial,sans-serif;
}
menu items extend more than they should in that fixed layout.
For a horizontal menu, in a flexible min-max width layout, using em is not a viable choice, unless you could also restrict em sizes to a min-max px sizes. Otherwise, you need to concentrate your neuro-muscle on what to do when a menu that should stay on one line drops on more lines.
I never said em is to blame.
Ok
I said you just can’t use em in certain situation, and it happend SitePoint had a page exemplifying just that.
Sitepoint wouldn’t have the form covering the menu if they had bothered to Enclose Their Floats. SitePoint can use em in this situation, they just need to improve their CSS coding is all.
And the overlapping reason is em.
Not in this case (if #header had overflow: hidden and a Haslayout trigger, the form would push the menu down rather than sitting over it)… but I’m not disagreeing with your main point, that there are situations where em-sizing causes trouble at larger font sizes.
For a horizontal menu, in a flexible min-max widht layout, using em is not a viable choice, unless you could also restrict em sizes to a min-max px sizes.
I don’t do this for text, but I have done it for boxes (mixed success). With text there’s no point: it’s gotta grow.
Indeed it’s not a good idea to put em/% sized text in px containers.
Since my application and desktop fonts are set to Mildly-Ginormous, I get this:
http://stommepoes.nl/spsmall.png
and full-screen:
http://stommepoes.nl/spwide.png
Again, they could have made the form just push down (and not sit over) the menu just fine. Keeping everything (text) set to px wouldn’t fix this: my browser will text-enlarge anyway (which I think I like even if it breaks the rules).
With px-sized containers, if they don’t use overflow, I’ll still have text at least spilling out, even if the containers themselves still fit with each other.
My main point was, not counting zoom, using em would make the layout break, at least by making a one line horiz menu extend to more lines.
Before even considering zoom behaviour, you should think about this possibility and cater for the scenario where the menu would possible hide submenus because it’s now a two-or-more lines menu.
Off Topic:
I’m feeling a deja vu, Stomme…?
My main point was, not counting zoom, using em would make the layout break, at least by making a one line horiz menu extend to more lines.
Yes, it does that here. It would do it in px too though in my browser.
The other menu, the one called vbmenu, grows to the right. I wonder if that’s because for some reason it’s in a table?
Before even considering zoom behaviour, you should think about this possibility and cater for the scenario where the menu would possible hide submenus because it’s now a two-or-more lines menu.
Yes. A horizontal menu in a fixed-width page or container is always going to have this issue (except in IE if you’ve set the text size in px).
Because my fonts are larger even when I don’t set them larger (simply because I run Gnome as my windowing system), sites with dropdown menus often have the last menu item wrapping (doesn’t matter what they use to size the text… still wraps for me). This makes the first and sometimes second menu-items’ submenus unavailable to me. I’ve learned as a user to do CTRL-- several times to access those menus, but why should I have to make the text microscopic just to get your menu in line??
[ot]
I’m feeling a deja vu, Stomme…?
No? Did we have this discussion before?[/ot]
Off Topic:
Somehow, this horiz menu talk brought SPF memories with it. I can’t put my finger on it though…
if your plan on using EM & % here is a good useful converter emCalc/ i think using EM/% and min-width on the body is an excellent idea
There was a thread fairly recently that discussed why converting px/ems is unreliable. @Stomme_poes summed it up pretty well [URL=“http://www.sitepoint.com/forums/showthread.php?791754-FONT-SIZE-CONVERTION-chart-(ARRAY)-GODDIE-)&p=4979164&viewfull=1#post4979164”]here](http://riddle.pl/emcalc/).
Okay, I am not entirely clear on this. I too have suffered problems using px, em and percentages, and I don’t know were to use each.
When I use % or em’s in Opera on a 120dpi mode I get a somewhat distorted view. I want a way to view things well in all browsers. I think Safari is a bit iffy too, pixels seam to work well with all browsers. Even though I understand what you’re saying you’ve still got to understand many professionals use pixels.
There is no real justification for using px for anything except borders. It might make laying out the page easier for the person writing it but will make it unusable for a portion of visitors.
I use pixels for everything more or less. Don’t use em’s. I sometimes use % for width of pages sizes relative to another div which happens to be in pixels. I think it would be easier to explain things in terms of what you would use each for.
For instance, for text, for containers and for body. I normally set the body to body {font-size:100%} on before resetting the DIV’s. Take a look at this article, 16 pixels body copy anything less costly mistake. As you can see this is a very up-to-date article and they’ve mention pixels as oppose to anything else. This discrepancy over what’s best and what’s not has left web designers lost in what they should really do in terms of fonts on their websites.
I understand the em and % in theory seem to be a good idea. But I’m finding that on my pages my floating dividing block are ending up in totally unexpected places. Also if a page is scrambled then it’s automatically rubbish, so i’ll stay with PX then. and maybe avoid min-width and heights?