Flex justify-content: center has horizontal scroll left side cut-off or clipping issue on horizontal overflow; Workaround by using margin: auto to center

Last updated on 27 April 2024

Quick-Info

display:flex declaration followed by justify-content:center declaration applied to body element of blogbook through CSS class blogbook, is the cause of left side cut-off/clipping issue. Solution is to drop justify-content:center declaration in CSS class blogbook and apply auto margins (margin: auto declaration) to the item inside flex which is the main element with associated CSS class main-book.

--------------------------------------

While the Blogger Blog Feed to HTML book (BFTB) App now prevents horizontal scroll for window width less than 360px, due to images (by setting max-width to 90%), pre elements (using specific CSS for that) or long words (similarly using specific CSS), every once in a while I come across a blog book case where some HTML in it results in horizontal scrollbar appearing and sometimes a portion of the window on left side getting cut-off or clipped such that the scrollbar cannot bring it into view. The latest case is a page having span with 'whitespace: pre'  CSS declaration having content that overflows the window when the window width is reduced to 550?? or so pixels.

Now these small window widths would typically be on mobile. I use the app mainly on desktop but would like it to handle such mobile window widths too. Also there would be some use cases of reducing window width on desktop/laptop/tablet to 550 or so pixels, for some comparison or other such tasks. So it will be nice if the app. can handle such window widths for all blogbooks irrespective of its HTML.

A decent solution would be to have full horizontal scrolling for special content like span with whitespace: pre CSS declaration, for which the app (currently) does not have special CSS to prevent horizontal scrolling. 

I also felt that this is the right time for me to investigate why this left-side cut-off or clipping is happening in some cases. I expected that in such cases, the content will be fully viewable with horizontal scrolling. Earlier I did not have the time to investigate it, and anyway as I wanted to avoid having horizontal scrolling itself, there was no urgent need to understand why this left-side cut-off was happening.

Over past couple or so days, I did some digging up on the issue. This stackoverflow article of July 2022: Justify center flexbox items without cutting off overflow [duplicate] and/or similar articles led me to understand that the display:flex declaration followed by justify-content:center declaration applied to body element of blogbook through CSS class .blogbook, could be the cause. The article has a jsfiddle showing the original post author's issue which uses an outer container div with display:flex and overflow: scroll, and an items container with display:inline-block. The outer container div is used twice, once with 10 items and once with 1 item. The 10 items div shows the left-side cut-off clipping issue.

An answer in the article provides a solution to the issue by having an outer container div with display: flex and justify-content: center, an inner container div with display: flex and overflow: auto, and an items container div with display: inline-block. However, the horizontal scrollbar for overflow div cases appears only at the bottom of that div which becomes visible only when scrolling down.

I decided to write a test page which uses my blogbook structure and check out various key CSS settings. I wrote some JavaScript to change key CSS settings via buttons on the page. I have given some explanantion on the page itself and have right-justified the text as when the clipping issue happens only the left side gets clipped. One is able to scroll to the right edge and view all content on right hand side. The pages are on Github (a page with solution/fix was added later) and are deployed on Github Pages.

On Chrome browser, with initial values of style properties of the page, reducing window width will eventually show left side cut-off/clipping problem even though some horizontal scrolling is possible (but not to the cut-off/clipped areas). If the image in the page is hidden then the span with white-space:pre will create the same left side cut-off issue but at a smaller window width.

Setting container flex: justifyContent to "initial" will solve the issue by introducing wide enough horizontal scrollbar!

Setting item div: overflowX to "scroll" introduces a scrollbar at bottom of item div which is sometimes off the screen, and so is not helpful.

I think this test page confirms this strange behaviour of flex when justify-content: center is used. I had tried an earlier version of this page additionally on Edge browser and saw the same issue. 

This stackoverflow article of Oct. 2015: Can't scroll to top of flex item that is overflowing container , covers a similar issue but for vertical scroll. The first answer to the original post confirms the issue and also provides alternative solutions! It states, that flexbox makes centering very easy. That's exactly what I learned going through flexbox tutorials, and that is why I used flexbox in the blogbook body element to center the contained main-book main element contents. It goes on to say, "However, there is a problem with this method when the flex item is bigger than the flex container." For vertical overflow, top becomes inaccessible and for horizontal overflow, the left part becomes inaccessible.

Hmm. This seems to be a known problem. None of the CSS tutorials that I went through on flexbox pointed this out. I don't like these unpleasant surprises/discoveries but I think that is life in HTML/CSS world.

Why does flex have this strange behaviour? The first answer in the Oct. 2015 stackoverflow article has a section at the end, called "Explanation for scroll limitation from MDN:" which links to an MDN article but the MDN article content does not seem to have the explanation given in the stackoverflow article (also, the url provided in the stackoverflow article does not fully match the article one goes to in MDN)! Perhaps the MDN aricle has changed drastically over the past 8 years since the stackoverflow article answer. I have given below the key part of this "Explanation" below:

For now, if this is a concern, you can instead use margins to achieve centering, as they'll respond in a "safe" way and stop centering if they overflow.
Instead of using the align- properties, just put auto margins on the flex items you wish to center.
Instead of the justify- properties, put auto margins on the outside edges of the first and last flex items in the flex container.
The auto margins will "flex" and assume the leftover space, centering the flex items when there is leftover space, and switching to normal alignment when not.

---- end extract from stackoverflow article ---

Hmm. I need to try this out. But Flex items inside overflow container display issue article dated March 2022 seems to cover a similar case where the author states that margin: auto solution has some issue. I wonder whether I should invest time to study this article or whether I should consider using media query to have justify-content: center only when window width is greater than max-width of main-book class associated with main element of blogbook (only child element of body of blogbook).

Update on 23 Apr. 2024, around 10.15 PM: Tried the above margin: auto solution and it worked! Reorganized github project to have index page having links to one page showing problem and another page showing fix.

w3schools.com page about using margin: auto to horizontally center block elements

Now a question I need to consider, not urgently, but somewhere down the line, is whether in my BFTB App, I should remove display: flex from body element of blogbook page. I was using it along with justify-contents: center to center main element (which has max-width of 1200px). Now I am using margin: auto to center main element and so body element need not be flex. The concern for making the change is the time needed for testing the app. Maybe I will do it at a time when I need to do major changes to the app.