Re: layout idea

On Thu, Mar 19, 2009 at 1:01 AM, Brad Kemper <brad.kemper@gmail.com> wrote:
> I think 'row#' and 'col#' would be very easy to understand. The author could
> specify one or both, and other cells would move to get out of the way or
> close holes left by the movement.

Ah, no, I was talking about out-of-flow alignment.  In out-of-flow,
grid units are ideal, as they provide a simple and useful abstraction
that trivially generalizes to allow intuitive out-of-flow alignment on
other flow models as well, such as multicol.

In-flow positioning is a bit more difficult.  What happens in the following?:

#foo {
  row#: 2;
  col#: 2;
}

#bar {
  row#: 2;
  col#: 2;
}

Do they overlap?  Does one slide into place, and then bump the other
one out?  If so, which?  And in which direction? (Presumably to the
right.)  Is one of the declarations invalid?

> I wonder if we need the word 'table-' in there, and if we actually need to spell
> out 'column', or if 'row-span' and col-span' is enough (like the HTML properties,
> with a dash added for CSSiness). In theory, the same properties could then be
> used for other things, so that if I change the display type and add columns (for
> multi-column layout), then col-span could maybe be used with that too. By the
> same notion, I would replace table-columns with just 'columns' (or to 'column-count'
> if you don't want to change the shorthand meaning of 'columns' in multi-column layout).

I like the explicit namespacing that occurs here, because I don't
think it likely that a property used to describe table-flow would be
useful in other flow modes.  I'm fine with shortening 'column' to
'col', though.

> Yes, exactly, except that I would like to see baz automatically becoming col-span:2
> so that the row has the required number of cells. In fact, I would like to have
> something like that for rule 7 of section 17.2.1 of CSS21 tables [1]. Its a little
> beside the point, but anything that generated cells for a cell-free row, should
> really end up with all of its columns filled.

Hmm, that's not how the current table model works, though.  If I have:

<table>
  <tr>
    <td></td>
  </tr>
  <tr>
    <td></td>
    <td></td>
  </tr>
</table>

then I don't get a col-span:2 cell on row 1.  I just get an empty hole
in the in the upper-right corner.

Of course, you might be able to get that behavior by specifying:

::table-row :last-child {
  table-col-span: remaining;
}

If that doesn't work (I'm kind of iffy on it, but it would be nice!) a
separate property (table-row-fill:{complete|none}?) could handle it,
but that seems inelegant.  Honestly, though, I doubt that your
preferred behavior will be generally expected by authors (it's not
expected by me as an author).

> By my way of thinking, it instantly becomes ::table-cell(2,1), due to the col-span
> of the above (it moves to the next available slot).

I'm not sure I fully understand, but then, I think we have a mismatch
in exactly what we believe ::table-cell() is referring to.  It seems
you see the table-flow as automatically creating a bunch of
::table-cell() elements, presumably associated with actual
display:table-cell blocks, which are then pushed around within a
horizontal flow model.  Allowing someone to specify numbers, but not
even pretending that the numbers correspond to anything significant,
seems likely to be extremely confusing.  Frex, if I have
"::table-cell(1,1){table-col-span: 3; table-row-span: 3;}", then
::table-cell(1,2) could be in the (1,4) position.  Or it could be in
the (4,1) position, if "table-cols:3" was specified on the flow
parent.  This feels ridiculous.

In my mental model, once you declare "::table-cell(1,1) {
table-col-span: 2; }", ::table-cell(1,2) is either an invalid
selector, or corresponds to the same cell as ::table-cell(1,1) (don't
have an opinion on which would be better).

I'm curious as to Dave's thoughts on this.

> I'm not sure I follow you, but it may be because of what I imagine
> happens to the cell at the location that another cell is being moved
> to (it and the cells after it slide to the right one slot, wrapping
> into new rows if needed, or they move to the left if the cell that
> was moved creates an empty grid slot to the left).

Well, we've got two different ways of pushing content around in table
flow, which David touched on.  We can move a block around as a
first-class table flow entity, or we can flow contents *into*
table-cells, where they then take place in whatever flow model the
table-cell has set for itself.

I see table-position as doing the latter, which is why I'm concerned
about anonymous block creation.

For example, say you have the following page structure:

<body>
 <header />
 <article />
 <nav />
 <ul id=related-posts />
 <ul id=blogroll />
 <ul id=fun-links />
 <footer />
</body>

You want to set up a 3-column layout, with the article in one column,
nav and related-posts in another, and blogroll and fun-links in a
third.  If you rely on anonymous block creation and only allow things
to be shoved around within the table flow as, the best you can do is
set up article as row-span:2, and deal with the fact that nav and
blogroll must be the same height, as must related-posts and fun-links.
 In other words, you'd be stuck with a setup like this:

aaa
bcd
bef
ggg

When what you want is this:

aaa
bcd
eee

with two things flowed into slot c, and two things flowed into slot d.

Without a way to flow content into the table-flow blocks, you'd have
to wrap things in <div>s.  This is unattractive, and means that you'll
likely have to revise your page code *again* later when you want to do
a redesign.  All in all, unacceptable to me.

~TJ

Received on Thursday, 19 March 2009 15:22:34 UTC