On 2/13/14 4:48 PM, Patrick Walton wrote:
The pull request #1681 takes approach #2. It deals with the parallel hazard by deferring height computation of absolutely positioned blocks until display list construction time (which is top-down).
I sort of think that the right time to do absolutely positioned stuff in general is in a completely separate pass after the "main" layout is done.
We've run into this in Gecko as well; that's what held up supporting relpos table-cell as an abs pos containing block. The way table (or flexbox, I suspect) layout works is that you do a pass, do some layout, then go back and fix up all your sizes. You need to either do the abs pos stuff _after_ the fixup or at least fix it up after the fixup, and the latter starts placing constraints on exactly how you can do your fixup.
So the way I was envisioning layout with abspos stuff involved is that you go through without descending into abspos kids and do layout. Whenever you see an abspos kid during this process you add it to a list.
Then you go through this list (this part should parallelize pretty nicely, btw, except for the overflow area updates on parents) and reflow them all, since now you know their containing block sizes, and you update overflow areas. Again, if there are abs pos kids you add to a list, etc.
None of this really pins down anything about what you actually store as the containing block vs hypothetical box bits. The only requirement is that you be able to get to both pieces of information quickly when you go to reflow the abs-pos box.
Anyway, for now I'm inclined to just not handle hypothetical boxes and just make up some values (e.g. zero) where the spec says to calculate their positions. This will almost certainly break the Web
s/almost //, fwiw. ;) -Boris _______________________________________________ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
