Re: [css-grid] Span & faulty line names

On Mon, Jun 30, 2014 at 3:49 PM, François REMY
<francois.remy.dev@outlook.com> wrote:
>> > I hereby propose to change the specced behavior in case ((an item is >
>> > sized
>> > using a span && span lines are filtered by name) && (no line of that >
>> > name
>> > exists)).
>> >
>> > Here is the current text:
>> >
>> >   span && [ <integer> || <custom-ident> ]#
>> >
>> >       Contributes a grid span to the grid item’s placement such
>> >         that the corresponding edge of the grid item’s grid area is
>> >         N lines from its opposite edge.
>> >
>> >       If a name is given as a <custom-ident>, only lines with that
>> >         name are counted. (If no line with that name exists, the
>> >         name is ignored. If not enough lines of that name exist, it
>> >         spans to the last such named line in the spanning direction.)
>> >
>> > That means "grid-row: span 3 x-track" is considered the same as >
>> > "grid-row:
>> > span 3" if no row is named "x-track" (typo). I don't think it makes >
>> > sense. I
>> > would prefer to say that it either:
>> > - is equivalent to "span 1"
>>
>> The reason we didn't do this is because if you write "span 3 x-track",
>> you clearly mean for it to span *at least three* tracks, so we can at
>> least honor that much of your intention, rather than dropping it all
>> the way down to span 1.  We tried to stay close to the author's
>> intention with the error-correction, when it seemed possible to infer.
>
> You forget that this isn't true in all cases. Because of the "last if not
> enough lines" rule, you may already end up with less than 3 cells covered
> (the intention is to stay in the explicit grid, and removing the name
> constraints does allow to break that assumption).

Yeah, that's purposeful.  We *could* say that it spans the *minimum*
of the last track of the name *or* the specified number, but that
would violate the clear intention of the author to have it end on a
line of that name.  Lesser of two evils here.

> There's a point where error-correction is worse than reporting an error.
> We're making wild guesses here, not sure this is a very good idea.

They're not wild guesses.  We do just perform the simplest error
correction (treating like "auto") in a number of cases where we can't
infer the author's intent, but in these cases we have at least *some*
intent that we can usefully act on.  Whether or not it's worth it is
certainly debateable, but I think we should at least try.  Resetting
to 1 has *zero* chance of being correct; our behavior has at least
*some* chance of being correct, and it's not expensive to figure out.

~TJ

Received on Tuesday, 1 July 2014 19:29:00 UTC