- From: Brad Kemper <brad.kemper@gmail.com>
- Date: Fri, 20 Mar 2009 11:44:07 -0700
- To: "Tab Atkins Jr." <jackalmage@gmail.com>
- Cc: David Hyatt <hyatt@apple.com>, Jonathan Snook <jonathan.snook@gmail.com>, "www-style@w3.org" <www-style@w3.org>
On Mar 20, 2009, at 9:55 AM, "Tab Atkins Jr." <jackalmage@gmail.com> wrote: > On Fri, Mar 20, 2009 at 11:47 AM, Brad Kemper > <brad.kemper@gmail.com> wrote: >> >> On Mar 19, 2009, at 12:39 PM, David Hyatt wrote: >> >>>> No. We don't flow contents *into* cells. We *absolutely position* >>>> contents to align with edges of particular cells. >>>> >>> >>> Three kinds of positioning: >>> >>> (1) table-position on a display:table-cell. The object actually >>> becomes >>> the cell at that position. A pseudo-element can't refer to this >>> cell >>> position when this is done. >>> (2) table-position on a normal flow object like a block. The >>> object is >>> placed *into* the cell at that position. If no cell exists at that >>> position, then an anonymous one gets made. A pseudo element can >>> be used to >>> style this cell. >>> (3) position:absolute with grid units. Provides out of flow >>> alignment to >>> cells in tables. >> >> Please note that I am not totally against #2, above. Just somewhat >> against >> it, because I think it confuses the understanding of the rest of it, >> complicates things that would otherwise be simpler (the automatic >> wrapping >> of cells into new rows), and is unnecessary for the goals of source- >> order >> independence. I think if you had #1 above, plus row-spans/col- >> spans, it >> would satisfy the vast majority of layout needs, and also be a >> great boon to >> creating table-like structures out of non-table HTML structures (like >> definition lists, or headline/paragraph combinations). >> >> #3 is a "nice-to-have" for abs-pos items to align with table- >> display-based >> layouts. #2 just seems extraneous. Is it so that you can put a >> group of >> things, like paragraphs, into a cell without actually having a >> wrapper of >> some sort (like <DIV class="article">) around them first? > > Yes, exactly. Without #2, you have to explicitly add wrappers to your > HTML, It is a natural division anyway, and so one place where a DIV is perfectly semantic. There's even a new tag for it in HTML5 Plus, most existing markup using floats or abs-pos for layout would already have that "central area wrapper" anyway. > and you have to *change* those wrappers if you want to alter the > layout significantly. Change the HTML? How so? I would think so, if you are using classed or id'ed DIVs (likely). > The first part is unpalatable and should be > avoided if possible, and the second is simply ridiculous for a layout > manager. That's the second time in about as many days when you've declared my arguments ridiculous. I'd appreciate it if you could just discuss the matter in a little less insulting manner. Even with no appropriate container,, an anonymous table-cell would be generated, and the question is just whether or not you can select it with the new pseudo-class, or if you need to after moving around the other cells. If it could be selected, then it really really doesn't need this further complication. > As an author, it would be a significant impediment if I didn't have > #2. I could get around it by manually altering my source, as previous > noted, but that shouldn't be necessary. As an author, I would not find it an impediment at all. Nor would I need to alter any of the source that I've written style sheets for in the last decade for this. #2 might be occasionally useful as an extra feature to add later, but should not be allowed to have an impact on keeping #1 (or row/col-spans) simple and easy to use.
Received on Friday, 20 March 2009 18:44:54 UTC