Re: [css-grid] auto-placement algorithm step 2 doesnt' respect sparse/dense/stack choice

On Wed, Sep 17, 2014 at 4:33 AM, Manuel Rego Casasnovas <rego@igalia.com> wrote:
> On 16/09/14 19:44, Tab Atkins Jr. wrote:
>> In another thread, Manuel Casasnovas points out that step 2 of the
>> auto-placement algorithm (which processes items with a definite row
>> position but auto column position) doesn't vary its behavior based on
>> the algorithm specified in 'grid-auto-flow'.  Interestingly, it
>> actually does a "dense" packing, as it repeatedly looks for the
>> "earliest" spot in the row that the item will fit in.  (This makes
>> sense, as it's the easiest way to implement it; doing a sparse packing
>> would require more work, and wouldn't even maintain the ordering that
>> is the entire justification for sparse packing.)
>>
>> Should we have this step pay attention to the algorithm, or leave it
>> as it is?  I'm inclined to leave it as it is.
>
> I also think that it's better to keep it as it is, as you said changing
> it depending on the algorithm will complicate things and I don't see a
> clear benefit.
>
> This makes me think if the "sparse" algorithm is really needed.
> If we go with the approach above, "sparse" will be only working as
> expected for fully auto-placed items and items with a definite column.
> However, items with a definite row will use "dense".
>
> The main goal of "sparse" was keeping the items order, but we're not
> doing it for items with a definite row. Having a different behavior for
> items with a definite row vs column might cause confusion.
>
> At least I cannot think in a clear use case for "sparse".
> So maybe we just need to have "dense" and "none" values for
> grid-auto-flow property.
>
> What do you think?

If you only have fully-auto items or items which are auto in the flow
direction (which I think is far more common than items which are
locked in the flow direction - the step 1 things), "sparse" correctly
maintains the "ordering" invariant I mentioned, which I think is
useful.  It also happens to be slightly more efficient, though the
difference is probably minimal.

Grid has a number of compromises where we attempt to automatically
respect as much of the author's intent as we can, but know that we
can't get things perfect.  That's fine; in general it's an
overconstrained problem, so it's okay to be slightly weird in some
cases as long as we're doing the obviously right thing most of the
time.

~TJ

Received on Wednesday, 17 September 2014 19:44:24 UTC