- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Fri, 29 Apr 2011 21:05:05 -0700
- To: "L. David Baron" <dbaron@dbaron.org>
- Cc: Andrew Fedoniouk <news@terrainformatica.com>, Alex Mogilevsky <alexmog@microsoft.com>, Brad Kemper <brad.kemper@gmail.com>, www-style list <www-style@w3.org>
On Fri, Apr 29, 2011 at 8:41 PM, L. David Baron <dbaron@dbaron.org> wrote: > On Friday 2011-04-29 12:55 -0700, Tab Atkins Jr. wrote: >> The re-use of 'vertical-align' to do content alignment in table cells >> was inarguably a mistake. > > It was? Having different properties that do similar things in > different contexts can be confusing -- authors might have trouble > remembering which one is which. Right, but vertical-align on inlines and vertical-align on table-cells are an even worse problem - identical properties that do substantially different things. > Also, for the record, the box-align proposal we discussed a few > years back was about horizontal alignment only. The proposal in > this thread seems substantially different, since it puts the > alignment property on the parent instead of the children, and has > alignment on both axes. This adds the capability to align > vertically, but removes the capability of aligning different child > blocks differently, and perhaps confuses the model a good bit as > well. Right, this is explicitly an attempt to gain the same capabilities that vertical-align on table-cells presents, because that's really useful and authors like it, to the point where they get really confused when they try to use vertical-align on other elements. Mixing in horizontal alignment shouldn't complicate the model too much, but it makes the property more complete and useful, and makes it direction-agnostic, which is something we want to encourage in new layout primitives. ~TJ
Received on Saturday, 30 April 2011 04:05:52 UTC