W3C home > Mailing lists > Public > www-style@w3.org > July 2014

Re: [CSSOM] The GeometryUtils interface & DOM Ranges

From: François REMY <francois.remy.dev@outlook.com>
Date: Mon, 7 Jul 2014 10:48:14 +0200
Message-ID: <DUB130-DS247900DD825315486BE4B3A50D0@phx.gbl>
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

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:39:23 UTC