Re: [css-grid] How to resolve lines for absolutely positioned grid items

On Thu, Oct 8, 2015 at 11:40 AM, Mats Palmgren <mats@mozilla.com> wrote:
> On 05/09/2015 01:11 AM, fantasai wrote:
>> On 03/24/2015 11:58 AM, Mats Palmgren wrote:
>>> Q3. what is the start and end lines for "grid-column: 99 / 100"
>>>      in a 3x3 grid?
>>> [... snip ...]
>>> And what is the answer to Q3 if the grid has no tracks at all?
>>> (same as "auto / auto" ?)
>>
>> Tab suggests that we force the explicit grid to always have
>> at least one grid line. The example above would then end up
>> in a zero-width track in a mostly-empty grid of zero-width
>> tracks.
>>
>> Let us know what you think.
>
> Sorry for the late reply.  I just saw that this was added to the spec:
> "If these properties don't define any explicit tracks, the explicit
> grid still contains one grid line in each axis."
> https://drafts.csswg.org/css-grid/#grid-definition
> https://github.com/w3c/csswg-drafts/commit/18fddb003b3486b1cbcce184282cb7e41dd18174
>
> That sentence is problematic for several reasons:
>
> 1. If a line 1 is always present and explicit then the start column
>    resolves to line 2 in the following example:
>
> <div style="display:grid; grid-auto-columns:50px">
> <span style="grid-column:A">A</span>
> </div>
>
> Which doesn't really make sense to me (I think it should start at
> line 1 and it should be an implicit line).  If you really want it
> at line 2, what would the rendering be? Is "A" indented 50px or
> not?  Is there a track between line 1 and 2?

Why should it, tho?  If you had some explicit lines, it would start
one line past the end of the implicit grid, so it's already
established that this kind of error ends up putting you in the
*second* implicit track.

(This is an error case, so we're not really interested in finding a
"correct" rendering, because there's isn't one.  We just want
something that's simple and reasonable.

> fantasai's answer above seems to suggest there is, not only an
> always present explicit line 1, but also an associated zero-width
> track?  The spec doesn't say anything about that though.

She was talking about an implicit track, which is default "auto" and
will collapse to 0 without anything else in it.

But what we ended up going with instead is that the implicit grid is
created by the placement algo, and then if any abspos try to refer to
lines that don't exist, that properly just doesn't do anything for
their placement, as if they'd said "auto" for the placement property.

> 2. The alignment subjects for align-/justify-content are the tracks.
>    Since there are no tracks in this case, line 1 is always at the
>    content start edge and alignment has no effect on it.  This is
>    confusing since if "grid-column:1" always matches a line for
>    a grid-aligned abs.pos. box then it seems it should be always
>    affected by alignment too.
>
> <div style="display:grid; position:relative; justify-content:center">
> <span style="position:absolute; grid-column:1">B</span>
> </div>

We *could* do something like that, but adding more rules just to
handle a degenerate error case doesn't seem that great.  Unless
there's content that , for some reason, would depend on this behavior,
I'd rather let it just be "whatever falls out of the existing rules".

> 3. Thus far the model has been that lines exist on each side of
>    a track, and conversely that all numbered lines have a track
>    in-between them.  No tracks <=> no lines.  The added sentence
>    breaks that mental model.
>
> As I suggested in my original mail above, I think all lines for
> grid-aligned abs.pos. descendants should snap to the padding edge
> when the grid has no tracks.  Then there is no need for the added
> sentence and all the problems above disappears.
>
> FWIW, the Grid implementation in Gecko rests on the invariant in
> point 3 above.  It would be rather complicated for us to support
> an explicit line without an associated track.  (A zero-width
> track would solve that, but that doesn't seem to play well with
> track distribution.)

The current spec *does* match your invariant as stated; if there's
only one line, there's no chance for there to be a track between
anything. ^_^

Maybe your impl assumes that every line has an associated track to its
right/bottom? But that doesn't work with the *last* line in each axis,
hm.

What's the precise issue?  Because if a real grid item is being
placed, it'll generate implicit lines, so you're fine - you've got
multiple lines, you've got tracks, nothing's weird.  If an abspos is
being placed, there's only one corner-case to deal with, and it's easy
whether your internal model is actually line or track based.

~TJ

Received on Thursday, 8 October 2015 20:44:39 UTC