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

Re: MouseEvent: pageX/Y, offsetX/Y [CSSOM View]

From: Garrett Smith <dhtmlkitchen@gmail.com>
Date: Wed, 14 Jul 2010 03:17:01 -0700
Message-ID: <AANLkTinIdmqSRD4jkEJHSfgK-vhfrcy4IYLgenfepK8Q@mail.gmail.com>
To: "Hallvord R. M. Steen" <hallvord@opera.com>
Cc: www-style <www-style@w3.org>
I've moved this to www-style, as the properties the OP was asking
about are present in the CSSOM Views, which is a CSS spec that
references www-style:

| The (archived) public mailing list www-style@w3.org
| (see instructions) is preferred for discussion of this
| specification. When sending e-mail, please put the text
| “cssom-view” in the subject, preferably like this: “[cssom-view]
|  …summary of comment…”

The subject matter seems off-topic for this mailing list; the
rationale for posting here is explained below.

On 7/14/10, Hallvord R. M. Steen <hallvord@opera.com> wrote:
> Siterer Garrett Smith <dhtmlkitchen@gmail.com>:
>>>> The MouseEvent spec covers neither event.pageX/pageY nor
>>>> event.offsetX/offsetY. The former specifies event coordinates relative
>>>> to top of document and the latter coordinates relative to the contents
>>>> of nearest scrollable ancestor container.
>>>> Simulating either in JavaScript in a way that takes scrolling of any
>>>> scrollable element into account is a bit convoluted, all the 4 major
>> The real fun starts when writing workarounds for older versions of Gecko.
> Can't say I've tried but I take your word for it ;)

With older Gecko versions, the pageX/Y properties don't include scroll offsets.

Assigning to evt.pageX results in the error "setting a property that
has only a getter." To workaround that, a getter can be defined on the
instance using __defineGetter__. However, __defineGetter__ requires a
feature test first, because it is not present in many implementations
(including Safari 2 (which also has problems with synthesized events).

>>>> engines already support some of this (Gecko lacks support for
>>>> event.offset*, IE for event.page*, Opera and WebKit supports both though
>>>> Opera copies IE's offset* implementation more correctly for elements
>>>> with borders).
>>>> I suggest we should include at least event.offsetX/Y in the spec.
> Anne kindly pointed me to the spec that actually defines those:

Yes, I see that and as I questioned in my previous message, the
properties may be out of place that spec. They don't seem to have
anything to do with CSS and they have everything to do with

If they do belong in CSSOM-Views, then questions such as yours should
be posed to www-style, not www-dom.

What I was getting at in (please see) my previous message was that
this creates a coupling, or interdependency, between CSSOM-Views and
DOM Events.

Such interdependencies are in the cusp of causing problems that the
W3C may have yet to realize. The problems mainly boil down to HTML 5
stepping outside of its scope. You probably don't want to be bothered
by the specification interdepenency, but if you are, I can explain
them to you.

The properties in question, and in your question, are DOM MouseEvent
properties. To you, the question seemed related to DOM Events and the
pertinent mailing list for that is www-dom. That makes sense to me as
well, and and the list for that spec is the one you picked; it is not

However, if the properties are defined in CSSOM-Views, then I
understand that the mailing list for that specification to be
www-style. Again, I do not agree that questions about MouseEvents
belong on the CSS mailing list anymore than I agree that such
properties belong in a CSS specification.

CSSOM-Views is a mishmash of various things that have little to do
with CSS and has itself influenced a couple of problems by defining

The problems were mentioned on www-style in or around late 2007/early
2008. One of those problems comes up occasionally on c.l.js and is
mentioned again here:

>>> http://dev.w3.org/csswg/cssom-view/
> Garrett asks:
>> Is that the right place to define those properties?

As I see it, no CSS specification should be defining these. I see
these propertes as being MouseEvent properties. I suspect that they
are implemented as MouseEvent properties by implementors. It therefore
seems proper to define these properties on MouseEvent.

>> The problem I see with defining them there is that they don't provide
>> a way to be set programmatically so that they can be dispatched, as in
>> the OP's case. Are they automatically calculated off clientXArg +
>> scrollOffset at time of dispatch? It seems underspecified and tightly
>> coupled.

(the OP I was referring to was you).

>> Why not move these into D3E?

The question remains.

>> NB. The list at www-dom@w3.org filters this email address so this
>> message won't show up on list, you or anyone may repost this message
>> to the list, as that was my intention.

I should have instead written: "Anyone may repost this message to the
list, in whole, as that was my intention."

>> Garrett
> Hallvord

Received on Wednesday, 14 July 2010 10:17:31 UTC

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