Skip to content
New issue

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

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

Already on GitHub? Sign in 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

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

Successfully merging this pull request may close these issues.

2 participants