Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Fix colWidth calculation issue #25

Open
wants to merge 2 commits into
base: master
Choose a base branch
from
Open

Conversation

amytych
Copy link

@amytych amytych commented Mar 2, 2019

There are sub-pixel differences between col widths returned by different browsers, when the width is not defined in absolute pixel values, e.g. a percentage. In Firefox, for example, it causes a three column layout to be rendered as a two column layout.

See this fiddle forked from your example in the README: https://jsfiddle.net/avwgdurp/
When you resize the preview container you notice in Firefox the layout jumps between 2 and 3 columns, whereas in Chrome there are always 3 columns rendered.

Chrome:
chrome

Firefox:
firefox

This change floors the col width value to the whole pixel, ensuring their combined width is never wider than the container.

There are sub-pixel differences between col widths returned by different browsers, when the width is not defined in absolute pixel values, e.g. a percentage. In Firefox, for example, it causes a three column layout to be rendered as a two column layout.

See this fiddle forked from your example in the README: https://jsfiddle.net/avwgdurp/
When you resize the preview container you notice in Firefox the layout jumps between 2 and 3 columns, whereas in Chrome there are always 3 columns rendered.

This change floors the col width value to the whole pixel, ensuring their combined width is never wider than the container.
@e-oj
Copy link
Owner

e-oj commented Mar 2, 2019

Unfortunately, There's no real fix for this issue due to the lack of standardization around sub-pixel rendering. Browsers handle sub-pixels in different ways; some round up, some round down, and some do both.

If we round down the value returned by colWidth, we might get overlapping elements in browsers that round up sub-pixels, and if we round up colWidth, we risk creating columns that are wider than their components.

Check out these articles for more info on this issue:

@amytych
Copy link
Author

amytych commented Mar 2, 2019

I see, I'll close it then. Thanks for the response and the articles!

@amytych amytych closed this Mar 2, 2019
Instead of flooring col width down to the whole pixel, this approach tries to reduce the value by 0.0001 of a pixel, until we have proper layout. It happens in a short loop with limited iteration count. It also happens only in the case when there is sub pixel rounding issue.
@amytych amytych reopened this Mar 4, 2019
@amytych
Copy link
Author

amytych commented Mar 4, 2019

I tried one more idea to solve this issue. Please let me know what you think about it, I explained it in the commit message.

@e-oj
Copy link
Owner

e-oj commented Mar 24, 2019

Have you tested this?

@amytych
Copy link
Author

amytych commented Mar 31, 2019

Yes, I did, please check this fiddle based on the version of MagicGrid from this PR. When you resize the window in Firefox, you can see that the layout always keeps 3 columns, instead of jumping between 2 and 3 columns like in the original one. https://jsfiddle.net/txyojrq3/

image

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants