Re: layout idea

On Mar 19, 2009, at 8:21 AM, Tab Atkins Jr. wrote:

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

I do not think moving a cell or row should put it out of flow, and I  
did not interpret what David Hyatt said to mean that either. He did  
mention extending position:absolute to align __content__ of a cell to  
particular cell boundaries.

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

I disagree. I do not think taking a table cell (or table cell-like  
structure) out of flow is simple or trivial. Most layouts are based on  
a grid, and it is much simpler to maintain a grid when things are in  
flow. Out of flow, by definition, means that the item is no longer  
there to affect the height of its neighbors, and there is nothing to  
prevent important content from being covered. Most layouts would not  
want that. If you do want to take something out of flow and position  
it in a place where it can cover up important content, you can  
position DIVs etc that are contents of a cell.

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

How many columns have you set on the element acting as the table?  
Let's assume that you set it to have 2 columns. The first rule would  
put #foo into the bottom right corner, with the other cells currently  
empty. The second rule overrides that and says, "no, #bar should go  
there. So #foo moves to the next available slot, which would be row 3,  
column 1 (I would not put it into the empty slots, as they were not  
created as the result of #bar bumping #foo out of its way). If you did  
not have column counts set on the table, then  #foo would either move  
to column 3 or row 2, or we could say that new columns cannot be  
created that way, and it would move to row 3 column 1.

I find this very simple and consistent, with much fewer issues to be  
resolved than with out-of-flow cells.

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

Adding 'table-' to everything that has to do with tables seems like  
overkill, and it seems unlikely that a property used to describe table- 
flow would cause adverse affects in other flow modes. However  
unlikely, it seems more likely to be useful than problematic to keep  
the property less specific to tables, and to not hard-code the word  
table in there.

Plus, it makes these properties kind of long otherwise, especially if  
you have to type something like '-webkit-table-column-span'.

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

Right. That's why I suggested it be added to how the current table  
model works. That is what I meant by 'I would like to have something  
like that for rule 7 of section 17.2.1 of CSS21 tables'.

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

A little off-topic, but if I turned a large paragraph into table-row,  
I would hope for it to fill the row, not just some small square at the  
beginning of the row. But ayway, I think having something like 'table- 
col-span: remaining' could take care of that and provide the option  
for current behavior. Maybe 'max' would be a better word than  
'remaining'?


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

Yes.

> Allowing someone to specify numbers, but not
> even pretending that the numbers correspond to anything significant,
> seems likely to be extremely confusing.

I didn't say they shouldn't correspond to anything significant. There  
would be a natural order in which rules are applied, and certain  
things would have precedence other things.

> Frex, if I have
> "::table-cell(1,1){table-col-span: 3; table-row-span: 3;}",

That creates a 3x3 spanning cell, currently in the upper left corner.

> then
> ::table-cell(1,2) could be in the (1,4) position.

No it couldn't. '::table-cell(1,2)' would not select anything. You  
would not be able to select a part of a cell that was part of a row- 
span or col-span, you could only select the whole spanning cell, which  
in this case would have a position of cell(1,1). If this cell was  
moved somewhere else, so that an actual cell started at cell(1,2),  
then it would be selected by ::table-cell(1,2).

> Or it could be in
> the (4,1) position, if "table-cols:3" was specified on the flow
> parent.  This feels ridiculous.

Yes, it is ridiculous that you are expecting to select a cell that is  
occupied by the right half of a column span. There is no cell(1,2) in  
the above example, because that spot is filled with cell(1,1)'s column- 
span. Assuming, again, that the first number of cell() is the row and  
the second number is the column. Please correct me if this assumption  
is incorrect.

> In my mental model, once you declare "::table-cell(1,1) {
> table-col-span: 2; }", ::table-cell(1,2) is either an invalid
> selector,

Not invalid, just doesn't select anything. Unless things are moved out  
of source order in such a way that a spot opens up there. For  
instance, if cells #a was moved to (1,1) then it would be before the  
3x3 spanning one. If #b were then moved to (1,1), then it would be  
before both those, and then ::table-cell(1,2) would be able to select  
#a. Its really not that complicated.

> or corresponds to the same cell as ::table-cell(1,1) (don't
> have an opinion on which would be better).

That would be another way to go. I don't think it is as natural. In an  
HTML table, selecting TR:nth-child(0n+2) would not select anything if  
there was only one cell in the row that spanned 3 columns.

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

No. We don't flow contents *into* cells. We *absolutely position*  
contents to align with edges of particular cells.

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

I don't. I see it doing the former. Source order independence of the  
grid units (the cells) should mean putting the grid units where you  
want them, not their contents. If I style the cell itself, I should be  
able to have that appear where I want, regardless of its contents. If  
you see it as the latter, you should be concerned, as that makes no  
sense.

>

Sorry, ran out of time. Can't respond to the rest of your letter right  
now.

Received on Thursday, 19 March 2009 17:39:55 UTC