W3C home > Mailing lists > Public > www-style@w3.org > October 2007

RE: [css3-grid] comments

From: Alex Mogilevsky <alexmog@exchange.microsoft.com>
Date: Mon, 1 Oct 2007 19:04:51 -0700
To: James Elmore <James.Elmore@cox.net>, CSS <www-style@w3.org>
Message-ID: <04F36FB4ED0F85459AA447F72711526F0108037AECDB@DF-GRTDANE-MSG.exchange.corp.microsoft.com>

Thanks for the comments!

Note: I've published an update at http://dev.w3.org/csswg/css3-grid/overview.html . It addresses some of these points.

> -----Original Message-----
> From: www-style-request@w3.org [mailto:www-style-request@w3.org] On
> Behalf Of James Elmore
> Sent: Tuesday, September 25, 2007 3:59 PM
> To: CSS
> Subject: [css3-grid] comments
> Section 4.1 Explicit grid
> What if the layout is not LTR or RTL? Don't forget that CSS 3
> supports TTB and BTT layouts, and that in the case of TTB and BTT the
> lines may be stacked either lr or rl. This paragraph needs to cover
> those cases. (Is there any possibility that LTR or RTL will be
> stacked bottom to top? If this is possible, it adds another layer of
> complexity.)
> Maybe the paragraph could say something like:
> Outer edges of the block's padding box always define grid lines.
> Depending on the layout directions, the leading edges define lines
> that we refer to as horizontal and vertical line zero. In LTR-tb
> layout the left and top edges are the vertical and horizontal line
> zeros. In TTB-rl layout, the right and top edges are the vertical
> line zeros.

You are correct, direction of the grid changes with RTL and vertical. Progression of grid columns is same as ling progression, progression of grid rows is same as block progression. Although no other module is fully defined (yet) in all combinations of bidi and vertical, it is reasonable to expect grid direction to change in same way as tables. I will add a phrase to that effect (or use yours).

> Section 4.1.1 'grid-columns' and 'grid-rows' properties
> There is discussion whether to use '*' or 'gr' to indicate equivalent
> sized (or multiple-sized) grids. Please select one, rather than
> making the developers support the two. I personally prefer 'gr'
> because it matches the rest of the CSS units and because '*' means
> pattern match in other languages (e.g., perl). The more consistency,
> the easier it will be to understand and use. If, in some cases non-
> integer values may be used, this needs to be VERY clearly explained.

At F2F we've settled at 'fr' (for 'fraction'), (http://dev.w3.org/csswg/css3-grid/overview.html#explicit ). What do you think?

> Section 4.2.2 Table
> There must be N+1 grid lines if only a single grid line is counted
> between each row/column, in order to provide the first/last grid
> line. Perhaps it would be simpler to count the table columns/rows the
> same as in Section 4.2.1 Multi-column element, with two grid lines
> for each, and allow border collapse to combine the two grid lines.

That is my preference too. It may seem odd to collaps two lines in one, but it is consistent with multi-col. "3gr" is always two columns.

> Section 4.3 Default grid
> The sentence is poor english and unclear.
> Does it mean:
> Any element that has no explicit grid defined for it and which
> contains no elements defining an implicit grid is considered to have
> a single-cell grid.

The concept of "default grid" is removed (moved to issues). I think the concept is useful though. If it is OK for grid be undefined, it introduces yet another kind of containing block, which complicates the model but doesn't really enable new scenarios... But for now "default grid" is out.

> There seem to be unresolved issues in the last sections, but thanks
> to the team for an outstanding first effort. I hope it is implemented
> soon so I can use it.
> James Elmore

Thanks again for comments
Received on Tuesday, 2 October 2007 02:05:48 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:27:31 UTC