List-like formatting question...

[Quoth]

I'd never use tables (or frames) for lists. A <p class="my-custom-list-1"> etc works fine and renders on epub2, and converts to azw3/KF8 or KFX or epub3.

Indeed I avoid tables, and on epistolary content from Gutenberg I convert the two columns to alternating paragraphs, which is easier to read. That's less than ideal for bilingual texts that use facing pages (only works on PDF & Landscape tablet) or columns in a table, but actually works on a smaller (anything less than 8″) screen.

Automatic from a docx paragraph style in LO Writer without using "list" property via Calibre.

[ElMiko]

@phillipgessert - Thank you for that info. Particularly that when things break they are unlikely to break consistently across platforms. That's fundamentally what I think I was trying to get some clarity on (in this question and many others I've asked): is there a one-size-fits-all solution. The answer, it seems, is a resounding "No".

[DNSB]

Originally Posted by ElMiko

@phillipgessert - Thank you for that info. Particularly that when things break they are unlikely to break consistently across platforms. That's fundamentally what I think I was trying to get some clarity on (in this question and many others I've asked): is there a one-size-fits-all solution. The answer, it seems, is a resounding "No".

Not only is there no one size fits all solution, there isn't even a decent one size fits most solution for pretty much any formatting beyond an ebook that looks like a text file. When not working on ebooks for my own use, I tend to format ePubs for Kobo apps and ereaders with conversion to Amazon KF8/KFX for Amazon apps and ereaders and a vanilla ePub2 for other brands of ereaders.

[ElMiko]

Yep, that's definitely the message I'm hearing. Fortunately, this is in the context of personal use, so for the time being I don't have to stress too much. On the other hand, I'm thinking of switching e-reader platforms some time in the not too distant future, so a library-wide reformat may be on the menu. Will cross that bridge if/when I get to it, though.

[ElMiko]

Originally Posted by RbnJrg

Read the following article:

https://www.digitalocean.com/communi...s-inline-block

@RbnJrg - So, I'm still struggling to see the difference between float and in-line block. They boy seem to make the element "float". Is it that the formal "float" will only work in terms of floating all the way right or all the way left, whereas inline-block can "float" relatively throughout a given element?

[RbnJrg]

Originally Posted by ElMiko

@RbnJrg - So, I'm still struggling to see the difference between float and in-line block. They boy seem to make the element "float". Is it that the formal "float" will only work in terms of floating all the way right or all the way left, whereas inline-block can "float" relatively throughout a given element?

Maybe this can help you:

  <h2>Example on inlined blocks</h2>

  <p><span class="col1">A label</span><span class="col2">The text asociated to the label on the left. As you can see this text does not surround the previous one</span></p>

  <h2>Example on floated blocks</h2>

  <p><span class="col3">A label</span><span class="col4">The text asociated to the label on the left. As you can see this text does surround the previous one</span></p>

.col1 {
  display: inline-block;
  width: 20%;
  vertical-align: top;
  background: lightgreen;
}

.col2 {
  display: inline-block;
  width: 80%;
  vertical-align: top;
  background: lightblue;
}

.col3 {
  float: left;
  padding-right: 4px;
  background: orange;
}

.col4 {
  background: khaki;
}

However, if in .col4 you add the properties:

  float: right;
  width: 80%;

apparently they have a similar appearance. BUT the solution with "display: inline-block" keeps the blocks together (they have the "page-break-inside: avoid" property implicit), and that doesn't happen when the blocks are floating.

[ElMiko]

Originally Posted by RbnJrg

apparently they have a similar appearance. BUT the solution with "display: inline-block" keeps the blocks together (they have the "page-break-inside: avoid" property implicit), and that doesn't happen when the blocks are floating.

THIS is the explanation I was looking for. Thank you for articulating it so clearly!

Does this mean that two adjacent "inline-block" <p> elements will also want to run together?

[RbnJrg]

Originally Posted by ElMiko

THIS is the explanation I was looking for. Thank you for articulating it so clearly!

Does this mean that two adjacent "inline-block" <p> elements will also want to run together?

Yes, they will. And if they are at the end of the page, and the user increases the font-size, the text inside the blocks won't break; both blocks will go to the next page. It won't have part of the text at the end of the page and part of the text at the start of the next page; all the text will remain joined.

With the floating method you can have similar results if you add the properties "page-break-inside: avoid", "break-inside: avoid" and "-webkit-column-break-inside: avoid" but all these properties are implicit in inlined blocks. But with one caveat: while the "display: inline-block" property is supported by virtually all e-readers (including ADE), the "page-break-inside: avoid," "break-inside: avoid," and "-webkit-column-break-inside: avoid" properties are not supported by all e-readers.

[ElMiko]

This is kind of tangential, but related to how elements break, particularly in the context of actual e-readers: if you use "white-space: nowrap" on a string of text, but the text is longer than what fits on the reading screen (either because it's a small screen or because the user has significantly increased the font-size), how do e-readers render that? Will it just break the text at the last character that fits? Will it just "display" the excess text off screen? Will it burst into flames?

[RbnJrg]

Originally Posted by ElMiko

This is kind of tangential, but related to how elements break, particularly in the context of actual e-readers: if you use "white-space: nowrap" on a string of text, but the text is longer than what fits on the reading screen (either because it's a small screen or because the user has significantly increased the font-size), how do e-readers render that? Will it just break the text at the last character that fits? Will it just "display" the excess text off screen? Will it burst into flames?

Read this:

https://www.w3schools.com/cssref/pr_...hite-space.php

and this:

https://www.w3schools.com/cssref/pla...&preval=nowrap

and this:

https://www.w3schools.com/cssref/css...t-overflow.php

and this:

https://www.w3schools.com/cssref/pla..._text-overflow

[ElMiko]

Sorry, I wasn't clear with my question: is that how ereaders will treat it? For example, I know that with words that are longer than the screen width, some e-readers will break them automatically. I'm assuming (perhaps erroneously) those e-readers might treat "nowrap" strings similarly.

[RbnJrg]

Originally Posted by ElMiko

Sorry, I wasn't clear with my question: is that how ereaders will treat it? For example, I know that with words that are longer than the screen width, some e-readers will break them automatically. I'm assuming (perhaps erroneously) those e-readers might treat "nowrap" strings similarly.

It's a bit difficult to explain. With "white-space: nowrap" ereaders in one page should show only the portion of text that fits within the screen width. Anything beyond that is carried over to the next page and overlaps the text that might otherwise be there. To avoid this overlap, the string is usually truncated with the following properties (both must apply):

.nw {
  white-space: nowrap;
  overflow: hidden;
  text-overflow: ellipsis;
}

Of course, of this way the string is truncated. If you want to see the whole string, then employ "overflow: auto" and "text-overflow: clip".

[ElMiko]

Hmmm... wouldn't the "text-overflow: clip" clip/truncate the text?

Or, perhaps better stated: why wouldn't the "text-overflow: clip" clip/truncate the text? Will the "overflow" override the clip? But not the "white-space: nowrap"?

[RbnJrg]

Originally Posted by ElMiko

Hmmm... wouldn't the "text-overflow: clip" clip/truncate the text?

Or, perhaps better stated: why wouldn't the "text-overflow: clip" clip/truncate the text? Will the "overflow" override the clip? But not the "white-space: nowrap"?

Do the try and you'll see The property "text-overflow: clip" (or "text-overflow: ellipsis") will truncate the text (because the text's lenght is wider than the screen due to the property "white-space: nowrap") when is joined with "overflow: hidden". But when you employ "overflow: auto", then a scroll bar will be added so you can watch the full text.

[ElMiko]

Okay, but e-readers don't generally allow scroll bars, right?

Perhaps a little context from me here would be helpful:

What I'm trying to solve for here is transcript-like formatting where the speaker name/title is in the left column and the dialogue is in the right. I want to avoid word wrapping the "name/title" column unless, of course, the font size has been set so large that it wouldn't fit on the screen. Another way of saying it is, I want the column width of the left column to be equal to the width of the longest string of text it contains, no more and no less.

My approach has been to use "nowrap" on the left column to ensure that it doesn't wrap if it's longer than 50% of the screen width. However, my concern is that using this method, if someone sets the font size too large, the text from the left column could disappear off the right side of the screen. Granted, in most cases, for this to happen the font-size would have to be pretty big or the screen would have to be pretty small (e.g. phone-sized), but it's still technically possible.