Table troubles Options

[Brian Chandler]

A decade or two ago I made this page:

https://imaginatorium.org/shop/shipjp.php

Page down past the Covid problems bit, and there is a banana-shaped map. This is in three slices, but looks fine. So I hope I could just copy this code to the new domain and think about redesign. (If you narrow the window to about 50% of the screen, you will see what I originally intended.)

But as soon as I embed this in my new site, the map breaks. Here is a copy (at the original domain, just to show the domain has nothing to do with it):

https://imaginatorium.org/shop/test_map1.php

I have added a red border for diagnostic purposes, but the problem was there before. The inspector thingy says that the image is 250px high (top row) or 90px high (second row) , and that the TD has vertical-align:bottom. But it also says, without explanation, that the TD is an extra 4.583px high, and leaves this gap on the bottom of both rows 2 and 3. Note that in row 3, the "vertical-align" seems to work, moving the included table exactly to the bottom of the TD.

Short of reconstructing the whole thing, line by line, I don't know how to approach problems like this. Any suggestions?

[pandy]

What's the same? You have different doctypes, different CSS. The first map table on the page is broken, but so is the one on the working page. The second map table is even more broken.

https://validator.w3.org/
https://wiki.mozilla.org/QA/Minimal_Test_Cases

[Brian Chandler]

I repeat my question, hoping for a constructive answer.

(I should add that the old page is for reference only. I am not going to change it, since it is being replaced.)

This post has been edited by Brian Chandler: Sep 3 2021, 09:36 AM

[Christian J]

It looks like the letter descender gap: http://gtwebdev.com/workshop/gaps/image-gap.php (Eric Meyer used to have a dedicated demo page, but I can't find it now).

The reason it breaks on the new page is likely because the HTML5 Doctype puts the browser in Strict mode (I'm guessing the old Doctype results in just Almost Strict mode actually the validator says the old Doctype is invalid, so maybe that results in Quirks mode even).

Give the IMG element itself "vertical-align: bottom" and it should go away.

This post has been edited by Christian J: Sep 4 2021, 11:59 AM

[Brian Chandler]

It looks like the letter descender gap: http://gtwebdev.com/workshop/gaps/image-gap.php (Eric Meyer used to have a dedicated demo page, but I can't find it now).

The reason it breaks on the new page is likely because the HTML5 Doctype puts the browser in Strict mode (I'm guessing the old Doctype results in just Almost Strict mode).

Give the IMG element itself "vertical-align: bottom" and it should go away.

Ah, thanks Christian. Groan. I think I can see how to do this - just use display:block, which is more intuitive, I think, once you understand that inline formatting has problems. The TD already has "vertical-align: bottom", which is the CSS verbosification for "valign:bottom", and should mean the vertical alignment of the contents of the TD. But actually means something completely different. The other day you used the word "theoretical", but I do not think such a word can possibly be used for the confused mish-mash of inconsistent terminology that is CSS.

Next problem: inline vertical alignment of buttons with both English and Japanese text. I'll make a separate post...

But really, changing from "almost strict" to "Strict" means that an image, which by definition does not have descenders, must now have space left for the descenders it might have, if counterfactually it were not an image?

[Christian J]

But really, changing from "almost strict" to "Strict" means that an image, which by definition does not have descenders, must now have space left for the descenders it might have, if counterfactually it were not an image?

No, I think the descender space is reserved for descender letters, wether any such letters are actually present or not. I don't know if the latter is part of the spec, I suspect it's just a way to make things simpler for the browser.

[Brian Chandler]

Still struggling. Here is the source of the table included the map which was broken:

CODE

<table class=yuumap><tr><td style="width: 250px; height:250px;">

<table class=yuupak style="margin: 0 auto;"><tr class=z0><td style="text-align: center"><img src="image/reddot.png" width=8 height=14 alt="red dot"></td><td style="text-align:left">Sano (free delivery!)</td></tr><tr class=z0><td>Zone 0</td><td style='text-align:left'>Tochigi</td></tr>
<tr class=z1><td>Zone 1</td><td style='text-align:left'>Kanto, Tohoku, Chubu</td></tr>
<tr class=z2><td>Zone 2</td><td style='text-align:left'>Kinki</td></tr>
<tr class=z3><td>Zone 3</td><td style='text-align:left'>Chugoku, Shikoku</td></tr>
<tr class=z4><td>Zone 4</td><td style='text-align:left'>Hokkaido</td></tr>
<tr class=z5><td>Zone 5</td><td style='text-align:left'>Kyushu</td></tr>
<tr class=z6><td>Zone 6</td><td style='text-align:left'>Okinawa</td></tr>
</table>

</td><td style="vertical-align: bottom;"><img src="maps/yuu1.gif" width=200 height=250 alt="Japan shipping zones (NE)"></td></tr>

<tr><td colspan=2><img src="maps/yuu2.gif" width=450 height=90 alt="Japan shipping zones (central)"></td></tr>
<tr><td style="vertical-align: top;"><img src="maps/yuu3.gif" width=250 height=200 alt="Japan shipping zones (SW)">
<p><small>Map courtesy of <a href="http://hp-sozai.net/s-map/g-map.html" target=_blank>hp-sozai.net</a></small></p>
</td><td style="vertical-align: bottom;">

</td></tr></table><!-- yuumap -->

The map was broken because the images were display:inline; I fixed this by adding the following rule:

CODE

TABLE.yuumap TD IMG {
    display:block;
}

I have now moved the subtable (the list of zones) inside this table, in the "hook" of the bent banana. But now the red dot image, supposed to be display:inline and text-align:center, moves to the top left corner. I tried various changes to the red dot img, like putting "display:inline", (... inline-block, and block with auto margin settings etc), but these all produced incomprehensible messes of various sorts.

So: I assume the problem is that the CSS rule for TABLE.yuumap applies to images anywhere inside it. So I changed this to

CODE

TABLE.yuumap>TR>TD>IMG {
    display:block;
}

This is supposed to apply only to IMG included at the top level. Check fragment above: IMG is child of TD is child of TR is child of TABLE. But what happens is that the map breaks again - somehow this rule does not apply - but the red dot goes back to being centred, confirming that this rule is the problem.

As always, I do not see what to do next. Grateful for help...

PS: Sorry, it is hard to show the page directly - the 'test' page has broken because I had to include a class, and... You can see the live version, but you need to go to (eg) https://imaginatorium.com/fujisiro.html then click "add to basket" on a puzzle, then then go to checkout and set the destination to Japan.


This post has been edited by Brian Chandler: Sep 5 2021, 02:05 AM

[Christian J]

If I understood the examples correctly, the red dot image is already "display: block" due to

CODE

TABLE.yuumap TD IMG {
    display:block;
}

and block-level elements can't be centered by "text-align: center" on their parent element. Making the red dot "display: inline" should work though.

Or you could use

CODE

TABLE.yuumap TD IMG {
    text-align: bottom;
}

to remove the map images' descender spaces. But I don't know if you want "text-align: bottom" on the red dot image too, so maybe you still need a separate rule for that...

[Brian Chandler]

Thanks for looking at this Christian. Yes, your take on the problem is correct, and actually as you say, if I removed the "descender gap" by using vertical-align:bottom (or is text-align: bottom a synonym??), then this would not harm the red dot. Because, actually the "baseline" vertical alignment is a completely stupid default - can you name an application for it other than font soup?

I can see any number of ways of sorting this out (although none of the first five I tried worked) but my immediate question was about the > selector thing. Why does this not work? Have I completely misunderstood the words "child", "element", and something else? It is supposed to apply the 'display:block' to the images in the top level table only; but it doesn't. Replace the > by spaces, and it correctly mends the map, but of course also messes up the red dot.



This post has been edited by Brian Chandler: Sep 5 2021, 12:17 PM

[Christian J]

actually the "baseline" vertical alignment is a completely stupid default - can you name an application for it other than font soup?

Maybe the CSS default value is indeed based on the existing browser default, which was in turn used in the days of FONT tag soup...

my immediate question was about the > selector thing. Why does this not work?

Apparently browsers think a TBODY element always exist in tables, even if you didn't specify one explicitly. So there will never be a case where a TR is the direct child of TABLE.

See if this works:

CODE

.yuumap>tbody>tr>td>img {}

[Brian Chandler]

Thanks Christian. I had a feeling there would be something like this. Was TBODY invented recently? I don't remember ever learning it, and it does not seem to have any function...

Tried it, and instant success!

Anyway, this looks like is a very good reason to avoid the > thing entirely. It seems to me that if you are generating a website in a systematic (ie programmed) manner, it is just vastly simpler to generate specific class names in exactly the right places. It is so tempting to try these CSS tricks - which always seem oriented to elaborate hand-crafted documents - but they always end up wasting time. Anyway, at least I have learned about the inline alignment horrors. More to come...

[Christian J]

Was TBODY invented recently? I don't remember ever learning it, and it does not seem to have any function...

No it's part of HTML4 (along with THEAD and TFOOT). Almost never used it myself.

https://www.htmlhelp.com/reference/html40/tables/tbody.html

Anyway, this looks like is a very good reason to avoid the > thing entirely. It seems to me that if you are generating a website in a systematic (ie programmed) manner, it is just vastly simpler to generate specific class names in exactly the right places.

Yes, I think the more general selectors like > are meant for styling existing, static HTML code.