On 2/16/14 7:15 PM, Pradeep Kumar S wrote:
Hi everyone,
Just wanted to weigh in about the algorithm mentioned by Boris and Patrick
above:
I think it won't work for calculating height for absolutely positioned elements because
we aren't calculating the static position y-coordinate anywhere. Thi
Hi everyone,
Just wanted to weigh in about the algorithm mentioned by Boris and Patrick
above:
I think it won't work for calculating height for absolutely positioned elements
because we aren't calculating the static position y-coordinate anywhere. This
needs to be done by adding up the heights
On 2/14/14 4:15 PM, L. David Baron wrote:
The overflow:fragments spec should probably either (a) say the same
or (b) require fragments following an absolutely positioned fragment
to also be absolutely positioned. I'm in favor of (b), I think. (I
think there might also need to be a constraint ab
On Friday 2014-02-14 15:53 -0800, Patrick Walton wrote:
> So I just looked at the relevant piece of this spec and I'm confused:
>
> http://dev.w3.org/csswg/css-overflow-3/#fragment-pseudo-element
>
> Suppose that I have a document like this:
>
>
> .a { position: relative; }
>
On Friday 2014-02-14 13:54 +1300, Robert O'Callahan wrote:
> On Fri, Feb 14, 2014 at 1:43 PM, Boris Zbarsky wrote:
>
> > On 2/13/14 5:56 PM, Robert O'Callahan wrote:
> >
> >> 2) Fragmentation. With something like overflow:fragments, absolute
> >> positioning can affect the number of fragments you
On 2/13/14 4:54 PM, Robert O'Callahan wrote:
On Fri, Feb 14, 2014 at 1:43 PM, Boris Zbarsky wrote:
On 2/13/14 5:56 PM, Robert O'Callahan wrote:
2) Fragmentation. With something like overflow:fragments, absolute
positioning can affect the number of fragments you generate, which can
affect the
On Fri, Feb 14, 2014 at 1:43 PM, Boris Zbarsky wrote:
> On 2/13/14 5:56 PM, Robert O'Callahan wrote:
>
>> 2) Fragmentation. With something like overflow:fragments, absolute
>> positioning can affect the number of fragments you generate, which can
>> affect the size of the container of the fragmen
On Fri, Feb 14, 2014 at 12:53 PM, Patrick Walton wrote:
> For the first concern, I realized that pages like that are going to be
> sequential no matter what we do, of course, because of the way parallel
> tree traversals work. So never mind there. The O(n^2) update of overflow
> areas still concer
On 2/13/14 6:45 PM, Patrick Walton wrote:
1. This creates multiple sequential barriers, which can result in a
parallelism hazard. As an extreme case, consider:
div { position: absolute; }
...
This will effectively result in fully sequential layout because you have
to wait until layou
On 2/13/14 5:56 PM, Robert O'Callahan wrote:
2) Fragmentation. With something like overflow:fragments, absolute
positioning can affect the number of fragments you generate, which can
affect the size of the container of the fragments.
Ugh. I thought one of the points of absolute positioning was
Here's an idea for how to leverage the leaf-set-removal proposal to optimize
this algorithm:
1. When assigning widths for parents, don't enqueue absolutely positioned kids
to have their widths assigned.
2. Absolutely positioned kids of a node should not be counted as outstanding
children-to-be
For the first concern, I realized that pages like that are going to be
sequential no matter what we do, of course, because of the way parallel tree
traversals work. So never mind there. The O(n^2) update of overflow areas still
concerns me though.
Patrick Walton wrote:
>On 2/13/14 2:42 PM, Bor
On 2/13/14 2:42 PM, Boris Zbarsky wrote:
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 p
> Let me use this opportunity to remind people that fragmentation and
> writing-mode are stuff we should be building into Servo now-ish because
> they affect everything else.
writing-mode is already on the list for next quarter, but fragments is
slated for the quarter after that. I'll try and bump
> By contrast, approach #1 (Gecko's approach) avoids the unbounded amount of
> information flow in the opposite direction to the traversal. The height and
> overflow region only need to travel one step: from containing block to its
> immediate absolutely positioned flow child and back. This can be
On Fri, Feb 14, 2014 at 11:42 AM, Boris Zbarsky wrote:
> 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
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 po
Hi everyone,
Pradeep's excellent pull request [1] for absolute positioning raised
some thorny issues relating to solving geometry constraints for
absolutely positioned blocks in a parallel setting. The fundamental
issue is that absolute positioning can depend not only on width and
height of t
18 matches
Mail list logo
