User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:54.0) Gecko/20100101 Firefox/54.0 Build ID: 20170628075643 Steps to reproduce: Attachment Actual results: Width value (set not only through JS) is not the same as rendered (< 0.08). If we set font-size higher (as in the test file 40) it may also overflow (though if we say that the rendered one is the real value then it already should have). But if we set padding to: 10px 0px; it will be good until we open inspector and start to use it Expected results: stay on the same row, chrome does it right as i saw

For the rendering issue: http://imgur.com/a/vipwc

(In reply to asztrik35 from comment #0) > Actual results: > > Width value (set not only through JS) is not the same as rendered (< 0.08). To clarify -- I *think* your concern here is that the width shown in the devtools tooltip ("235.883px" in the tooltip in your screenshot) does not exactly match the specified width ("235.875px"). That's kind of expected -- we are not infinitely precise, and there's some rounding under the hood. Also, I see a version of this same bug in Chrome, too -- e.g. if I load your testcase fullscreen on my laptop in Chrome, the first group of divs get a specified "width: 228.571px", whereas Chrome's devtools reports them as "228.57" pixels wide (off by 0.001). Bottom line, layout systems aren't infinitely precise, so your specified width might be rounded slightly when producing the actual coordinates used for layout. In Firefox, we use a fixed-point representation, with 60 integer-valued "app units" per pixel. So, we can only represent fractions of a pixel that are multiples of 1/60. And in your screenshot, the specified fraction (.875) is not a multiple of 1/60, so it gets rounded to the closest value that is (which is 53/60 or 0.88333333). (Under the hood, what happens is: you specify 235.875px, and then for layout purposes we convert that into "app unit space" by multiplying by 60 & rounding -- this gives us 14152.5, which we round up to 14153.) And then our devtools dutifully report the *actual width* that we're using in our layout calculations (rounded to a reasonable number of decimal places). > Expected results: > stay on the same row, chrome does it right as i saw OK, here you seem to be talking about the actual rendered layout -- and things wrapping to the next line (which I do see at some window sizes). If you're trying to *exactly* divide up the free space equally among your elements, then yeah -- any rounding under-the-hood that we do *might* throw things off a little and can result in things being very slightly too wide, and something wrapping Your best bet is probably: (1) use something like CSS flexbox, or CSS Grid, or an HTML table -- something where you're explicitly communicating your preferences to the rendering engine about how you want space to be distributed. ...or: (2) place this content in an intrinsically sized element with "overflow:hidden" on its parent (so that a subtle overflow won't cause wrapping or scrollbars or anything ...or, perhaps easiest: (3) just round down your calculations (maybe to the closest 0.02px), and potentially throw away ~0.02px) during your calculations. Anyway, this is basically a duplicate of bug 265084 (which is on converting away from the 60-app-units-per-pixel representation), though I don't know how soon (or whether) we'll actually take action on that.