List-like formatting question...

[ElMiko]

I know which of these is easier, but I'm wondering which is the most likely to produce consistent results across e-readers, and what the "failure" scenarios would look like. What I'm trying to accomplish is a kind of list-like styling that retains its justification without changing the distance between the "bullet" and the "text". (Consequently, a straight-forward hanging indent won't do the trick).

CSS:

.litem {
	text-align: justify;
	margin: 0 0 0 4em;
	}
span.lbullet {
	font-weight: bold;
	float:left;
	margin: 0 1em 0 -4em;
   }

CODE:

<p class="litem"><span class="lbullet">A (1 [c])</span> Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua.

or...

CSS:

td.tdlefths {
	font-weight: bold;
	margin: 0;
	padding: 0;
	text-align: left;
	vertical-align: top;
	white-space: nowrap;
	}
td.tdrighths {
	padding: 0 0 0 1em;
	margin: 0;
	text-align: left;
	vertical-align: top;
	}
.left {
	margin: 0;
	text-align: left;
	}
.just {
	margin: 0;
	text-align: justify;
	}

CODE:

  <table>
    <tbody>
      <tr>
        <td class="tdlefths">
          <p class="left">A (1 [c])</p>
        </td>

        <td class="tdrighths">
          <p class="just">Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua.</p>
        </td>
      </tr>
    </tbody>
  </table>

In my experience, and particulularly when converting to other formats, both floats and tables can get real wonky...

In the first scenario, I see the potential for issues if there are multiple list items with variable length "bullets", resulting in disalignment across the "text" elements (i.e. distance between the bullet and the text will be preserved, but the text will vary relative the left-most marging depending on the length of the "bullet"). The second scenario is just very busy and, like i said, the use of the <table> element makes me a little skeptical.

To be clear, if there are other suggestions out there, I'm open to those too, but again, it'd be helpful to know what the failure scenarios are (knowing that there is no "one-size-fits-all" solution in the world of ebooks).

[nabsltd]

Why is it that CSS standard lists won't result in the correct display?

In other words, if you are looking for some way to create lists that work on platforms that don't support CSS lists, then my answer would be to ignore those platforms. CSS lists have been around since version 1 of CSS and any reader that doesn't support at least the basic CSS list properties probably isn't worth targeting.

[Turtle91]

Originally Posted by nabsltd

Why is it that CSS standard lists won't result in the correct display?

In other words, if you are looking for some way to create lists that work on platforms that don't support CSS lists, then my answer would be to ignore those platforms. CSS lists have been around since version 1 of CSS and any reader that doesn't support at least the basic CSS list properties probably isn't worth targeting.

Exactly!


Worst case - if you realllllllly need to support those really bad/old renderer's...have a second css file.

[KevinH]

FWIW, from an Accessibility framework, using a normal list (ordered or unordered) styled the way you want with CSS, is much better as the tags themselves document exactly what you are trying to achieve. So no additional aria role information is needed.

A long time ago, someone wrote a popular "create an epub" guide and advised people to create their own headings from P tags, their own list (instead of list tags), use tables or blockquotes for indentation, and etc..

That one popular guide did more to damage the creation of epubs for accessibility (and in general) than anything else. I am constantly see people creating headings from paragraphs instead of css styling the h1-h6 tags themselves.

Tags have names that reveal both structure and meaning and they should be used. Using the right tags will not hold back the visual display when you can use css to style just about anything any way you want. Using the proper tags is very important for accessibility, archiving, and search of any digital publication.

Sermon done.

[ElMiko]

Originally Posted by nabsltd

Why is it that CSS standard lists won't result in the correct display?

To my knowledge, there is very limited flexibility on the list markers (ordered or unordered). For example, I don't know how to specify the desired list "number" as shown in the examples using ol/ul/li css...

EDIT: to be clear, I have seen some CSS-based workarounds for custom bullets..

e.g.

ul {
  list-style: none;
  margin-left: 0;
  padding-left: 0;
}

li {
  padding-left: 1em;
  text-indent: -1em;
}

li:before {
  content: "+";
  padding-right: 5px;
}

but that doesn't work for a multiple-item ordered list.

[KevinH]

With ol and ul you can set your own marker images. That has existed for quite some time now.

Sublists can use different css styles and also different marker images.

Newer css supports the ::marker css which means fully custom and emojis can be used as markers.

[ElMiko]

Okay, but I'm not talking about images... Am I misunderstanding your post?

are your referring to this type of code:

ul li::marker {
  content: "@ ";
  color: pink;
  font-size: 25px;
}

If so, I don't see how that addresses my initial point either. I don't see how it would allow me to create an ordered list with the format: 1(a.i), 1(a.ii), 1(b), 2(a)...

[enuddleyarbl]

I could be misunderstanding what you're looking for. But, how about this?


The HTML (keeping track of the various nestings of the ul and li elements is a pain in the Calibre Editor -- and EDIT: I mistakenly used the ul (unordered list) instead of ol (ordered list). But, it still seems to work.):

<p class="headline">Nested Lists</p>

  <p>Lists can be nested by simply putting the nested list immediately following an earlier list’s element (put that element’s closing tag AFTER the nested list’s closing tag):</p>

  <ul class="ol_arabic">
    <li>Coffee
    <ul class="ol_lowalpha">
      <li>with cream
      <ul class="ol_lowroman">
        <li>dairy</li>
        <li>non-dairy</li>
      </ul></li>
      <li>with sugar
        <ul class="ol_lowroman">
          <li>sucrose</li>
          <li>glucose</li>
        </ul></li>
    </ul></li>
    <li>Tea
      <ul class="ol_lowalpha">
        <li>Black tea</li>
        <li>Green tea</li>
      </ul></li>
    <li>Milk</li>
  </ul>

The CSS:

.ol_arabic {
  /* Ordered List Class for Arabic Numbers (Safer to use UL) */
  display: block;
  list-style-type: decimal;
  margin-left: 1.2em;
  margin-right: 1.2em;
}
.ol_lowalpha {
  /* Ordered List Class for Uppercase Alphabetic "Numbers" (Safer to use UL) */
  display: block;
  list-style-type: lower-alpha;
  margin-left: 1.2em;
  margin-right: 1.2em;
}
.ol_upalpha {
  /* Ordered List Class for Uppercase Alphabetic "Numbers" (Safer to use UL) */
  display: block;
  list-style-type: upper-alpha;
  margin-left: 1.2em;
  margin-right: 1.2em;
}
.ol_uproman {
  /* Ordered List Class for Uppercase Roman "Numerals" (Safer to us UL) */
  display: block;
  list-style-type: upper-roman;
  margin-left: 1.2em;
  margin-right: 1.2em;
}
.ol_lowroman {
  /* Ordered List Class for Lowercase Roman "Numerals" (Safer to us UL) */
  display: block;
  list-style-type: lower-roman;
  margin-left: 1.2em;
  margin-right: 1.2em;
}

[phillipgessert]

Originally Posted by KevinH

FWIW, from an Accessibility framework, using a normal list (ordered or unordered) styled the way you want with CSS, is much better as the tags themselves document exactly what you are trying to achieve. So no additional aria role information is needed.

A long time ago, someone wrote a popular "create an epub" guide and advised people to create their own headings from P tags, their own list (instead of list tags), use tables or blockquotes for indentation, and etc..

That one popular guide did more to damage the creation of epubs for accessibility (and in general) than anything else. I am constantly see people creating headings from paragraphs instead of css styling the h1-h6 tags themselves.

Tags have names that reveal both structure and meaning and they should be used. Using the right tags will not hold back the visual display when you can use css to style just about anything any way you want. Using the proper tags is very important for accessibility, archiving, and search of any digital publication.

Sermon done.

Out of curiosity, is this the zen guide? That one drives me nuts every time it comes up.

[RbnJrg]

The solution by enuddleyarbl is very good but if you want to insist on your own list and numbering, use the following code, which is valid even for epub2:

1. In your .xhtml file:

  <p class="list"><span class="col1">1(a.i)</span><span class="col2">This is the text for the first item in the list</span></p>

  <p class="list"><span class="col1">1(a.ii)</span><span class="col2">This is the text for the second item in the list</span></p>

  <p class="list"><span class="col1">1(a)</span><span class="col2">This is the text for the first item in the list</span></p>

  <p class="list"><span class="col1">1(b)</span><span class="col2">This is the text for the second item in the list</span></p>

2. In your .css stylesheet:

p.list {
  margin: 0;
}

.col1 {
  display: inline-block;
  width: 15%; /* you can play with this percentage */
  padding-right: 10px; /* you can play with the padding value */
  margin: 0;
  vertical-align: top;
  text-align: right;
}

.col2 {
  display: inline-block;
  width: 76%; /* you can play with this percentage */
  padding: 0;
  margin: 0 5% 1em 0; /* you can play with the margin-right percentage */
  vertical-align: top;
  text-align: justify;
}

Here you have a screenshot:



Take into account that the percentage of .col1 plus percentage of .col2 plus percentage of margin-right must be lower than 99% (because of the padding of .col1). Of course, this aproximation under epub2 is very sensitive to changing the font size. You can minimize this danger by increasing the size of the first column and reducing the size of the second. To get a dinamic layout to automatically change column widths as the font size changes, you need to work in epub3. Below you can check the respective epub2.

[KevinH]

Originally Posted by phillipgessert

Out of curiosity, is this the zen guide? That one drives me nuts every time it comes up.

I think so. And then there was one other that followed it up really early on that kind of supported it.

I threw out my own pdf copy years ago in disgust so I can not give you an exact citation.

In their defence a lot of it was caused by horrible limitations in html 3.2 and css 1.0.

Luckily those days are long gone now.

[ElMiko]

Thank you ennudleyarbl and RbnJrg for your help.

And yes, RbnJrg, that's exactly what I was looking for. I'm curious, though, how does the use of "inline-block" differ from float? That is, on the surface, they appear to be doing a visually indistiguishable thing here, but surely there's a subtle difference that I'm not catching. Is it the wrapping behavior of the two elements? I see that they detatch in the Sigil Preview window if it's narrow enough (presumably would do so on, like, a phone screen too), whereas the float (and table) css did not.

Also, is it necessary to define the width for the col2 span? I've tried toggling it on and off, and it doesn't seem to affect the wrapping behavior one way or another...

[RbnJrg]

Originally Posted by ElMiko

And yes, RbnJrg, that's exactly what I was looking for. I'm curious, though, how does the use of "inline-block" differ from float? That is, on the surface, they appear to be doing a visually indistiguishable thing here, but surely there's a subtle difference that I'm not catching. Is it the wrapping behavior of the two elements?

Read the following article:

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

I see that they detatch in the Sigil Preview window if it's narrow enough (presumably would do so on, like, a phone screen too), whereas the float (and table) css did not.

Also, is it necessary to define the width for the col2 span? I've tried toggling it on and off, and it doesn't seem to affect the wrapping behavior one way or another...

That is because you disable the width of .col2. If you don't set a width, then it will be by default 100% and then you see the following output:



In order for the .col2 element (box) to be next to the .col1 element (box), you have to define a width for .col2 such that, when added to the width of .col1, it is less than 100%. As long as this is respected, unless the screen width is very narrow, .col1 will always have a width of 15% of the total width, while .col2 will have a width of 76%. However, if the user sets a large enough font size, the text in .col1 may overlap the text in .col2.



But as you appointed, if the screen width is very narrow, you can't avoid UNDER EPUB2, to get outputs like the following:



But set the width of .col2.

[ElMiko]

Yup. Just to be clear, the image i posted WAS with your original code (setting width to 76%). BUt as you say, with a narrow screen it'll split.

Would it be safe to summarize the three methods' pros/cons as:

1) (float method) Pro: displays relationship between bullet and text consistently and replicates list-style formatting. Con: variable bullet lengths will affect the left margin of the text.
2) (table method) Pro: displays relationship between bullet and text consistently and replicates list-style formatting. Con: very busy code.
3) (inline-block method) Pro: bullet length will not affect the left margin of the text. bullet and text element will separate on narrow viewing windows (e.g. cell phones).

...and then, additionally, all three lack the semantic/accessibility info of ol/ul list css.

Is there another "con" to the table method that I'm not articulating? I could've sworn that non-giant e-readers tend to struggle with tables...

[phillipgessert]

Originally Posted by ElMiko

Yup. Just to be clear, the image i posted WAS with your original code (setting width to 76%). BUt as you say, with a narrow screen it'll split.

Would it be safe to summarize the three methods' pros/cons as:

1) (float method) Pro: displays relationship between bullet and text consistently and replicates list-style formatting. Con: variable bullet lengths will affect the left margin of the text.
2) (table method) Pro: displays relationship between bullet and text consistently and replicates list-style formatting. Con: very busy code.
3) (inline-block method) Pro: bullet length will not affect the left margin of the text. bullet and text element will separate on narrow viewing windows (e.g. cell phones).

...and then, additionally, all three lack the semantic/accessibility info of ol/ul list css.

Is there another "con" to the table method that I'm not articulating? I could've sworn that non-giant e-readers tend to struggle with tables...

Downsides for the table method off the top of my head:

It's semantically incorrect as it isn't tabular data. I think maybe a case could be made that the numbers for an ordered list and the elements of that list do kind of constitute a table-like matrix, but it's a stretch.

Anywhere your styling fails, like one-off, oddball reading apps, could display these with borders, whether you want em to or not. Like your chosen styling won't necessarily fail gracefully—if it fails, it'll be "what's going on here" to the reader.

Tables with very high row counts can cause problems for Kindle / KDP. And the platform may display them scaled down, with an icon meant for zoom/pan, which is an oddity you might like to avoid.

Tables are much more of a PITA to reconfigure than lists are, should you have to.

HTML tables default to column width adjustment based on the content within the cells in ways that are kind of unintuitive (to me). There are CSS controls for it, but like above, if they fail, there's going to be all sorts of numeral > list item spacing inconsistencies if you've got one list full of short items and another full of long ones.

I'd assume these don't have high column counts, being that they're actually lists, but a ton of columns is probably the root of the con you cited yourself re: screen size.

Personally, the semantic part is what would bug me most. And the markup hassle would be close behind it.