- From: Noam Rosenthal via GitHub <sysbot+gh@w3.org>
- Date: Fri, 23 Oct 2020 21:08:45 +0000
- To: public-css-archive@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