CSS compatibility width: fit-content

[ElMiko]

Is there any chance of getting KOReader to accept the width: fit-content property/value?

[ElMiko]

Nothing?

I'm really struggling to understand what CSS elements and properties are compatible with KOReader, and why. I have yet to find a program that reliably gives the user as much control over his/her reading experience as KOReader, but the advanced CSS formatting that it interprets versus that which it ignores is a black box. I understand (and, frankly, align with) the reticence to make KOReader integrate the multimedia elements of ePub3 design, but I am left puzzled by what appears to be an abitrary implementation of modern HTML formatting.

Is there at least any sort of reference guide for what works in KOReader and what doesn't? And what (if any) additional HTML/CSS functionalities are likely to be incorporated?

[Frenzie]

https://wiki.mozilla.org/QA/Minimal_Test_Cases

fit-content is already supported, so without a minimal testcase there isn't really anything to say.

I am left puzzled by what appears to be an abitrary implementation of modern HTML formatting.

The fact that Netsurf is quite similar in end result suggests it's closer to inevitable than arbitrary.

Is there at least any sort of reference guide for what works in KOReader and what doesn't? And what (if any) additional HTML/CSS functionalities are likely to be incorporated?

Mainly https://github.com/koreader/crengine...t.cpp#L38-L315

As for what would be added, basically whatever piques someone's interest. Doing preparatory work like providing minimal testcases increases the pique factor.

[ElMiko]

Originally Posted by Frenzie

https://wiki.mozilla.org/QA/Minimal_Test_Cases

fit-content is already supported, so without a minimal testcase there isn't really anything to say.

Sorry, the Google AI overview (which we all know has never been wrong) reported that fit-content is not well-supported by KOReader, which seemed to confirm my personal experience, prompting the original post. I've attached a sample epub file with the replicated code that is getting jammed up in KOReader.

The goal is to have a block of text that is centered in the page but with its contents variably aligned within that block, and constrained by the width of its contents [see FitContentCORRECT.jpg].

Unfortunately, in KOReader, it seems to be ignoring the fit-content value and occupying the full width of the screen (excluding the 5% L/R padding). [see FitContentWRONG.jpg]

[Frenzie]

It looks like the "correct" screenshot for me. You're most likely using an old version or you've changed some render setting.

[ElMiko]

Originally Posted by Frenzie

It looks like the "correct" screenshot for me. You're most likely using an old version or you've changed some render setting.

Thanks for looking into this @Frenzie.

I updated and now am getting something similar to what your seeing, but it's still not actually "fitting to content". As you can see from your screenshot, the lines are breaking when they shouldn't be—the "padding" is way more than 5% on either side.

EDIT: I think I see what's happening... It's applying the padding after the fit-content, so the content will always render as less than its full width. Presumably, setting the padding to zero and wrapping the whole element in a div with 5% L/R margins will get around this, right?

EDIT2: Okay, so there are two approaches here that would work, I think. One is the div wrap, which would be most useful with absolute value margins (e.g. 2em). The other is a max width property within the blockquote itself, which would be most useful for relative boundaries.

[Frenzie]

More in https://github.com/koreader/crengine...on_r3107195648

[ElMiko]

Originally Posted by Frenzie

More in https://github.com/koreader/crengine...on_r3107195648

Okay, interesting; so this was not necessarily intended. I never really know how something is supposed to look because so many html engines have idiosyncratic differences. And to be honest, I'm not even sure that KOReader is doing it "wrong" in any logical sense... every time I try to parse the "fit-content" behavior described, my brain breaks. I know that it defines the padded content a certain way in Sigil, Calibre and Sigil's Page-Edit plugin, while doing it differently in KOReader. What I don't know is which of the two approaches is logically "right." Broadly speaking, is the padding supposed to "push" the boundary out or is it supposed to compress the contents within the boundary?

In any case, do you know if the workarounds would stop working if KOReader were to align itself with the Sigil/Calibre-type rendering? (FWIW, the workarounds also appear to function as desired in Calibre and Sigil, but that's hardly a guarantee of anything.)

EDIT: The two workarounds do seem to work correctly in KOReader currently, too.

[Frenzie]

Broadly speaking, is the padding supposed to "push" the boundary out or is it supposed to compress the contents within the boundary?

Normally padding compresses the contents within the boundary, but fit-content specifies that text should go for the max width without overflow before soft-wrapping. I'm not entirely sure how that would interact with padding from a quick glance at the spec though.

In any case, do you know if the workarounds would stop working if KOReader were to align itself with the Sigil/Calibre-type rendering?

In principle it shouldn't stop working.

[ElMiko]

Originally Posted by Frenzie

Normally padding compresses the contents within the boundary, but fit-content specifies that text should go for the max width without overflow before soft-wrapping. I'm not entirely sure how that would interact with padding from a quick glance at the spec though.

Yeah, it appears it creates an order-of-operations paradox, which is probably why the current KOReader rendering and the Sigil/Calibre/Et al. rendering can be internally logically consistent but contradictory to each other.

I'm a little torn now. The Sigil rendering is apparently more commonly adopted, but the KOReader logic is more psychologically soothing. However, I'm fairly confident that the KOR devs didn't conceive of this app with satisfying my mental tics as their principal concern... (and, as per the following paragraph, it appears that my workaround doesn't actually work as well as I'd like, either.)

One note about my workarounds (in case anyone is perversely curious): the <div> wrapper solution doesn't play nice with top/bottom margins defined in percentage values at the blockquote level. Presumably, this has something to do with the div wrapper altering the frame of reference by which that percentage would be calculated, rather than just the height of the page. So perhaps not a perfect solution after all...

[Frenzie]

It'll be fixed in https://github.com/koreader/crengine/pull/662

[rjwse@aol.com]

It is not widely acceptable yet but calibre's viewer can 'contain' font size and therefore container width in the calibre viewer and the calibre text editor. In the viewer you can vary number of columns with ctrl-[ and ctrl-] and 'uncontained font size' with ctrl-minus and ctrl-plus. The text editor lets you vary 'file preview' with edge dragging and font size with track pad. I don't suppose this works well in ebook readers yet.