"If an undue delay is likely to be caused, the work already completed is processed and the update phase yields to other update phases for unlocked content."
My interpretation for a pane/column resize or hidden to visible operation: display-locking reduces jank if I could operate on these elements with the display lock tools. This jank reduction produces more fluid updates in elements not affected by the lock.
Question: If sub elements have complicated draw/render cycles, how will the interplay of locks at different layers affect the result? Composing objects with libraries that use these locks makes me wonder about this issue (or if I make sub-components myself).
As far as I can tell, this is being presented as a change to the programming model which will be undertaken unilaterally. Are we back to the days where one browser gets to decide how the web works, and everyone else can catch up if they like?
(OK, formal languages don't, really, either. But they do tend to stick stakes in the ground via those mechanisms, for which most human languages don't have any analogous concept.)
The question was not about the intent of the feature, but a possible use case that may not have been intended. A more specific reason for the "No" could be more informative.
However if you can do: "BEGIN TRANSACTION; ...#foo.append(...)...; END TRANSACTION;" it gives you a mechanism to "freeze" all or some of the display (think of it as a subset double-buffer), and "blit" the changed dom to the UI when you're done (with the possibility of: " && CONTINUE TRANSACTION".
Imagine a simple list of search results with alternating row colors (white / grey backgrounds) specified by css (nth-child %2 == 0).
If you prepend elements, instead of appending elements it might cause all elements to change color and re-render, on each insertion.
If you append elements instead then it's likely a more efficient on an individual element basis than prepending, but if you had the ability to "lock" the affected display area until you're done with your for-loop, then the browser can avoid updating the area at all until the "COMMIT" call (multiple actions, with a single commit resolution at the end).
Think of it as "batch these dom updates..." Git/SVN multi-file commits vs CVS commits (single-file).
(Or set inner html? :-)
Is this a technical term?
If you synchronously swap a large portion of DOM, style, layout, and paint will likely blow your frame budget.
What am I missing?
It breaks already attached event handlers, undo buffers for input elements, and any existing references you have to DOM nodes.