W3C home > Mailing lists > Public > www-style@w3.org > June 2014

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

From: François REMY <francois.remy.dev@outlook.com>
Date: Tue, 1 Jul 2014 00:49:31 +0200
Message-ID: <DUB130-DS113411C7A4CC8103D98BEFA5040@phx.gbl>
To: "Tab Atkins Jr." <jackalmage@gmail.com>
Cc: "CSS WG" <www-style@w3.org>
> > 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).

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. 
Received on Monday, 30 June 2014 22:49:49 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:39:22 UTC