- From: Robert Flack via GitHub <sysbot+gh@w3.org>
- Date: Mon, 19 Oct 2020 19:30:06 +0000
- To: public-css-archive@w3.org
> I'm not too sure how easy it is to distinguish these from within the implementations. > From an implementation point of view, the API's which are developer requested flushes can for the duration of their execution set some attribute on the state to reflect that style is updating due to a developer requested flush. > For example offsetLeft would cause a style update that is caused by script but that shouldn't flush (IMHO). offsetLeft requires clean layout in order to compute result which requires flushing style. You could for example have a pending style update (or even animation) which affects the position. > getComputedStyle, on the other hand, should, but not if it is called from an internal source (which is possible, I think but I don't really know) > > I still think that we should just spec it as everything is deferred while the element's contents are skipped. But maybe if it's just limited to getAnimations then it could work? It just seems awkward that animation creation events would get fired when there is a getComputedStyle call. We already do create animations when style is flushed, but events are (as usual) deferred until the next lifecycle update. The advantage of flushing in these cases is that the correct style would be reflected (e.g. the animation's initial position may affect the element's style). -- GitHub Notification of comment by flackr Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5611#issuecomment-712393730 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Monday, 19 October 2020 19:30:07 UTC