Re: [CSSWG][css-grid-layout] Updated WD of CSS Grid Layout

On Sat, Apr 20, 2013 at 11:13 AM, Ojan Vafai <ojan@chromium.org> wrote:
>> > - grid-column: 1/2 and grid-column: 1/1 go in the same cell.
>>
>> This is just error handling.  grid-column:1/3 is different than those.
>
> I think this is the wrong error handling. 1/1 should just compute to
> auto/auto. Having 1/1 and 1/2 do the same thing confuses the model. It's
> like it's halfway between lines and positions. If we're going to have this
> position-each-edge model, we should force people to use it correctly so that
> they have to understand the model to get anywhere.

fantasai and I figured that it was better to error-recover to as close
as possible to the author's intent, rather than completely ignoring
their intent and forcing it into auto positioning (as your suggestion
would do).

We could be wrong, of course!  But it seemed convincing at the time,
particularly when you realize that most of these errors will be
*unintentional*, resulting from things like named lines not being
where they expect.

>> > - grid-column: span 1 / 4...I still can't figure out what that's
>> > supposed to
>> > do.
>>
>> The first value goes to grid-start, the second goes to grid-end.  So
>> it attaches its end edge to line 4, and spans 1 column.
>
> OK, now I understand the spanning syntax, but I still think it's totally
> inscrutable. "span 2" doesn't make sense to me as a value for grid-start,
> etc. As it's not actually an edge. It's implicitly relative to some other
> edge.

It was either that, or introduce another pair of properties for
spanning that was ignored if both edges were non-auto.  Maybe that's
the better option?  I dunno.

(If we did that, the syntax of grid-row/column would likely be: [
<line> / <line> ] | [ [start|end] <line> [ span <int> ]? ].)

> Now that we've talked it through, I get it. But, again, I don't think
> web developers will get this. It's bad if the syntax needs the authors of
> the spec to explain it to you.
>
> Can someone write up a summary of what we gain by using the
> position-each-edge model? I'm having trouble seeing any benefits.

For one, we received a lot of feedback from designers that said they
did grid design based on lines, and found the current design
resembling tables to be confusing and weird.  From what I can tell,
this feedback mostly came from people with a print design background,
so it doesn't represent all web authors, but a decent subset.

For two, when you introduce naming into the syntax, and actually dive
into the use-cases for named lines, it seems to lean more strongly
toward line-centric concepts.  This is because often what's actually
being named are *regions* of the grid, which can span multiple
rows/columns.

Before you jump up to say that this is what grid-template is for, the
regions I'm talking about now are typically overlapping/containing.
That's not compatible with grid-template's syntax.  If you want to
deal with regions *explicitly*, you have to do some more confusing
manual specification of them in a separate property.  Explicit regions
are also more difficult to deal with when doing repetition, and this
is made worse by them being a separate property from the row/column
defining properties.

Like I said, for people who want to just think about things in terms
of rows and columns, the syntax accommodates that - just use
"grid-row: 2;" or "grid-column: 3 / span 2;".  Stick with those two
syntaxes, and you never have to think about lines ever.  You can even
mix in named lines, and get away with pretending they're actually
naming rows/columns.  Nothing will ever disabuse you of your notions
if you stick within that subset of the syntax, which is fairly natural
anyway.

But for the more advanced use-cases that have been brought up in this
list and in feedback blog posts, lines are the more useful
abstraction.

~TJ

Received on Saturday, 20 April 2013 19:42:49 UTC