Waat! We need to talk - I'm taking a very similar approach in my rewrite. There are some very interesting algorithm problems. Eg; I'm actually comparing pixels in 2 screenshots --with and without text rendered--, in order to get text colour and visibility. This way is actually more performant than using `getElementAt(x, y)` and `getComputedStyle(element)`.
I rewrote mine to. One big problem i hit before rewriting was performance and also css :after classes they are not reachable in the DOM if I remember correctly.
So I resorted to patching phantom to give me access to the WebKit render tree.(which is a tree similar to the Dom tree but not the same.
I can't remember if there was some big issue that eventually made me stop developing. I think the final issue was characters with dual width like many Chinese characters the gui library blessed did not understand the concept of characters with non standard width and a single such character would destroy the entire layout.
And issues with correlting the render tree and the Dom tree.
Now I remember the main problem before switching to the render three was text rows. there is no good way of knowing where a text line will break without resorting to the render tree or to use some form of ocr.
Ah yes, that was a big hurdle, but that's actually fully supported now with DOM Ranges - basically codified selection boxes, those regions that highlight when you select with a mouse. There's still some extra leg work though to render whitespace in the same way as the browser.
I did that to if you are referring to getBoundingClientRect & getClientRects, before I switched over to the render tree.
It does work perfecly for single line text but not multi line text. The rect will become larger than the text and you won't know where each line starts.
Oh! Sorry I just assumed they weren't around then. That's really interesting to know. Hey could I have a chat with somewhere, IM, or something? Would be really good to hear your story with this.
