Any letters other than abcdef just read as 0, so the only 'useful' letter in TheShyIon is that 'e' - which gets stripped out by the algorithm. Adding the spaces... uh... shouldn't change that, since the HTML should just read 'The Shy Ion' as 00[e0] 00[00] 00[00], which is still black... but for some reason is using the sections in [here] instead.
Let's test this! (My method of figuring out the exact hex code is simple: take a magnified screenshot, read the numbers from MS Paint, then convert them to hex.)
The She Ioe comes out as e0 e0 e0, and confirms that the 'wrong half' reading carries through the whole word. What about if we add some earlier valid letters?
Tee She Ioe actually comes out as ee 0e 0e; so it's clearly counting from the first valid letter. Is it only doing that when the 'first letter' falls in the first third of the string?
Thy She Ioe is 00 e0 e0, meaning it's still dropping the 'first halves' even when there's nothing weird in the red block. So why is this happening?
00e 00e 00e is still e0 e0 e0, meaning it's nothing to do with the letters used.
00e000e000e0, still the same. Does it just not like 12-item strings? (Yes, 'The Shy Ion' is 11, but it automatically adds one to make it a multiple of three).
00e0000e0000e00 is the 15-letter equivalent, but is still grey. Maybe it's just the letter 'e'?
00c 00c 00c and 009 009 009 are also grey, meaning they're also skipping the 'first halves'.
Come to think of it, this is exactly what's going on with PoorCynic - the middle 'rCy' cluster is forcing the HTML to start each cluster from the middle. PoorCynicGreen is 00 c0 0c, so it's definitely reading 'nic' from the middle, too (to get that 'c' in there). And those are three-letter sections.
New guess: if every 'block' starts with a 0, those 0s are cut off and pruned back until one block finds a letter. So Neshomeh reads as nEs hom Eh0, and doesn't truncate (giving 0E 00 E0); Neshomuh is nEs hom uh0, so truncates to read as E0 00 00. Okay. That works.
But... what about TheShyIon, which appears as pure black despite having a non-fronting 'e'? Well, actually... it doesn't. ^_^; The precise hex value of TheShyIon is 0e 00 00 (or a red value of 14 in Paint); it's very slightly red.
So to tighten up our theory: each third of the string is 'pruned' from the front until the first letter of one isn't a 0 - or until there are only two letters left in it. 'TheShyIon' can trim far enough to bring the 'e' into the second position, but it's the last letter in its cluster; it can't become the first letter, because then it wouldn't have a second letter after it.
(Alternately, this could be consistent with the suggested mechanism for 3-letter strings: they take each letter as a hex value, then add a zero in front of it. So FFF becomes 0f 0f 0f, and TheShyIon becomes eyn, which becomes 0e 00 00. Consistency!)
... did I solve it? I think I solved it. Er, with rather too many words...
hS