- From: Travis Leithead <travil@microsoft.com>
- Date: Sat, 19 Sep 2009 22:06:57 +0000
- To: Doug Schepers <schepers@w3.org>, www-style CSS <www-style@w3.org>, www-svg <www-svg@w3.org>, "www-dom@w3.org" <www-dom@w3.org>
> From: www-style-request@w3.org [mailto:www-style-request@w3.org] On > Behalf Of Doug Schepers > I do like the authoring convenience of providing x and y attributes, but I'm > not convinced that simply reflecting the clientX/clientY attributes provides > the most benefit to authors. The SVG WG has suggested that > DOM3 Events offers a way to resolve the mouse coordinates with respect to > transformations and viewbox adjustments, rather than forcing authors to do > this in Javascript; if the CSS WG also adds transformations to CSS, this is > something that will be needed for CSS+HTML as well. Thus, it is best defined > in the DOM3 Events spec than in the SVG spec. The most obvious names for > these attributes are x and y. I understand that this part of the CSSOM spec is > already implemented, but this need not cause a problem... in the absence of > any coordinate transformations, x/y would be identical to clientX/clientY, so > we could simply extend that definition. Unfortunately, I think that hijacking these already-deployed properties (x/y) would result in backwards-compatibility issues for browsers. The use case for mouse coordinate transformations from CSS/SVG is a great idea. I'd rather suggest a _method_ (rather than a property) that translates the coordinates. That way, we don’t have to deal with the init*Event() issue.
Received on Saturday, 19 September 2009 22:07:57 UTC