Re: Transformed Pointer Coordinates?

On Tue, Feb 12, 2013 at 5:07 PM, Dirk Schulze <dschulze@adobe.com> wrote:

> I trust web authors to understand what z is for. w might be a bit more
> difficult but might not even be necessary to specify. If we add a new
> element into the web platform we should think beyond the current needs. I
> believe that this interface would be useful for other situations like 3D
> transforms or WebGL contexts. Especially CSS Transforms have a lot of
> situations where you get from a 2D context into a 3D context. You may would
> need to return different object types depending on the current
> transformation, this seems to be difficult in the long term.
>

I guess z is innocuous since ignoring it is OK, but I really don't want to
force Web developers to divide by w.

I suppose we can have convertPointFromNode return the full Point and
specify that it always returns a w value of 1.0.

If Point is a dictionary, which memberes x/y/z/w should be present in the
result of convertPointFromNode? I think x/y/z should be and w shouldn't be.
I think it would be really ugly to have convertPointFromNode return
something that looks like a JS object which always has a vestigial "w:1.0"
member.

Is it actually safe to create a DOM interface called Point? It doesn't
sound very safe to me...

Rob
-- 
Wrfhf pnyyrq gurz gbtrgure naq fnvq, “Lbh xabj gung gur ehyref bs gur
Tragvyrf ybeq vg bire gurz, naq gurve uvtu bssvpvnyf rkrepvfr nhgubevgl
bire gurz. Abg fb jvgu lbh. Vafgrnq, jubrire jnagf gb orpbzr terng nzbat
lbh zhfg or lbhe freinag, naq jubrire jnagf gb or svefg zhfg or lbhe fynir
— whfg nf gur Fba bs Zna qvq abg pbzr gb or freirq, ohg gb freir, naq gb
tvir uvf yvsr nf n enafbz sbe znal.” [Znggurj 20:25-28]

Received on Tuesday, 12 February 2013 04:31:56 UTC