W3C home > Mailing lists > Public > www-style@w3.org > September 2009

RE: [cssom-view] Extensions to the MouseEvent Interface

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>
Message-ID: <49142F02149340458FDD20841AD0AD561CB1EC79@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com>
> 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

This archive was generated by hypermail 2.4.0 : Monday, 23 January 2023 02:13:39 UTC