CSS percent Vs. Pixel

Hello.

Can anybody suggest me what is better to use between % an px to specify the dimension in CSS?

Thanks.

 

Depends on whether you want a fixed or fluid site.

 

If you use %, note that: your design will not looks the same in all computer user screens. Some people use small computer screens like 800x600 (px), others use larger screens like 1153x864 (px), 1280x720 (px). So your page could looks smaller or larger, depends on screen wide/height that the user has.

 

Depends on the ELEMENT. %/EM is generally made of fail on lineart images due to pixellation. PX is generally made of fail for FONTS unless you declare a size LARGE enough in the first place for everyone. (anything less than 12px is useless for large font/120dpi users, and really we bitch about 14px as too small)

Generally, your content font should ALWAYS be %/EM, or at bare minimum PT so it at least obeys the system metric. Anything else is made of /FAIL/.

Generally, anything that is an image, will interact with images, or requires precise measurement in the vertical should be declared in px - the last of those (measurements in the vertical) wouldn't be neccessary if gecko wasn't such a retard about making %/EM elements the same height on the same page.

 

I prefer using fixed sizes... about 1000px for web page wide which is standard today. It's easier to organize the content and it looks nicer for me.

Percentage is ok for websites with not too much rows and images. Percentage is also ok for forums...

Solution I also like is to mix fixed size with fake percentage... for example: header and footer are 100% wide... Content stays fixed and it looks like the whole screen is filled...

 

Depends on your image. It's not a problem with those by themselves.

I don't follow you there at all.

None of that is true and pt is for print.

This isn't true, or at least doesn't make any sense. I use percent and em all over my sites with no issues in any browser (but IE which can't get anything right).

 

and the browser - if you have a lineart image that used dithering it's going to look like crap resized either direction which is why if you are using an IMG tag, declaring it's width and height in CSS is going to be made of /FAIL/. Downscaling giving you a moire pattern, upscaling if you have pixel width lines are going to give you uneven multiples or blurring.

Usually the only image type you can get away with it ends up being photographs or smooth shaded art - and even then some browsers handle it better than others since browsers handle the resizing of images differently.

It is also an issue with fixed height images used as backgrounds for things like headers - you declare the height as %/em don't be suprised when it looks like ass on some IE and Opera users machines when the large font 120dpi system metric kicks in.

(re: px made of fail for fonts)

Anything smaller than 12px is effectively useless to those of us running large fonts/120dpi under windows - which is a increasing number of users with 22" LCD's coming out at 1920x1200 or 15.4" laptops that are 1400x1050. Really 14px is too small in a lot of typefaces which is why a font that obeys the system metric, like %/em (in Opera and IE) or PT (which everything except webkit does)

There's a REASON so many forums and sites started using PT for font sizes in the first place when CSS first came along - and that reason was it's the only font with sufficient granularity to have integer sizes that obeys the system metric in both Netscape (and netscape heritage browsers) and IE. Large font users EXPECT your site to enlarge the font 25% when visiting your page - and if it doesn't they are more likely to blow right past your site as rubbish instead of diving for the zoom.

(re: %/EM or PT good, px for fonts made of /FAIL/)
So you say it's ok to generate your content text in PX? Good job alienating anywhere from 10-30% of windows users depending on your target audience. As to 'pt is for print' pt is just another measurement, and while in print it is indeed 72ptpi, it does have a value, meaning and predictable behavior in screeen media so where's the problem? ... AND AT LEAST it obeys the system metric in gecko and older netscape, something %/em cannot claim.

Try making a 100% min-height layout with a 'ride up' footer as 3em tall and say that. There's an 'issue' with gecko where it tracks ALL numbers as floats, never discarding that float when adding up values. Because every other browser uses the rounded off (or truncated) rendered heights instead of actual heights, 1.3em for example doesn't always total the same height.

For example:

<div style="height:1.3em;"></div>
<div style="height:1.3em;"></div>
<div style="height:1.3em;"></div>

Code (markup):

and

<div style="height:3.9em;"></div>

Code (markup):

Under gecko have a very slim chance of that EVER rendering to the same number of pixels in height, being up to two pixels 'off'. You apply this to a dithered image or lineart... or even worse a layout that requires the height to be fixed for positioning, and you end up in hell... For example a simple 100% min-height layout:

CSS:

* {
	margin:0;
	padding:0;
}

html, body {
	height:100%;
}

#container {
	overflow:hidden; /* wrap floats just in case */
	min-height:100%;
}

* html #container {
	/* 
		IE6 has no min-height, but will will treat height as such
		if overflow is set to visible. Thankfully the height declaration
		trips haslayout, which wraps floats.
	*/
	height:100%; 
	overflow:visible;
}

#content {
	/* extra bottom padding makes room for footer */
	padding:0.5em 0.5em 4.1em; 
}

#footer {
	position:relative; /* make sure it depth sorts over #content */
	margin-top:-3.6em;
	font:normal 100%/120% arial,helvetica,sans-serif;
}

Code (markup):

HTML:

<div id="container">

	<div id="content">
		Just some test content
	</div>
	
<!-- #container --></div>

<div id="footer">
	Test Line 1<br />
	Test Line 2<br />
	Test Line 3
<!-- #footer --></div>

Code (markup):

Has a 50% chance of giving you scrollbars when it shouldn't under firefox depending on how tall you make the browser window - I know what you are thinking, add a height to #footer of 3.6em - no go because the EM calculation ends up 'different' for margin than for height. If you use px for fonts for the footer, you don't have this problem.

Remember, gecko is a complete ****tard both about it's default line height which seems to change willy-nilly, and about adding up the total heights if declared in percentages or em - or any other metric that resolves to an non-integer number of pixels. These same rounding issues are why position:absolute; right:0; is often off by a pixel in gecko depending on screen width, requiring that stupid padding-right:0.5px; on BODY to fix it.

... and it's **** like that which the mozilla folks don't even consider to be a problem that cause more headaches for me than anything wrong with IE - why? Because at least IE's bugs are well documented and talked about, while things gecko gets wrong (compared to Opera, Safari and IE) often leave you high and dry with no choice but to abandon a normally sound technique wholesale, or resort to -moz equivalents that have been available since before firefox was a twinkle in a floss fanboy's eye yet still not have their CSS2 equivalent available. (inline-block anyone?)...

Even saying there's anything wrong with gecko seems to be heresy to most web designers and the rabid fanboy firefox nuts - much less pointing out decade old unresolved gaps in the CSS2 implementation like say... bugzilla #915?

-- edit -- I should point out that many of the height issues WERE finally resolved when FF 3.0.3 was released, and 3.0.4 shows more promise, but it's still ridiculous what a pain heights are in FF compared to RoW.

 

The 1px rounding error is in IE and still in IE7 but fixed in FF3 (might have been fixed in the last version of FF2, don't recall). iirc, it still exists in other browsers, too.

The rest of your post I don't have time to look at right now but, combined with your post in the other thread, makes me wonder if you aren't a year or so behind the times.

 

Fixed pixels is better than porcentage for me. We convert PSD to HTML CSS.

 

If the text appears too small - ever heard of this...

CTRL + MOUSEWHEEL

Changes the size of your text and in some browsers, images as well.

 

I use both. There's no way to say that one is better than the other they both have their uses depends what your doing.

 

... and often breaks layouts, and is a pain in the ass every time you visit a page, and usually makes images look like crap especially when people use images instead of text on things like buttons...

See the current train wreck that is my.opera.com

All for something there is zero excuse not to implement as an automatic behavior in your page from the start.

Oh, and if you use px the text-sizing does NOT work in IE6/earlier, which is where that whole 62.5%==10px nonsense came from. (Which is not true on any of my computers)

 

I don't worry about that bug, but there are a pack of others that just kill me. They make me rip my hair out, and I see people on Bugzilla commenting on how "it's not all that important" or "there aren't enough coders working on layouts" meanwhile all these goofy features keep getting added-- just like in the Browser Wars. Features should always come AFTER bugs are fixed, not the other way around. There's a bug (the table-relative-absolute positioning bug) that's getting its 8 year anniversary the 21st of this month (dec 2008). I'm putting on my party hat and breaking out the cheap beer for that one!

At least IE bugs are hackable and usually fairly easily avoidable. FF bugs just make you either abandon decent web practises or force you to leave a page not working fully in Gecko. Hate it.

I don't worry about using ems in my fonts-- I know each browser seems to show even the same font slightly different so I'm not going to cry over a few pixels. I can pretty much set all my text in em's, even over images if it has a lot of room.
Menu image replacement, I use px always. I've used %'s for popup labels and sometimes this is ok but that's maybe the only time I'd use a scalable thing for popups, otherwise also px.

Re the rounding bugs--
I've noticed that whenever I'm pulling someone up with a top negative margin, SaffyChrome is ALWAYS higher than everyone else. Doesn't matter if I set the margin in px or em or whatever, it's always higher (however I've never tried this in a page entirely sized in px, which I wonder if that would work). I haven't found out what causes this, or if there's a way to code around it (something I'm missing?). I've seen this on other people's pages too.

What's going on in SaffyChrome here?

 

As I said on Bugzilla, how about finishing off HTML 4/XHTML1/CSS2 compliance before having your coders start wasting time on HTML 5/CSS3 elements we won't be able to deploy for a decade anyways? Mozilla, Opera and the Webkit folks are all guilty of that one. They've got people wasting time coding **** that isn't even out of DRAFT when they have some really big holes in decade old finalized specifications.

I'd have to see a code example, I've not had any issues with Webkit in regards to negative margins.