On Tue, Aug 31, 2010 at 5:01 AM, Anne van Kesteren <annevk@opera.com> wrote: > On Wed, 18 Aug 2010 23:07:36 +0200, Ojan Vafai <ojan@chromium.org> wrote: > >> Those are totally valid concerns. Ideally we could spec this so that it >> would also work in the situations where inserting an empty text node >> doesn't create a CSS box, which is what IE does, but I'm not sure how. Even >> without that, I think this would be an improvement. It's incrementally >> closer to >> what IE does and, in my opinion, gets closer to meeting the use-case for >> this API. >> > > So I looked at this a bit closer and I think it is rather ugly. For the > purposes of the API we have to pretend there are empty text nodes everywhere > which somehow cause a box to be generated (although I would never expect > empty text nodes to do that) in most cases (e.g. not with tables) which is > then returned by the API. This seems really rather fragile and I would > rather not do it. At least not in this way. > I agree it's ugly. > I suppose we could special case start of an element and end of an element. > Start of an element gives you top/left of the element with height/width 0 > and end of element gives you bottom/right with height/width 0. That would > also work for the table scenario, but it might miss others. > How about start of an element gives you top-left of the content-box and end gives you top-right of the content-box? The use-case I have in mind is figuring out where the text cursor is. While this won't work for 100% of cases, it will work for the common cases and is certainly better than returning an empty rect. Code that works with this will still need to figure out the height of the cursor, but that's not a deal-breaker. They can at least avoid needing to modify the DOM just to get these metrics. Ojan
Received on Wednesday, 1 September 2010 04:29:34 UTC