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

Chrome Issue: CSS column-count and data-role="panel" #5508

Closed
gvanberkel opened this Issue Jan 22, 2013 · 5 comments

Comments

Projects
None yet
2 participants
@gvanberkel

gvanberkel commented Jan 22, 2013

Trying to click into one of the JQM controls in the CSS column count area yields unexpected results when combining CSS column count in the content area and a data-role=panel (the click doesn't accurately select the correct control).

Try and select on of the columnized controls in the details section. Example 1 is broken. Example 2 works fine (as it does not have a Panel control).
This is a Chrome only issue. Works fine in every other browser I've tried.
Tested using Chrome versions 24 (stable) and 26 (canary)

http://jsbin.com/uhefac/14/edit - E1 with panel control
http://jsbin.com/adaxix/1/edit - E2 no panel control

@jaspermdegroot

This comment has been minimized.

Show comment
Hide comment
@jaspermdegroot

jaspermdegroot Jan 22, 2013

Member

@gvanberkel

Thanks for reporting the issue. Should be fixed in latest code now.

Member

jaspermdegroot commented Jan 22, 2013

@gvanberkel

Thanks for reporting the issue. Should be fixed in latest code now.

@ghost ghost assigned jaspermdegroot Jan 22, 2013

@gvanberkel

This comment has been minimized.

Show comment
Hide comment
@gvanberkel

gvanberkel Jan 22, 2013

Working great!
You guys have such amazing turnaround time on reported issues.
Something to personally aspire to.

gvanberkel commented Jan 22, 2013

Working great!
You guys have such amazing turnaround time on reported issues.
Something to personally aspire to.

jaspermdegroot added a commit that referenced this issue Jan 27, 2013

Panels: Removed CSS rule that was added as fix for issue #5508 becaus…
…e 3D-ing all divs causes stacking context issues. Added info to the docs as fix for #5508.
@jaspermdegroot

This comment has been minimized.

Show comment
Hide comment
@jaspermdegroot

jaspermdegroot Jan 27, 2013

Member

@gvanberkel

The issue you reported was caused by the way we force hardware acceleration on WebKit browsers: we set -webkit-transform: translate3d(0,0,0); for the divs that are animated. The fix was setting the same rule for all divs in the content.

However, we noticed that this causes problems with at least one widget (rangeslider) so I removed the fix. It only appears to be a problem when column-count is used to layout a form. Since there is no way to narrow the scope so the fix would only apply in this situation, we can't fix this in the framework. I added information about the issue and how to fix it to the panel documentation.

This means you have to add the fix in your custom CSS. I added it on your test page: http://jsbin.com/uhefac/25/edit

While looking into this again I noticed some other issues with column-count in general. Maybe you already found out, but if not...

column-count and box-shadow don't seem to play nice together. In the first collapsible, on Chrome, when the first input in the right column gets focus you see the top of the focus style at the bottom of the left column. On Firefox it was even worse, the whole input moves to the first column when it has the focus style. The fix for this is to set a bit top and bottom margin on the form elements.

Also the first collapsible, Chrome renders the top half of the input in the left column and the bottom half in the right column on certain screen widths. To prevent this you can set -webkit-column-break-inside: avoid; for the field containers.

Member

jaspermdegroot commented Jan 27, 2013

@gvanberkel

The issue you reported was caused by the way we force hardware acceleration on WebKit browsers: we set -webkit-transform: translate3d(0,0,0); for the divs that are animated. The fix was setting the same rule for all divs in the content.

However, we noticed that this causes problems with at least one widget (rangeslider) so I removed the fix. It only appears to be a problem when column-count is used to layout a form. Since there is no way to narrow the scope so the fix would only apply in this situation, we can't fix this in the framework. I added information about the issue and how to fix it to the panel documentation.

This means you have to add the fix in your custom CSS. I added it on your test page: http://jsbin.com/uhefac/25/edit

While looking into this again I noticed some other issues with column-count in general. Maybe you already found out, but if not...

column-count and box-shadow don't seem to play nice together. In the first collapsible, on Chrome, when the first input in the right column gets focus you see the top of the focus style at the bottom of the left column. On Firefox it was even worse, the whole input moves to the first column when it has the focus style. The fix for this is to set a bit top and bottom margin on the form elements.

Also the first collapsible, Chrome renders the top half of the input in the left column and the bottom half in the right column on certain screen widths. To prevent this you can set -webkit-column-break-inside: avoid; for the field containers.

@gvanberkel

This comment has been minimized.

Show comment
Hide comment
@gvanberkel

gvanberkel Jan 28, 2013

Thanks for this extra info. I did indeed come up against these very issues. I fixed it in a more round about way playing with various styles (mostly disabling the external glow). I'll use the CSSs you suggested.

gvanberkel commented Jan 28, 2013

Thanks for this extra info. I did indeed come up against these very issues. I fixed it in a more round about way playing with various styles (mostly disabling the external glow). I'll use the CSSs you suggested.

@gvanberkel

This comment has been minimized.

Show comment
Hide comment
@gvanberkel

gvanberkel May 29, 2013

I have since switched to using the JQM column classes with much success. I'd be happy to close this issue.

gvanberkel commented May 29, 2013

I have since switched to using the JQM column classes with much success. I'd be happy to close this issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment