RE: [css3-grid-align] -- proposed new grid layout module

> -----Original Message-----
> From: Tab Atkins Jr. [mailto:jackalmage@gmail.com]
> Sent: Sunday, October 31, 2010 5:15 PM
> 
> I like it!  Overall nearly equivalent functionality to Template.  I like
> the addition of fr units.  The slider example is also very nice for
> showing why overlapping elements is valuable.

Great!

> 1. When elements overlap, do you still see the overlapped elements
> underneath (assuming a transparent background)?  I assume yes.

Yes, of course. Maybe we should add something to the overview to make it more obvious. 

> 2. Is there a specific reason you used a different property for the
> ordering, when it seems like it's identical to z-index?  Does the new
> property not create a stacking context or something?

This is up for debate. I think most use cases for layering are achievable with z-index. I thinks this is a similar kind of choice to alignment vs. margins.

> 3. The draft, plus your clarification, make it clear how to treat element
> children that aren't explicitly positioned.  Since you're using the same
> auto-wrapping behavior that Flexbox uses, it's also clear exactly how
> anonymous blocks are treated.  However, it's impossible to target
> anonymous blocks to give them an explicit position.  Template lets you
> specify where untargeted children go; perhaps a property could be added
> giving a default position in the grid?  Then the default values for grid-
> row and grid-column could be 'auto', which means 'consult the grid-default
> property'.

I would agree that the grid placement model as currently defined doesn't have any meaningful default position. There is an interesting use case where *all* grid items are at (0,0), but that doesn't make that default useful elsewhere.

One way to address that is to admit that grid items should have specified positions in most cases. There isn't anything that is not achievable without a more sophisticated default placement. 

Another way is to define auto-incrementing defaults, which BTW would make it also make it easier to convert content from XUL grid (if that is ever important). I think it would be reasonable to consider a different behavior; use cases would help here.

> 4. It appears that only children of the grid element can be aligned.
> Is this true?

Yes, in this it is a close match to flexbox containment model. Getting indirect descendants positioned on the grid is what Grid Positioning spec is dealing with. We have intentionally left the relationship between Grid Alignment and Grid Positioning undefined in this initial draft; for either spec to progress on standards track it is certainly important to resolve how the two kinds of grid use merge or co-exist. Let's have a discussion on that.

> 5. The fact that elements automatically overlap when positioned in the
> same place is useful sometimes, but other times hurts the source-
> independence of the module.  For example, if I have a blog with two
> sidebars, I have to wrap all the sidebar sections in two container
> elements and position the containers.  If I want to swap a section from
> one sidebar to the other, I have to change it in the HTML.  In Template,
> it's a simple matter of setting the section from "position:slot(a);" to
> "position:slot(b);".  I'm not quite sure how to address this lack, but see
> below.

I am not sure what the problem is here. It seems as easy to change grid-column/grid-row properties in stylesheet. Or perhaps I don't understand the use case...

> 6. I really like the scriptability-simplicity afforded by having the grid-
> rows and grid-columns properties, but I'm still totally in love with the
> immense *usability* afforded by Template's ascii art.  Being able to grok
> a page layout by looking at a single property is extremely valuable, I
> believe.  A template *is* fundamentally compatible with Grid Alignment, so
> I think it would be great to pull it in.

It is probably possible to allow ascii art grid definition that coexists with grid-* properties (including the two ways you describe). As usual, we should find strong use cases where we think ascii art has a major advantage.

One concern with having both ways is that would create multiple ways to do the same thing, which would deviate from the way we usually add things, even if a more general way is somewhat less intuitive than the simple way. Your own position of favoring flex margins over alignment in flexbox is an example of the latter approach...

> 7. Grid Alignment suffers from the same 'display' problem that flexbox
> does - it's impossible to make a table-cell be a flexbox or a grid.
> Luckily, both flexbox and grid only care that their children are block-
> level, so they work together nicely by default.

I agree. That is an issue with 'display' property. Adopting your display-inside proposal would have addressed it, I think we should resume discussion on that and get it to some kind of conclusion.

> Overall, I think Grid Alignment can be a great successor to both Template
> Layout and Grid Positioning.  Good job!

Thanks!

/alex

Received on Monday, 1 November 2010 10:59:13 UTC