Improve handling of body overflow

[JayPanoz]

I'm submitting a need for improvement

We have several issues related to overflow in body (CSS multicolumn) so there is clearly a need to improve ReadiumCSS here.

List of know issues:

• Overflow on long words #129
• Long hyperlinks overlap on the next column #127
• EPUB with overflow-x: hidden style breaks pagination #119

At least text shouldn’t be visibly overflowing in the next column, but if we can also guarantee it will break in order to stay readable, this will be a better solution, obviously.

[JayPanoz]

OK so I explored overflow: clip as it was first mentioned in #119 to see how it could solve all issues.

As a disclaimer, we’re already finding ourselves dealing with progressive enhancement and the lack of guideline/policy (issue #139) given it’s part of the 2022 baseline, with support available from Chrome 90, Firefox 80, and Safari 16.

As a spoiler, this would be an incomplete fix due to partial support of overflow-clip-margin.

MDN docs

• Overflow: clip
• overflow-clip-margin

Support

• overflow: clip
• overflow-clip-margin

Summary

Overflow content is clipped at the element's overflow clip edge that is defined using the overflow-clip-margin property. As a result, content overflows the element's padding box by the value of overflow-clip-margin or by 0px if not set. Overflow content outside the clipped region is not visible, user agents do not add a scroll bar, and programmatic scrolling is also not supported. No new formatting context is created. To establish a formatting context, use overflow: clip along with display: flow-root. The element box is not a scroll container.

My guess is flow-root may help with scroll performance if needed.

Recap

In theory, this could help solve this issue. At least in isolation in ReadiumCSS, it is working as expected as a fix – of course it’s another story in apps injecting ReadiumCSS.

Anyways, adding the following deals with all the overflow issues:

:root {
  overflow: clip;
}
body {
  overflow: clip;
  overflow-clip-margin: content-box;
}

You need both overflow: clip in :root and body.

As a reference, no overflow is set and you can see the link doesn’t wrap and may flow into the next column:

Without overflow-clip-margin, this is what happens with a link that doesn’t wrap. You can still see it overflow in the “page margins” (which is padding added to columns).

With overflow-clip-margin: content-box, it works as you would expect, as the link doesn’t overflow any longer.

I’ve checked and element.scrollLeft and transform: translateX() work as expected in JS. At least it doesn’t break it.

Issues

Update: Turns out the support tables you can find on popular websites were wrong…

As far as ReadiumCSS is concerned, mainly support, which means this would fix overflow issues for the latest versions of browsers/webviews, but only partially due to the support of overflow-clip-margin:

• it’s not supported in Safari/iOS It is supported in Safari/iOS
• it’s only supported if overflow: clip is set for both axes in Chromium (i.e. you can’t set overflow-x: clip only)
• content-box is not supported in Firefox nor Safari

As far as apps are concerned, this is unknown.

Conclusion

This is not ready for prime time, another solution should be explored. has potential as a progressive enhancement. However, this means previous versions that do not support it have to rely on overflow: hidden – it’s used in other Reading Systems though, so it’s a confirmation of sorts that it can help alleviate this issue.

[fondoger]

Does the below code resolve the issue?

overflow-wrap: break-word;

[JayPanoz]

@fondoger Thanks for weighing in and pointing that out.

From initial testing it created some issues and didn’t necessarily offer the best expected results, especially in hyphenated contexts.

However, it’s something that might be revisited in the future, with the implementation of version 2 in toolkits. We will have to pay a particular attention to the overflow issue for practical reasons so I’m expecting additional effort being spent in the upcoming weeks.

[SH-github0]

Hey! Will this issue be ever resolved?

[JayPanoz]

@SH-github0 In version 2, overflow-clip has been implemented as a progressive enhancement.

Other than that, the safeguards’ selector for long strings has been slightly improved but, as always, the limitation lies in the publication’s markup – which is the reason it is a frustratingly complex issue to solve.

Note the safeguard is not using !important so that it can be disabled in order to use another option, should authors/publishers want to do that.

But if we are talking about a bulletproof solution, I’m afraid we have not been able to find that yet.

[SH-github0]

I am not a developer, so I cannot precisely say how to fix it. I am just a reader, and I use Aldiko, where I had faced this issue. On contacting Aldiko, they pointed me here.

But I have faced this issue only on readium based apps, like Aldiko and Thorium.

Same epub files on other open-source apps like calibre do not face this issue. Perhaps you could check how they have implemented it?

[SH-github0]

Also, after looking up a bit, doesn't overflow-clip, well, clip off the overflowing words? That doesn't seem very helpful for reading. As I said earlier, calibre deals with this by wrapping the overflowing text onto the next line, and so do commercial apps like Play Books, Kindle and Kobo. Is something similar not possible here?

I read earlier that someone suggested break-word as a possible solution. The response was that it caused problems in some special “hyphenated contexts”. I get that edge cases exist, but losing part of the text entirely feels like a much bigger issue. Can’t the wrapping be fixed first, and edge cases handled later?

[JayPanoz]

Sorry I’ve had very little time available for ReadiumCSS due to work being done in other Readium-related projects. I’m only catching up just now.

Same epub files on other open-source apps like calibre do not face this issue. Perhaps you could check how they have implemented it?

Believe it or not but what is already in place for dealing with this was heavily inspired by other apps as we needed to keep things consistent as well for publishers/authors/ebook designers.

But a lof of apps/distributors are also modifying files to solve various issues – something ReadiumCSS can’t do because it’s just a library of stylesheets making its best effort to apply styles on top of the ones in the publication.

Also, after looking up a bit, doesn't overflow-clip, well, clip off the overflowing words?

This is only part of the improvements meant to solve different issues e.g. large tables for instance, as they are overflowing into the next page currently. There, ReadiumCSS can’t do miracles, app developers have to implement something to handle that smartly e.g. displaying a simpler preview and making tables zoomable, etc.

I can reassure you I’m not seeing this as a good-enough fix for long words, far from it.

We actually have planned a round of Research and Development to see if the situation is any better than the last time we tried so I’ll keep participants updated here.