- From: François REMY <francois.remy.dev@outlook.com>
- Date: Mon, 7 Jul 2014 10:48:14 +0200
- To: <robert@ocallahan.org>
- Cc: "CSS WG" <www-style@w3.org>
> > DOM Ranges currently support the getBoundingClientRect() and > > getClientRects() methods, but both of them are incredibly buggy > > overall in most browsers (especially when transforms enter into > > the mix). > > Hmm. Can you point me to bugs in Firefox? Sure, I'll do so in a separate thread. Beside the algorithm specced for collasped ranges and issues with whitespace shared by about all browsers (IE does marginally better with whitespace, if I remember correctly), it seems Firefox in particular has a bug with css transforms. > > I think it would be great if the people working on the getBoxQuads > > implementation in FireFox could try to return a quad for the cursor > > position (for collasped ranges) or the quads of the associated > > selection overlay (for non-collapsed ranges) and/or report feedback > > regarding the complexity of these tasks. That would make me so > > happy. > > I agree Range.getBoxQuads is needed and would be pretty easy to > implement. However, I'd like to get spec text for existing getBoxQuads > first :-). Fair point. Just can't wait for it, though :D > I'm not sure we want Range implements GeometryUtils. It might not be > useful to have Range implement the convert* methods. Well, does it hurt if they do? It's ok to just implement getBoxQuads, it's just strange to define two interfaces for it.
Received on Monday, 7 July 2014 08:48:30 UTC