View Single Post
Old 08-31-2021, 06:20 PM   #80
Tex2002ans
Wizard
Tex2002ans ought to be getting tired of karma fortunes by now.Tex2002ans ought to be getting tired of karma fortunes by now.Tex2002ans ought to be getting tired of karma fortunes by now.Tex2002ans ought to be getting tired of karma fortunes by now.Tex2002ans ought to be getting tired of karma fortunes by now.Tex2002ans ought to be getting tired of karma fortunes by now.Tex2002ans ought to be getting tired of karma fortunes by now.Tex2002ans ought to be getting tired of karma fortunes by now.Tex2002ans ought to be getting tired of karma fortunes by now.Tex2002ans ought to be getting tired of karma fortunes by now.Tex2002ans ought to be getting tired of karma fortunes by now.
 
Posts: 2,306
Karma: 13057279
Join Date: Jul 2012
Device: Kobo Forma, Nook
Quote:
Originally Posted by Hitch View Post
The reason that the rest of the schmucks here didn't even try it is because we KNOW that tables are murky at best, in ebook readers and that when they carry over multiple screens, as yours do, you are courting Mephistopheles.
Yes, exactly. Tables with cells with lots of text are horribly broken on many devices/readers.

And then imagine someone reading on a cellphone + a much larger font, you can easily overload it with a larger-than-screen cell. On many devices, poof, that text is now inaccessible because next page will be the next cell.

Not to mention Text-to-Speech issues. (Information in <table>s that aren't actually tables!)

Quote:
Originally Posted by Hitch View Post
And lastly--customer and client education is part of what we are required to do. SOMETIMES, you just have to tell a client that what they want is NOT DOABLE or that if you do, the fix may be worse than the illness. This, imho, is one of those times.
Similar to relying on CSS3 content. Heck, you can't even rely on start or list-style either.

It's one of the reasons why, sadly, instead of relying <ul> + <ol>... we tend to "hardcode" the lists.

Instead of:

Code:
<ol>
	<li>One</li>
	<li>Two</li>
	<li>Three</li>
</ol>
we recommend the hardcoded numbers:

Code:
<div class="ol">
	<p class="list">1. One</p>
	<p class="list">2. Two</p>
	<p class="list">3. Three</p>
</div>
The hardcoded list of numbers will never go wrong. Where <ol> can go wrong, especially if you:
  • rely on start
    • Starting at 100.
    • Counting by 2.
      • 1, 3, 5, 7
    • Skipping a number.
      • 1, 2, 5
  • Use more complicated anything-but-default numbering
    • Roman numerals = i, ii, iii
    • Greek Letters = α, β, γ
    • Old Hungarian*
    • (a)
    • [a]
    • a)
    • 1.1

Same with <ul>, there were many bugs across devices, so a:

Code:
<ul>
	<li>Item 1</li>
	<li>Item 2</li>
	<li>Item 3</li>
</ul>
we recommend the hardcoded:

Code:
<div class="ul">
	<p class="list">• Item 1</p>
	<p class="list">• Item 2</p>
	<p class="list">• Item 3</p>
</div>
When you have extremely basic lists, you'll still probably be fine with using <ol> or <ul>.

But once you start reaching more complicated cases, such as:
  • deeply nested lists
  • different-than-default bullets

then you start reaching the EPUB reader bugs.

This is where hardcoding lists would win out.

- - - - -

Side Note: Lists in EPUB are, sadly, one of the few cases where I go for less Accessibility + much uglier (and harder to maintain) code.

... But then you get maximum compatibility across real-world devices.

* Note: Old Hungarian, was an RTL runic language. Fascinating stuff. I only learned about it since LibreOffice recently added it for Lists + Page Numbering + Transliteration.

Last edited by Tex2002ans; 08-31-2021 at 06:38 PM.
Tex2002ans is offline   Reply With Quote