Replacing tables

[mrmikel]

I have been trying to replace tables in my epubs with divs and css.

As with tables, when the text size is increased, things get out of line with each other. In tables it seems a little more graceful a failure.

Is there any way to make the following div in a table track with the preceding one?

This is what I am doing:
CSS
.row {
width: 100%;
}
.col1{
float: left;
min-height: 1px;
width: 75%;
text-align: left}
.col2, .col3 {
float: right;
min-height: 1px;
width: 25%;
text-align: right; }
.clear {
border: none;
clear: both;

}
HTML
<div class='row'>
<div class='col1'>
Ordnance and ordnance stores
</div>
<div class='col2'>
$45,000,000 </div>



</div>

[RbnJrg]

Originally Posted by mrmikel

I have been trying to replace tables in my epubs with divs and css.

As with tables, when the text size is increased, things get out of line with each other. In tables it seems a little more graceful a failure.

Is there any way to make the following div in a table track with the preceding one?

This is what I am doing:
CSS
.row {
width: 100%;
}
.col1{
float: left;
min-height: 1px;
width: 75%;
text-align: left}
.col2, .col3 {
float: right;
min-height: 1px;
width: 25%;
text-align: right; }
.clear {
border: none;
clear: both;

}
HTML
<div class='row'>
<div class='col1'>
Ordnance and ordnance stores
</div>
<div class='col2'>
$45,000,000 </div>
</div>

I'm not undestand very well what you want to do (my english is very bad). But if you want to add new entries to your "fake" table (made of <div> selectors) then I think the easiest way is:

<div class='row'>
  <div class='col1'>
    Entry 1 - First Column<br />
    Entry 2 - First Column<br />
    Entry 3 - First Column<br />
    Etc...
  </div>
  <div class='col2'>
    Entry 1 - Second Column<br />
    Entry 2 - Second Column<br />
    Entry 3 - Second Column<br />
    Etc...
  </div>
</div>

Regards
Rubén

[mrmikel]

The problem is that the ereaders have buttons on them that let the reader increase the size of text on the screen.

What looks perfectly at the small size does not look good when the user makes the text size larger.
In this example, the text description on the left side of the screen takes up two lines, while the number stays on one line.

Here are two pictures. In the second, the last line has no number next to it because the lines above it take up two lines.

Is there some css that will make the right side follow the left side?

I hope I have been more clear this time.

[Tex2002ans]

Originally Posted by mrmikel

I have been trying to replace tables in my epubs with divs and css.

Hmmm... any specific reason you are trying to do this, instead of just using typical HTML tables?

I took a quick look around, and I stumbled upon this site, which has some sample CSS Table Code:

http://www.vanseodesign.com/css/tables/

I used that to derive code for your example:

<div id="table">
    <div class="row">
      <span class="col1">Ordnance and ordnance stores</span>
      <span class="col2">$45,000,000</span>
    </div>

    <div class="row">
      <span class="col1">Aircraft and aeronautical material</span>
      <span class="col2">29,775,000</span>
    </div>

    <div class="row">
      <span class="col1">Tanks and other vehicles</span>
      <span class="col2">15,000,000</span>
    </div>

    <div class="row">
      <span class="col1">Miscellaneous military equipment</span>
      <span class="col2">10,225,000</span>
    </div>
  </div>

CSS:

#table {
    display: table;
    width: 100%;
}

.row {
    display: table-row;
}

.col1 {
    display: table-cell;
    min-height: 1px;
    width: 75%;
    text-align: left;
}

.col2 {
    display: table-cell;
    min-height: 1px;
    width: 25%;
    text-align: right;
}

Here is the images showing how it works in ADE/Sigil/Nook:



I didn't do any further testing beyond that.

Anyway, don't ask me to explain how it works... It seems like you were missing "display" in your CSS... and the floats weren't helping:

http://www.w3.org/wiki/CSS/Properties/display

I am always interested in how to make my tables better (currently they are just barebones basic HTML, and admittedly hideous). It is just getting around to spending a day or two to figure table code, and testing across devices... I would rather GET MORE BOOKS CONVERTED/OUT THERE. But this looks slightly promising.

Side Note: mrmikel, please use Code boxes, they make reading the code MUCH easier. You can use it on MobileRead by surrounding the text with [CODE][/CODE] (or pushing the little '#' button in the Advanced Post Editor).

[mrmikel]

I have never liked tables. It is so hard to keep from blowing them up. My bigger bugbear is when some moron decides to use ordered lists when transcribing a document. Why not just copy the number or letter? They are not going to add to it or subtract from it.

Thanks. I stumbled upon the display functions on the web. Makes a world of difference. It scales all the way up of XL. I used this for the css:

.div-table{display:table; border:1px solid black;}
.div-table-caption{display:table-caption; background:gray;}
.div-table-row{display:table-row; border:1px solid black}
.div-table-col{display:table-cell; padding: 5px; border: 1px solid black;font-size: 85%; text-align:left;}
.div-table-col-num{display:table-cell; padding: 5px; border: 1px solid black;font-size: 85%; text-align:right}

Now how do I get my Sony Reader to center the mess?

[Tex2002ans]

Originally Posted by mrmikel

I have never liked tables. It is so hard to keep from blowing them up.

I don't see it being any different for these Tables made completely out of CSS. Probably even LESS support for it on devices, when compared to basic HTML Tables.

And, for example, you wanted to copy/paste the book to a website (which often happens with a chapter I create in my EPUBs), relying on specific CSS to function/display something as basic as a table would break.

If the basic HTML tags exist, I would probably opt for those over emulating the same thing via CSS.

For example: Using "<blockquote></blockquote>" instead of "<div class="blockquote"></div>" with margins on top/bottom/left/right.

Originally Posted by mrmikel

My bigger bugbear is when some moron decides to use ordered lists when transcribing a document. Why not just copy the number or letter? They are not going to add to it or subtract from it.

I actually see this both ways. Using the <ol> WOULD be a correct way to handle it (IF ADE/RMSDK WOULD HANDLE GODS DAMN start="" and type="")... but the support on most ereaders is just completely buggy/broken.

Future Formats

<ol> COULD have some advantages such as not breaking across pages and/or being floatable to another page, if you were going backwards from ebook to print.

You could also use more advanced CSS Counters to do the same sort of thing (again, left for a format BEYOND EPUB/MOBI):

http://www.w3schools.com/cssref/pr_g...nter-reset.asp

Now

Indeed, the best way to tackle it CURRENTLY is to probably just transfer the number over as text (which is what I do). Much less chance of breakage across devices... BUT, keep in mind, that while the text may not change directly, let us say you DID want to create a second edition of the book with lots of edits. You may go in and change some text around, and this is where auto-numbering would see an advantage.

Let us say you had a list of 30 objects, you added one in between, this will mean editing code it only ONE position, instead of ~30.

Or let us say you wanted to swap from "number" format into "lowercase letters" or "roman numeral" format. Or let us say you had a nested list, and wanted to swap the inner list from "lowercase letters" to "roman numerals". It would just require a simple type change, instead of manually replacing all 30 "plain text" numbers.

Side Note: Another advantage of automation is that it is less prone to human error.

Another Side Note: I am noticing a lot of stuff I haven't noticed before, when trying to create a LaTeX version of a few of these books. Lots of places (especially chapters, sections, footnotes) are WAY better automated, than in plaintext form.

Originally Posted by mrmikel

Now how do I get my Sony Reader to center the mess?

Maybe something along the lines of:

.divtable {
	width: 80%;
	margin-left: 10%;
	margin-right: 10%;
}

HTML:

  <div class="div-table">
    <div class="div-table-row">
      <span class="div-table-col">
        Ordnance and ordnance stores
      </span>

      <span class="div-table-col-num">
        $45,000,000
      </span>
    </div>

    <div class="div-table-row">
      <span class="div-table-col">
        Aircraft and aeronautical material
      </span>

      <span class="div-table-col-num">
        29,775,000
      </span>
    </div>

    <div class="div-table-row">
      <span class="div-table-col">
        Tanks and other vehicles
      </span>

      <span class="div-table-col-num">
        15,000,000
      </span>
    </div>

    <div class="div-table-row">
      <span class="div-table-col">
        Miscellaneous military equipment
      </span>

      <span class="div-table-col-num">
        10,225,000
      </span>
    </div>

    <div class="div-table-caption">
      This is a test caption
    </div>
  </div>

Here is the CSS I used (changes in Red):

.div-table {
    display: table;
    border: 1px solid black;
    width: 80%;
    margin-left: 10%;
    margin-right: 10%;
}

.div-table-caption {
    display: table-caption;
    caption-side: bottom;
    background: gray;
}

.div-table-row {
    display: table-row;
    border: 1px solid black;
}

.div-table-col {
    display: table-cell;
    padding: 5px;
    border: 1px solid black;
    font-size: 85%;
    text-align: left;
}

.div-table-col-num {
    display: table-cell;
    padding: 5px;
    border: 1px solid black;
    font-size: 85%;
    text-align: right;
}

Although it seems like ADE did not like the "caption-side: bottom" that I added.. and it looks to have broken the width of the caption:



Anyway, this stuff brings a tear to my eye... I guess I should seriously look into beautifying my Table CSS.

[mrmikel]

What I do and what the web guys did is transcribe an existing document. No reason to do anything but copy what is there.

HOWEVER, if it is a living document, a manual of procedure, etc, there is much more reason, so long as you don't want it to be an epub.

HOWEVER, why should it be an epub and subject to reflow in the first place when it is easy to create PDFs which have no such problems and which is a heck of a lot less work.

I just wish the standards people and adobe were more interested in getting work done and accommodating existing documents than creating standards which are not supported in the real world.

Thanks, I will try the ideas for centering. I will just try to ignore the other checkers which are finicky about what they will accept but which play fine on most devices, since I have no interest in commercial publishing.

I will probably put the two books I have been working on up to MR in today after fiddling with centering. One has a table that will take a microscope to read, but there are no such things as fold out screens, yet anyway.

[crutledge]

I have found that converting tables to images works quite well.

[Jellby]

Originally Posted by mrmikel

I have never liked tables. It is so hard to keep from blowing them up.

Yep, but the solution is not to fake the table with CSS, but to lay things out differently:

<div class="table">
<p>Ordnance and ordnance stores: <span class="amount">$45,000,000</span></p>
<p>Aircraft and aeronautical material: <span class="amount">$29,775,000</span></p>
...
</div>

where you'd probably have some specific margins and indents in "div.table p". In "span.amount" you could include something like:

span.amount {
  display: block;
  text-align: right;
  font-weight: bold;
}

[eschwartz]

Originally Posted by Tex2002ans

Future Formats

<ol> COULD have some advantages such as not breaking across pages and/or being floatable to another page, if you were going backwards from ebook to print.

You could also use more advanced CSS Counters to do the same sort of thing (again, left for a format BEYOND EPUB/MOBI):

http://www.w3schools.com/cssref/pr_g...nter-reset.asp

Now

Indeed, the best way to tackle it CURRENTLY is to probably just transfer the number over as text (which is what I do). Much less chance of breakage across devices... BUT, keep in mind, that while the text may not change directly, let us say you DID want to create a second edition of the book with lots of edits. You may go in and change some text around, and this is where auto-numbering would see an advantage.

Let us say you had a list of 30 objects, you added one in between, this will mean editing code it only ONE position, instead of ~30.

Or let us say you wanted to swap from "number" format into "lowercase letters" or "roman numeral" format. Or let us say you had a nested list, and wanted to swap the inner list from "lowercase letters" to "roman numerals". It would just require a simple type change, instead of manually replacing all 30 "plain text" numbers.

Side Note: Another advantage of automation is that it is less prone to human error.

<ol> also indents the listed object properly. When I discovered that ereaders seem to have little support for lists (especially with 300 items) I was resigned to using text, with a negative text-indent + margin, but it still doesn't work when the number goes up to two and three digits.

[Tex2002ans]

Originally Posted by eschwartz

<ol> also indents the listed object properly. When I discovered that ereaders seem to have little support for lists (especially with 300 items) I was resigned to using text, with a negative text-indent + margin, but it still doesn't work when the number goes up to two and three digits.

Indeed, the clunky workaround to try to emulate the functionality of the basic HTML tags (how ADE/RMSDK could have broken such basic functionality, I don't know)!

Or doing something as simple as changing the shape of the bullet using list-style-type, you are relegated to emulating the <ul> via negative indent CSS, and inserting your own "bullet"!

Or on my Nook, if you have Ordered Lists + nested Unordered Lists, it breaks:

[corblimey]

We need to get away from tables in epubs and think of different ways of showing data. The devices were designed to give the user a degree of control (e.g. increasing text size) and therefore tables are a bad idea in these sort of documents.

I recently had to do my first epub which was full of tables but we had a rethink and decided lists were better. They gave us more flexibility and with some clever CSS use on the sub-headers, it looked a whole lot better.

Turning tables in to images is a really bad idea. If someone is having the epub read to them by the device, it will just read "image" and not the details from the table!

[mrmikel]

Some of us are transcribing tabular data from existing books. I agree that it is better to design tables out in the beginning in new works. But it would change the original work largely and be a huge amount of work to even try to figure it out. It is nearly always true that if they use tables once, there are ten or twenty which are very wide. I use mice type so that it will display in a small space, but I don't guarantee pleasant reading.

[corblimey]

Don't forget to make any lines of the table a colour other than black or they will disappear if the user changes to "night" mode.

[mrmikel]

Thanks for the reminder. My reader doesn't have this function, but I don't want to leave others "out in the cold."