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

On Mon, Nov 1, 2010 at 3:58 AM, Alex Mogilevsky <alexmog@microsoft.com> wrote:
>> From: Tab Atkins Jr. [mailto:jackalmage@gmail.com]
>> 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.

Sure, it's just that if there is *no* difference, then I don't think
it's reasonable to have a new property.

(For that matter, it seems like margins could indeed handle the
grid-*-align properties.)


>> 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.

Yes there is; in the following, you can't tell the bare text to
position itself in the (2,2) cell:

<div style="display:grid;">
  <h1 style="grid-position:1 1; grid-column-span:2;">Heading</h1>
  Some text!
  <aside style="grid-position:1 2;">sidebar stuff</aside>
</div>

> 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.

Yeah, auto-incrementing might be interesting, but I'd want to see
use-cases before attempting a solution.


>> 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.

Okay; I was just checking.


>> 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...

Given markup like this:

<article>
  <h1>heading</h1>
  Some text!
  <aside>Blogroll!</aside>
  <aside>Quote of the day</aside>
  <aside>About Me</aside>
  <aside>Recent Posts</aside>
  <aside>Search the blog</aside>
</article>

Given this reasonable display-independent markup, I'd like to be able
to display this in 3 columns, with one column for text and two columns
for sidebars, on sufficiently wide monitors.  But I can't do that with
Grid Alignment as it exists.  I'd have to add two wrapper elements,
placing the <aside>s in one or the other based on which column I want
the asides to display in.  This violates display-independence,
because, for example, I may want the most important two asides, recent
posts and search, to be at the top of the single sidebar in a 2-col
format (for monitors not wide enough for 3cols), but each at the top
of the two sidebar columns in a 3-col format.

Template could handle this just fine, by setting different Templates
behind media queries, and assigning asides to one or the other slot
based on which ones exist.

>> 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...

Right, I'm sensitive to the problem with multiple ways to do the same
thing.  So, I'm opposed to allowing the template declare row/col
lengths - we should rely only on grid-rows and grid-columns.

Basically, the *only* purpose of the template is to generate ::slot()s
and position them appropriately using the grid properties.  You could
similar just put in several empty <div>s and position them, then rely
on some as-yet-undefined reparenting property to push elements into
those <div>s, but that's a semantic hack, a bad split of concerns, and
relies on behavior that hasn't yet been defined in CSS.  Template, on
the other hand, does things in the proper place, and specs the
reparenting ability within its own domain.

>> 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.

Cool.

~TJ

Received on Monday, 1 November 2010 13:08:04 UTC