Grow your CSS skills. Land your dream job.

Percentage Bugs in WebKit

Published by Chris Coyier

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.

Update: WebKit now has subpixel rendering, which should clear up this issue.

The red lines indicate the column as rendered with WebKit. The background shades of gray are accurate placement of those columns in percentage widths.

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.


Firefox, IE, and Opera are fine.

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.

Comments

  1. Permalink to comment#

    ne kadar boş işlerler uğraşıyorsun chris bırak bunları yav

  2. 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!

  3. Permalink to comment#

    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?

  4. Willson
    Permalink to comment#

    … Odd, I just tried making a div that was 50px, and 4 divs floated left 12.5px each and there was still a gap.

    • Willson
      Permalink to comment#

      As it turns out, it seems webkit doesn’t render decimal points for css, it automatically rounds those as well.

    • Clint Kolodziej
      Permalink to comment#

      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.

  5. Clint Kolodziej
    Permalink to comment#

    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.

    • rolfsf
      Permalink to comment#

      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.

    • Clint Kolodziej
      Permalink to comment#

      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?

    • Clint Kolodziej
      Permalink to comment#

      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/

  6. 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

    • Clint Kolodziej
      Permalink to comment#

      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.

  7. 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

  8. Jarrod Medrano
    Permalink to comment#

    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.

  9. Permalink to comment#

    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.

    • Very cool, thanks for the run-down Patrick.

  10. Interesting topic, thanks

  11. Permalink to comment#

    Hi, its very nice post

  12. 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

  13. Maru
    Permalink to comment#

    Please use your old CSS-Tricks Layout…

  14. Opera also has problems with decimals in percentages:

    http://www.brunildo.org/test/percwidth2.pl

  15. priyesh
    Permalink to comment#

    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.

  16. I ran into this problem while writing a css grid, it sucks

  17. 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/

  18. Alfonse

    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.

This comment thread is closed. If you have important information to share, you can always contact me.

*May or may not contain any actual "CSS" or "Tricks".