- From: David Hyatt <hyatt@apple.com>
- Date: Thu, 19 Mar 2009 14:27:08 -0500
- To: "Tab Atkins Jr." <jackalmage@gmail.com>
- Cc: Brad Kemper <brad.kemper@gmail.com>, Jonathan Snook <jonathan.snook@gmail.com>, "www-style@w3.org" <www-style@w3.org>
On Mar 18, 2009, at 7:52 PM, Tab Atkins Jr. wrote: > Dave: You're basically exactly duplicating Grid Positioning, property > for property. You have, however, added a few more very useful > pseudo-elements (::table-row, ::table-cell, presumably > ::table-column). > > I'm cool with merging this into the table model. Tables have a *lot* > going for them, because they actually have a flow. Grid Positioning, > by itself, doesn't, which limits its usefulness somewhat. > > However, I'm against the rows/cols units. Grid Positioning currently > abstracts that into the gr unit, which is useful because you can then > use it on multicol elements as well. There's no reason to limit this > abstraction to only one display type. > Yeah a grid unit is fine. I wasn't really trying to propose any specific new unit type... just something that conceptually would let you use absolute positioning to align to a certain row/column cell. Like I said, I haven't thought about this in much detail yet. > I originally thought we could even kill the table-row-span and > table-column-span properties and replace them with height/width in gr > units, but we can't. Using a width/height affects, well, the > width/height of *that cell* (and the row/column the cell is in), but > rowspan and colspan affect the table's actual *flow*. > > Questions! > > 1) How does this interact with implicit table creation? Frex, given > this markup: > > <style> > body { > display: table; > table-columns: 4; > } > > div { > display: table-cell; > } > </style> > <body> > <div>foo</div> > <div>bar</div> > <div>baz</div> > </body> > > What do we see? I expect this: > +-----+-----+-----+-----+ > | foo | bar | baz | | > +-----+-----+-----+-----+ > > That is, I expect display:table-cell to shift content into the > table-flow of the parent element, and for the parent element's > explicit row/column declarations to be honored. > I think it would basically act as though you had declared four <col> elements in your source. > > 2) Same markup as (1), except this time table-columns is set to 3, and > there are four <div>s. > > I'm hoping for: > +-----+-----+-----+ > | foo | bar | baz | > +-----+-----+-----+ > | qux | | | > +-----+-----+-----+ > > That is, once again, a table's explicit row/column declaration is > honored *first*, and display:table-cell elements are positioned as > necessary in this flow. Removing the table-columns declaration (or > setting it to table-columns:auto) would create a 1x4 table instead, as > the CSS table model would normally do. > I think that would probably not be the default behavior. If you specify some initial rows and columns, it seems like you should still behave exactly like a table with table-layout auto specified by default. Intelligent fitting of cells into the grid could be achieved by either specifying a new kind of table-layout value, e.g., table- layout: grid, or by specifying a value in table-position.... table- position: fit .... I think I'd prefer specifying this using table- position. > This would allow for a very nice gridding of linear data. It's imilar > to a horizontal multicol element filled with inline-blocks, except > with explicit column control. > Yeah. I love the idea of defining the grid and the cells and never having to say explicitly what row the cells belong to... just fit them in to the arrangement. > 3) Can table-row-span and table-column-span be set on a ::table-cell() > pseudoelement? > > That is, I want to duplicate: > <table> > <tr> > <td colspan=2></td> > </tr> > <tr> > <td></td> > <td></td> > </tr> > </table> > > With the following: > <style> > body { > display: table; > table-rows: 2; > table-columns: 2; > } > > body::table-cell(1,1) { > table-column-span: 2; > } > </style> > Hmmm yeah thats tricky. The difficulty here is deciding whether you ever specify cells or if you are just specifying objects that go into cells. If your divs *are* display:table-cell, then I don't think things really work the way we want... since the div now *is* the cell, so how could a pseudo element represent it? It couldn't. I think you'd need a model that works something like this: (a) Specifying table-rows and table-columns results in the creation of columns and rows. It's as though a bunch of <col> and <tr> elements had been placed anonymously into the source (and styled with the specified lengths). (b) As table cells are encountered in markup, they would just behave as normal if table-position: auto(?) was specified. In other words, you wouldn't fit into the existing grid. You'd just tack on to it. If table-position:fit or an explicit position is specified, then you'd end up placing the cells at certain positions within the existing grid. We'd have to decide what happens if two cells want the same position in the grid. (c) As objects with table-position != auto are encountered that do *not* have display:table-cell specified, those would be placed at a particular cell position. If no cell is occupying that position, an anonymous cell would be created. It would only be the anonymous objects created from (c) that could support spans on the pseudo-element like you wrote above, but yeah I believe it would work as you described as long as the divs you're placing are just normal blocks and not display:table-cell. > > 4) Same markup as (3). Assuming that it works, what happens to > ::table-cell(1,2)? Can I use it? Is it invalid? Is it treated as > the same cell as ::table-cell(1,1)? What if I set rules on it earlier > in the source, before it was specified that ::table-cell(1,1) should > span 2 columns? What if I told ::table-cell(1,2) to span two columns > as well? > I think what cells you have would depend on an object attempting to place itself into a specific slot. The pseudo elements would not ever style non-anonymous table cells. They'd only be used for anonymous table cells. There is an overlapping problem to figure out of course. > 5) Given an element with display:table, what happens to its children > *without* display:table-cell? > If the objects specify table-position:auto, the same thing that would happen now in existing tables. If "fit" or an existing row/col position is used, then the objects get put into that anonymous cell (or a new cell gets created if none exists at that position). > Currently, the CSS table module says that it all gets wrapped into an > anonymous table-row-group/table-row/table-cell blocks, broken up into > multiple such blocks if there are display:table-* elements mixed in. > > This doesn't seem to mix well with your idea of moving things into > particular cells with the table-position property. They already exist > in a table cell, and even if you move them all out, you've still got > an empty anonymous table-cell block sitting there ruining your layout. > > After a bit of thought, the cleanest solution seems to be to specify > that the auto-wrapping *only* happens to elements with a > table-position set to the initial value. If they have anything else, > they're ignored and positioned after the table is done being laid out. > That prevents the creation of anonymous table-cells when you don't > want them, but lets you still create anonymous table-cells when you > *do* want them. > We pretty much agree, except I want the initial value to be "the way things work today" and to have a new value for table-position to get the fitting behavior we all like. dave (hyatt@apple.com)
Received on Thursday, 19 March 2009 19:27:52 UTC