W3C home > Mailing lists > Public > public-css-archive@w3.org > October 2020

Re: [csswg-drafts] [cssom-view] It is unclear when offsetX/Y are calculated (#1070)

From: Noam Rosenthal via GitHub <sysbot+gh@w3.org>
Date: Fri, 23 Oct 2020 21:08:45 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-715590900-1603487324-sysbot+gh@w3.org>
Just came bumped into this issue when trying to use the unfortunate property called MouseEvent.offsetX.

I think that WebKit/Blink behavior creates inconsistencies, and that the Gecko behavior is correct.
It's not in all cases "good for performance" to wait with computing `offsetX/Y` until they're requested, as this could lead in some cases to layout thrashing.

Envision the following case:
- JS is handling a mouse move event
- The handler changes the style, and affects the layout
- Afterwards, the handler requests for offsetX
- The browser needs to update the layout synchronously, to compute offsetX.
- The handler makes more layout-affecting style changes

In the above case layout was performed twice for WebKit/Blink, and only once for Gecko.
The performance gain is only in cases where offsetX is not requested at all, and it can be achieved in other ways - namely to wait until layout is about to happen and then calculate it.

Regardless of performance, I would expect one of the following:
- offsetX is the offset at the time of the event, and corresponds to clientX/pageX (as per spec)
- offsetX is the offset every time it's requested (as it might change inside the handler)

But the Blink/WebKit behavior is neither! It is:
- offsetX is the offset at the first time it is requested, and does not correspond to pageX/clientX.

So, IMO it is clear when offsetX/Y should be calculated, and the spec is correct.

GitHub Notification of comment by noamr
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/1070#issuecomment-715590900 using your GitHub account

Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 23 October 2020 21:08:47 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 06:42:21 UTC