Absolute positioning edge-cases #48
Comments
|
Hm, I whipped up a quick JSBin, there’s definitely layout, paint & compositing happening:
Do you have a test case you can give me where layout is not triggered? Genuinely curious. I think you are right that there might be an optimization to not trigger layout & paint on a promoted, absolutely positioned element, but I am not sure it’s trivial. |
|
I never said that layout would not be triggered, but paint is not necessarily triggered. I do not know of any case where layout can be circumvented.
The code for that page: <html>
<head>
<style>
.abs {
position: absolute;
top: 10px;
will-change: top;
width: 100px;
height: 100px;
background: lightgreen;
}
.abs.move {
top: 30px;
}
</style>
</head>
<body>
<div class="abs"></div>
<script>
var move = () => document.querySelector(".abs").classList.toggle("move");
setInterval(move, 500);
</script>
</body>
</html> |
|
Ah interesting. In Canary (M63) I don‘t see any paint either. Might be an optimization, but probably nothing to rely on for now. Good catch tho. If it makes it to stable I might add a note to positioning properties |
|
I tested this on 61.0.3163.100 actually. Interacting with the dev tools can cause paints by the way; not sure if they show up at the location triggered by the script and are prone to cause confusion though. |
I just found out that at the very least Chrome does not always cause paint if an element is positioned absolutely and has its own layer.
If the
gofunction on the subsequenttopchange test page only moves the outer element and not all the elements there is no paint. I changed it like this:Not sure what the issue is when the class is applied, as all the children are also positioned absolutely with
will-change. Intuitively it makes sense to me that absolutely positioned elements do not invalidate any pixels if they have their own layer.The text was updated successfully, but these errors were encountered: