Using percentage values for certain things can have slightly unexpected results in WebKit based browsers. For instance, if you have a series of columns set in percentage widths with percentage padding, WebKit can calculate their sizing rather strangely.
It’s percentages in general that seem to be the issue. I haven’t been able to dig up a ton of information on it, although I do seem to remember reading something about it quite a while ago. I think it’s related to how subpixel values are calculated. For example, if a container is 657px wide currently, and has four columns at 25% each, they would be 164.25px each wide, and WebKit doesn’t handle that well (rounding issues?) Other browsers handle the “subpixel” value OK.
Thanks to Nicolas Gallagher for pointing this out to me. If I’m way behind the times on this, feel free to yell at me, but throw me some links and information so I can update this post with the most accurate information I can. This link seems to indicate the issue has been around a while.
Remember this is only really an issue if you are doing something like shown in these examples with solid color columns. If you didn’t have any visual separators, it might not be a big deal, just a slight cross browser difference very few people would ever notice.
ne kadar boş işlerler uğraşıyorsun chris bırak bunları yav
english?
i dont know englis, u speak turkis ok?
Google translate give me: `Leave blank run them how they strive chris yav`
in turkish -> boş iş deme, büyük projelerde önem taşıyabilir böyle şeyler
I’ve noticed this before but had no idea it was a ‘subpixel’ issue. I think I just ended moving from percentage to pixel spacing just to bypass it entirely!
ups, what a bumma?!
they should fix it fast. I’m not using percentages that often but came along some strange behavior too.
Hopefully there aren’t some issues with em’s vertically?
John Resig wrote on this a while back:
Sub-Pixel Problems in CSS
Checked out the demo on that page – IE8 still does it wrong! Amazingly it still rounds up and breaks the layout and that article was written 2 1/2 years ago.
Wrong? The developers at Microsoft chose a different solution. In my opinion the least favorable but you can’t call it wrong. As the article states by the way!
… Odd, I just tried making a div that was 50px, and 4 divs floated left 12.5px each and there was still a gap.
As it turns out, it seems webkit doesn’t render decimal points for css, it automatically rounds those as well.
Yeah, its always frustrated me that 3 columns of 33.3%, 33.3%, and 33.4% in Webkit is functionally the same as specifying 33% on each without the decimal. The only solution is to go with 33%, 33%, 34% or some variant of that.
Ran into this quite a few times in the past dealing with fluid grids, seems Firefox and Opera try to round properly, and even if there is some odd pixel left over they find out a way to display properly. IE and Webkit unfortunately take the approach of truncating any fraction/subpixels which will cause floated elements to not fill their container properly if the math doesn’t work out cleanly. If you take a look at nearly any fluid grid systems currently out there IE and Webkit will give subpar results.
As John Resig summarized, there really is no right or wrong. It’s frustrating that all browsers don’t use the same method. In the case of Firefox, it’s no longer following the CSS rule that dictates that, for example, four floated divs be equal in width, whereas Webkit is. There are cases where one method will work better visually than the other, but it’s not universal.
Agreed, but it is definitely frustrating that if the percentages of multiple columns add up to 100% you would expect that they would fill 100% of the row rather than 98% (or less in some examples) due to the truncation of fractional percentages.
Even if the spec does not clarify which is the right approach my guess would be that if the percentages add up to 100% the designer probably wishes them to fill the entire row rather than enforce the requirement that they all be equal as if a few boxes have a couple “rounding pixels” that is less visible to the end-users of the website than if there is a bunch of space at the end of a row.
At least none of the browsers round up and cause float drop!
Anyone here taking part in the HTML5 spec so they can try to add some definition to this?
Take a look at this in IE/Webkit to see a better illustrated example of the problem: http://www.designinfluences.com/fluid960gs/12/fluid/none/
Hi Chris,
we covered sub-pixel rounding algorithms for major browsers for the development of Elastic CSS Framework.
You can read it here: http://elasticss.com/determination-of-algorithms-used-for-percentage-based-rounding-divs-on-browsers-and-css-frameworks/
cheers
Sergio, I hadn’t seen that framework in the past, thanks for the link.
For some including javascript to fix the rounding errors may not be desirable due to performance concerns on complex pages, especially depending on the average page visitor (slow computers), but there are a lot of situations where a fluid/elastic grid is desirable and is a great solution.
As suggested in your review of the issue, it of course would be great if the browser vendors at least documented how they handle rounding. Perhaps if that occurred it would be more apparent that there is a problem, and the chances would be greater that there was an effort to standardize.
I used *margin-right:-1px; fix(IE6/7) for 1 line CSS Grid Framework http://www.vcarrer.com/2009/06/1-line-css-grid-framework.html
I try to avoid using padding on things that have their widths defined, just to avoid complications like this. If possible I’ll add the padding to the child element.
I think the only way how to avoid this problem is to make sure you can divide the container in the whole pixels. I.e. if you want to divide into 4 columns of the same size, you need to adjust the container size from 657px to 656px.
Technically you need to follow this rule: container.size%number_of_columns = 0
Btw I’ve noticed the same problem in IE6 and IE7, when you divide i.e. container size 101px into two 50% columns, each of them will be 51px in IE6 and IE7. I guess it rounds 50.5px to 51px.
Like some others explained at the top, there are 3 types of calculation for sub-pixels.
IE-Method:
– classic round for subpixels
– round-down<0.535 ///// 32.3=>32
– leads to the problem that floated divs break the layout when IE rounds-Up too often.
Opera/Safari-Method:
– always round-down subpixels
– e.g. 34.6=>34 ///// 32.3=>32
– leads to some blank pixels at the left when divs are floated to the left and at the right when floated right
Firefox Method:
– complex algorithm for rounding
–>http://elasticss.com/determination-of-algorithms-used-for-percentage-based-rounding-divs-on-browsers-and-css-frameworks/
– leads to the best result for layouts, but its not transparent which div gets which exact size.
Very cool, thanks for the run-down Patrick.
Interesting topic, thanks
Hi, its very nice post
We try to make sure we can divide the container in whole pixels by 3 to 4 columns if need be, but this is not always the case with clients needs so good to have work arounds, Thanks. LT
Please use your old CSS-Tricks Layout…
Opera also has problems with decimals in percentages:
http://www.brunildo.org/test/percwidth2.pl
Good site and also kept the web bug with web kit. It is useful with browsers and kept web bug with webkit and give padding and percentage widths for webbug and also slightly unexpected results in WebKit based browsers.
I ran into this problem while writing a css grid, it sucks
Safari still has the problem but Chrome is good now.
I have made a comic about the percentage bugs and the browsers if you fancy a giggle about the situation:
http://www.digitalpod.co.uk/blog/web-browser-comic-percentage-layouts-with-gaps/
As of writing, Chrome (v 35.0.1916.114) still has issues dealing with padding percentages when used to wrap elements floated with percentages.
Check out this Fiddle and expand your window.
http://jsfiddle.net/mUudt/
You’ll notice that the third child will fall below to the next line once the area of the window expands. The reason is because the parent has a 1% padding applied to the container and the padding percentages expand to push the last(3rd) element down instead.