You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There exists a class of JS APIs that queries the up-to-date layout result, and if we don't have that, synchronously forces a layout to recompute it. These APIs are known to be easily misused and cause layout thrashing.
The current guidelines do not provide a guidance for these known troublemakers:
Be synchronous when appropriate says a API should be synchronously if "the execution time is short and deterministic", but these APIs can incur a long execution time.
Design asynchronous APIs using Promises says an API might need to be asynchronous if "the user agent may need to do a significant amount of work on another thread, or in another process, before returning the result", but these APIs do a significant amount of work on the same thread.
The text was updated successfully, but these errors were encountered:
(Noticed when reviewing w3ctag/design-reviews#1043)
There exists a class of JS APIs that queries the up-to-date layout result, and if we don't have that, synchronously forces a layout to recompute it. These APIs are known to be easily misused and cause layout thrashing.
Examples include:
Element.offset*
,Document.elementFromPoint()
, ...The current guidelines do not provide a guidance for these known troublemakers:
Be synchronous when appropriate says a API should be synchronously if "the execution time is short and deterministic", but these APIs can incur a long execution time.
Design asynchronous APIs using Promises says an API might need to be asynchronous if "the user agent may need to do a significant amount of work on another thread, or in another process, before returning the result", but these APIs do a significant amount of work on the same thread.
The text was updated successfully, but these errors were encountered: