8000 [BUG] White space on left side when scrolls are used on v1.2.0 · Issue #2271 · tabler/tabler · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

[BUG] White space on left side when scrolls are used on v1.2.0 #2271

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.

Sign up for GitHub

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

Jump to bottom
Open
rdeavila opened this issue Apr 17, 2025 · 9 comments
Open

[BUG] White space on left side when scrolls are used on v1.2.0 #2271

rdeavila opened this issue Apr 17, 2025 · 9 comments
Labels
bug Something isn't working

Comments

@rdeavila
Copy link
rdeavila commented Apr 17, 2025 •
edited
Loading

Browser

Chrome Versão 135.0.7049.86 (Versão oficial) 64 bits

OS

Windows 11

Screen size

1920x1080

Describe the bug

Hello!
On v1.2.0, when the page has content to scroll, a white space appears on the left side. The space is more proeminent with dark backgrounds.

Image

Image

Image

When the page don't use a scroll, no space are shown.

Image

How to reproduce

  1. Go to https://preview.tabler.io
  2. See the white space on the left
  3. Change to dark mode to see it better

Screenshots

Image

JSFiddle

No response
@rdeavila rdeavila added the bug Something isn't working label Apr 17, 2025
@rdeavila rdeavila changed the title [BUG] White space on left side when srolls are used on v1.2.0 [BUG] White space on left side when scrolls are used on v1.2.0 Apr 17, 2025
@ethancrawford
Copy link
Collaborator
ethancrawford commented Apr 17, 2025 •
edited
Loading

Context: If I understand it correctly, then this appears to be due to an issue (described in "Known Issues" at https://caniuse.com/viewport-units) where (in this case) Chrome is incorrectly calculating 100vw. (As implemented recently here):

tabler/core/scss/layout/_root.scss

Lines 1 to 7 in f25da87

:root,
:host {
font-size: 16px;
height: 100%;
@include media-breakpoint-up(lg) {
margin-left: calc(100vw - 100%);

(As a result, in firefox margin-left resolves to 0px, but all other browsers would not).

@siunus
Copy link
siunus commented Apr 19, 2025

This is also visible in the vertical sidebar.

Preview
Image

Production App
Image

@steveiliop56
Copy link

Seems to correctly if I remove the margin and set the body to scroll.

@media (min-width: 992px) {
  :host,
  :root {
    margin-left: 0;
  }
}

body {
  overflow-y: scroll;
}

@lenon
Copy link
lenon commented Apr 22, 2025

I have the same issue on macOS in both Chrome and Firefox. It seems to be caused by the margin-left added in #2237. If I remove it, the problem goes away.

@ethancrawford ethancrawford mentioned this issue Apr 22, 2025
Closed
@ethancrawford
Copy link
Collaborator

Given above comments, it appears that this issue is also affected by different browser's handling of 'classic' vs 'overlay' scrollbars.
https://www.smashingmagazine.com/2023/12/new-css-viewport-units-not-solve-classic-scrollbar-problem/ describes the problem (while also highlighting the inability of some new viewport units svw, lvw, dvw to solve it).

Several potential solutions are also outlined in the article. I tested a few of them roughly (forcing scrollbars to appear on my mac, while putting container-type: inline-size; and scrollbar-gutter: stable; both individually and together on the html element, and replacing 100vw with 100cqw). None of these worked. Possibly the solution in javascript described there may work, though of course that may be less ideal 🤷‍♂

Setting margin-left explicitly to 0 does of course solve the immediate problem, but would probably require an alternative solution to the issue that #2237 was trying to solve...

@rdeavila
Copy link
Author
rdeavila commented May 1, 2025

Hello! There's any workaround to use by now, or just wait for a new release?

@ethancrawford
Copy link
Collaborator
ethancrawford commented May 2, 2025 •
edited
Loading

@rdeavila - as mentioned above, setting margin-left to 0 appears to solve the immediate issue of the undesirable margin in this case. However, that undoes the work that @codecalm was trying to achieve with #2237 to apparently try to solve #1648.

(Without looking at it a whole lot more closely, My instinct is to think that #1648 requires an alternative solution, and that #2237 should be reverted or reworked).

@rdeavila
Copy link
Author
rdeavila commented May 2, 2025

@ethancrawford When 'margin-left' was mentioned, I thought they were talking about the definitive solution, not that it could be used as a workaround (sorry, backend developer here). Thanks for clarifying!

@ethancrawford
Copy link
Collaborator

@rdeavila Ah, no worries, you're welcome. Not sure what the 'proper' solution is in this case, but hopefully it's not too complicated 🙂

@XEonAX XEonAX mentioned this issue May 3, 2025
Closed
@ethancrawford ethancrawford mentioned this issue May 22, 2025
Closed
@ethancrawford ethancrawford marked this as a duplicate of #2399 May 23, 2025
@ethancrawford ethancrawford mentioned this issue May 23, 2025
Closed
@ethancrawford ethancrawford marked this as a duplicate of #2406 May 24, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug Something isn't working
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
5 participants
@lenon @rdeavila @ethancrawford @siunus @steveiliop56
0