Developed in Notepad but doesn't look the same in WP.

This is an oddity of using em to set the font sizes of nested elements, because in this case, em is a relative unit, not an absolute unit.

Basically, what happens is that #content is set to 16px, an absolute unit. Then, the font size of <table> is set to 0.7em, or ~11px (70% of the original font size). Finally, the font size of <td> is set to 0.8em. But surprise! The font size of <td> is actually 80% of the font size of <table> (remember, it was ~11px), or ~8.92px. See this fiddle for another example: https://jsfiddle.net/s0zfabrL/

Because of this, you have to be careful when using em to set font sizes. You can safely use the rem unit to set font sizes of nested elements, because it will always be a percentage of the base font size, but rem is only supported in IE9 or later.

[…] it does pass W3schools validator.

It’s perfectly valid to use cascaded em units. As @stephencottontail rightly describes though, you have to do the math or you may get caught off guard.

Now that I have converted all EMs to PXs, very little changed. It looked almost the same until,…..

I realized that all definitions in the child theme (CSS) has to be preceded with #content. It may not have had to be for all, but it works.

I was told that I did not have to do this so I never did. It was only for the highest order definitions. (Using my own terminology.)

Why is #content even needed in the first place?

Is it true that all definitions need to have it when I am coding CSS in WP child theme?

It really doesn’t have much to do with WP at all. It all comes down to specificity and load order. Your parent theme styles will load first. Then they will be followed by the child styles. (Actually there may be many more styles from other sources, but I’m just simplifying here.) The last to load will take precedence if the selectors are equal.

The parent theme will have many styles that are very specific to target only certain elements. If you want your child styles to over-ride such a rule, you need to at least match that level of specificity. Otherwise your child-theme style will have no effect: the more specific rule wins. (The child theme rule will, however, be used anywhere else that matches this lower level of specificity.)

I think we can say this thread isn’t a WP issue any longer but one of CSS. I’d recommend giving this page a going over. It has a good overview of using css with WP, and lots of links to reference material you may find quite interesting.

If #Content is not a WP thingie, then why is it only in WP that I seem to need it? It was the final answer here.

I am now happy with the site as it is but still needs a few twerks.

‘#whatever’ is just an ID added to a particular element by either WP core, the (parent) theme, a plugin, a function, or even created inline in a post. It’s source may well be WP in this case, but my point was that your child styles must meet the same level of specificity if they are to work. In this case, #content differentiates from #header, #footer, #branding, and so on. Make sense?
#content .table3 td
is more specific than
.table3 td

It sorta makes sense, at least in theory it does. At least it is working as I expect.

How’s this? #Content is what ever I place in a page while #Header of #Footer controls what is above or below what I place in the page. Everything that I see when I am editing a page is content and my CSS for that page in the child theme has to be told this. Of course, all this CSS can be used on any page of said content.

Anything you write when creating or editing a page or post in WP is going to be inserted within the #content div. So yes, that ID will pertain to those specific elements of your site. (Other elements such as widgets will have different IDs, if any.)

Again, best thing is to use the aforementioned web developer tools of your browser, inspect the element you’re interested in re-styling, and copy (or otherwise match) the existing selector string of that element in your new child-theme style rules.