1. In tx inputs, the size is dominated by scriptsig.
Each input has parts with fixed size and parts with variable size, the signature script and the witness (that could also be counted as part of input) have variable size depending on what type of output-script is being spent and are generally bigger than other parts.
which has an example of a scriptsig for one input, and says that it has 140 hex chars (=70 bytes) for the digital signature and 130 hex chars (=65 bytes) for the hashed public key. My question is a) why 70 bytes for an ECDSA signature? b) why 65 bytes for a RIPEMD160 hash? (unless this example is incorrect and I am missing something).
65 bytes is the uncompressed public key (which is uncommon by the way) not the hash of it. Normally the compressed public key is used which is 33 bytes.
Note that such scripts are for spending one of the oldest and simplest output-scripts called P2PKH.
2. In tx outputs, the size is dominated by scriptpubkey. For 2 outputs, you need to have 2 Pay To Pubkey Hash correct?
Correct, assuming you want to pay to P2PKH addresses, there are a bunch of other types with slightly different sizes.
The hash alone is 20 bytes, there are other stuff in the script itself to create the locking script:
OP_DUP (1 byte)
OP_HASH160 (1 byte)
OP_PUSH (1 byte)
<hash> (20 bytes)
OP_EQUALVERIFY (1 byte)
OP_CHECKSIG (1 byte)
The "OP_" codes are like commands telling the script interpreter (smart contract machine) what to do. For example OP_DUP tells it to duplicate the item it finds on top of the stack.
Note that "OP_PUSH" isn't exactly a named OP code, it is basically a byte telling the interpreter the size of the data it should read ahead and push to the stack (0x14 --> read and push 20 bytes).