The editor supports formatting options that are not respected when the epub table is generated. For example, borders are added no matter what and the first row is assumed to be a header. In so far as possible, the formatting of individual tables in the editor should be preserved in the generated epub code.
Background: How to get tab stops into epub
Have you had a look at the Tables & Lists compile format option pane, yet? There are a few different table styles given, with previews so you can see what it will look like before compiling. You can see the actual formatting they implement though, in the CSS pane (right column)—and that pane, in the left column, is where you could override aspects of the design. This is how you could remove the borders and make the heading row using a normal font weight, for example.
ePub uses HTML and CSS, not rich text formatting like the text editor does (which also answers your question about tab stops, those are a paper-based tool that make very little sense in an environment where the display can be anywhere between the width of a credit card or a giant television screen), and on top of that, the compiler uses Markdown to create the HTML, which itself doesn’t relay specific formatting other than column alignment.
Many thanks! Is this what you mean?
I don’t see any option for no borders or to negate the assumption that the first row is a header. Besides, this is an override for all tables, but the editor allows specfic formatting of individual tables.
You write “You can see the actual formatting they implement though, in the CSS pane (right column)—and that pane, in the left column, is where you could override aspects of the design. This is how you could remove the borders and make the heading row using a normal font weight, for example” I don’t see any such pane in Tables & Lists. Could you provide a screenshot that shows how to do what you describe?
I’m sure I’m being very naive, but when you say “the compiler uses Markdown to create the HTML, which itself doesn’t relay specific formatting other than column alignment.” I would reply by asking why the compiler uses an inadequate technique.
The wish is only that the compiler use the features of HTML tables, not that it do the impossible. My HTML is a little rusty, but I’m pretty sure I could write the HTML that renders my little tables the way I want, and all the clues are there in the editor, so, naively, I have to ask what is impossible here?
The idea that one has to tweak the results of the compilation by hand is not generally feasible: These are what are known as “downstream changes” and are the ruin of an efficient process. Everything done by hand has to be done before the process of compilation starts. After that, the results must be right without further manual intervention.
Please note that Scrivener has never promised to do this, for any output format.
It’s possible to send raw HTML through to the output document if you like.
Noted! IMHO it’s a pity that the goal isn’t a little more ambitious, but I don’t have to implement a solution so I’m ignorant of the issues. 
Maybe escaping to raw HTML is a workable solution. For this book I only have two little tables and I’m going to use the hack at How to get tab stops into epub - #12 by ds.
Without trying to sound like a know it all (and probably failing!), it seems to me using Markdown as an intermediate compilation language (which is how I understand the statement “the compiler uses Markdown to create the HTML”) is not the best solution. Translating from a more expressive language like the editor’s to a less expressive language like HTML is always going to present problems, but going via a language that is even less expressive than HTML–Markdown–only increases the problems. Why not just generate HTML directly? There’s no rocket science in that.
Just curious–and sorry to be a pain in the ass!
P.S. Don’t get me wrong: I love Scriviner! The editor and “binder” environment is really well done. The way through the compilation process is pretty well done. And the PDF output is good enough for the purpose of my little book.
P.P.S. If the editor representation is RTF then maybe a tool that goes directly from RTF to HTML could work. Five minutes searching found this: GitHub - lvu/rtf2html: RTF to HTML converter for use both with your applications and as a standalone tool. Small and fast. Processes tables better than any other tool I've seen..
I think maybe there is a matter of there being two threads about the same topic at this point? I followed the link to the one at the top, and found much of what I described in my post above has already been gone over in greater detail, on how you can control the formatting the book with CSS, in the main CSS pane. You have the final word on what things look like in the vast majority of cases.
So I’ll keep this more abstract, as any more technical discussion of table formatting should probably be kept over there.
You mention not wanting to have to edit the ePub after compiling, and hopefully the solutions given over there address the notion that this is hardly ever necessary with Scrivener. I do use Sigil for design, because of its real-time environment; it is ideal for that. But I always copy and paste my designs back into the compile settings so that from that point forward they are baked into what I get when I click the compile button. There are maybe only one or two things I can think of that would require post-compile editing, and they involve getting resources into the ePub that Scrivener doesn’t support, like custom fonts for headings and video media. You can set it all up in Scrivener so that all you have to do is drop those files into the ePub, it’s a 5 second thing.
As for why Markdown is used for HTML production, quite simply its because the text engine Apple provides is in the dark ages when it comes to that. It cannot produce HTML 5, which is what ePub 3 needs. I suppose we could spend months making our own HTML generator from scratch, but this addresses 99% of what people do, and it was bootstrapped off of existing code that was built to make Scrivener a better Markdown production environment in the first place. So it just made sense, and continues to make sense in my opinion.
To clarify one thing, it isn’t entirely Markdown, it’s a bit of a hybrid, which is how you do get formatting that Markdown can’t do, like highlight and text colours (well, I say that, but Markdown can do that in 2024, but back when this was all put together it couldn’t). Basically your text is converted to Markdown, that generates super clean HTML5 with minimal effort (something not easy to achieve with RTF conversion), and then that is marked up even further with custom HTML output in a selective fashion.
As for why tables don’t benefit from this bespoke treatment, in short its a matter of demand. Tables are not commonly used in ePub, in large part because many ebook readers do a poor job of rendering them in the first place. This is so true there is even a flag in the compiler that will convert tables to an image on the fly because that is sometimes better for compatibility depending on the market audience. On top of that, I think most people who do use them are satisfied with one unified look for them, rather than having multiple table designs. So we’re talking about a percentage of a percentage of a percentage here.
And, to get back to the solutions, Scrivener already has good answers for all of the above that don’t involve a lot of development time. Or to put it another way, the development time has been spent on giving you more power over the output rather than having less power and more automation. That is perhaps a philosophical difference. You wrote, in the other thread, that you shouldn’t have to make your own table designs, and even to the extent that having to do so indicates a “bug”, but we feel otherwise.
I’ll post some further ideas of a more technical nature in the other thread.
Thanks so much for taking all this time and trouble about my small problems.
I have honestly never used a SW tool in my long professional life that was as well supported as this one is!
My status is that I have the content of my little book in place and am only doing some revising and tweaking. The PDF looks good. The epub is acceptable (with the table hack), so all I need is a fix for the misplaced div or whatever it is (Epub output errors in new 3.4. release). The fix has to be straightforward and I would expect a hot fix release couldn’t take long. So my plan is to publish both formats at KDP in early January.
I never could have achieved this without the outstanding support!
Whether I write another book after that, and how challenging that would turn out to be in Scriviner, I have no idea, but I have certainly learned a lot in the last two months! Thank you!
