- From: Doug Schepers <schepers@w3.org>
- Date: Sat, 19 Sep 2009 14:42:44 -0400
- To: www-style CSS <www-style@w3.org>, www-svg <www-svg@w3.org>, "www-dom@w3.org" <www-dom@w3.org>
Hi, CSS WG- I'm editing the DOM3 Events specification in the WebApps WG, and I was recently made aware that the CSSOM View Module extends the MouseEvent interface, which seems to raise some issues. Here are some high-level comments I would appreciate your considering. CSSOM currently references DOM3 Events. Since DOM3 Events is closing in on Last Call, I think it's safe to reference DOM3 Events instead of DOM2 Events. CSSOM's extension of the MouseEvent interface [1] redefines screenX, screenY, clientX, and clientY, which are already defined in DOM3 Events (and DOM2 Events). Though the wording is slightly different, there doesn't appear to be a significant change. It would be better to simply reference the definitions in the DOM Events spec rather than redefining these attributes, so that the definitions don't need to be maintained in two places. I'm happy to work with you to improve the definitions in the DOM3 Events spec if that's needed. CSSOM also defines several new attributes: [[ The pageX attribute, on getting, must return the horizontal coordinate of the position where the event occurred relative to the origin of the initial containing block. The pageY attribute, on getting, must return the y-coordinate of the position where the event occurred relative to the origin of the initial containing block. The x attribute, on getting, must return the value of clientX. The y attribute, on getting, must return the value of clientY. The offsetX attribute, on getting, must return the x-coordinate of the position where the event occurred relative to the origin of the padding edge of the target node. The offsetY attribute, on getting, must return the y-coordinate of the position where the event occurred relative to the origin of the padding edge of the target node. ]] However, it doesn't also extend the initMouseEvent() method to allow the author to initialize these attributes. Depending on discussions in the WebApps WG regarding a generic initialization method, this may be moot, but for now at least, it's something that needs discussion. 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. The offsetX/offsetY attributes seem like they might also be useful in an SVG context, if they were defined in terms of the bounding box, rather than the padding edge. Since I'm actively editing the DOM3 Events specification, I'd like to work with you to update that specification so you don't need to extend the interfaces defined there. [1] http://www.w3.org/TR/cssom-view/#extensions-to-the-mouseevent-interface Regards- -Doug Schepers W3C Team Contact, SVG and WebApps WGs
Received on Saturday, 19 September 2009 18:42:59 UTC