Width / Height with fractional dimensions

[marcosesperon]

Hi!

I had to modify width/height calc at the items loop in order to fix a bug with fractional dimensions.

When an item size is not rounded, functions like outerWith, round the value to the low value. In my example, the button outerWidth was 136px but if you look at the css dimension it has 136.34...

I used $item[0].getBoundingClientRect().width to obtain the correct value.

[darsain]

Oh, didn't know getBoundingClientRect returns subpixel values.

But the thing is, what browsers render subpixel values? Don't they all round? That's the reason why I never even researched the subpixel thingy.

In other words, if I add up sizes of 100 items that are 136.34px, and than use this sum to resize the slidee element and set limits and positions, the slidee will be 34px bigger than it should, and all positions will be >1px off, no?

It is even more complicated with floated items, where the browser will alter the rounding direction (up/down) to fit items inside container. This altering is not visible in boundingClientRect, but it is in clientWidth, which is what Sly is using now.

Example: http://jsfiddle.net/jfao2zco/

I guess you are running into an issue where last item is placed on a next line because Sly didn't stretch the slidee element wide enough? If so, it'd be awesome if you could isolate the issue on jsfiddle so I can look at it and maybe come up with something. Thus far none managed to do that :)

[marcosesperon]

Hi darsain,

Exactly, the problem is that the last element fails to display with Sly because of 1px. I didn't know the problem of subpixels values with browsers without round, is the first time I find this.

I tried to reproduce the error on the fiddle: http://jsfiddle.net/jfao2zco/3/

Take a look and tell me.

Thank you.

[darsain]

I meant reproduce the issue where Sly fails stretching the slidee to accommodate last item. Don't know what the fiddle you posted is about.