- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Tue, 25 May 2010 12:32:29 -0700
- To: Brad Kemper <brad.kemper@gmail.com>
- Cc: Alex Mogilevsky <alexmog@microsoft.com>, James Robinson <jamesr@chromium.org>, www-style list <www-style@w3.org>
On Tue, May 25, 2010 at 12:29 PM, Brad Kemper <brad.kemper@gmail.com> wrote: > > > On May 25, 2010, at 10:55 AM, "Tab Atkins Jr." <jackalmage@gmail.com> wrote: > >> think there is a strong need for box reordering, based on my own >> experience as an author. I think the need is particularly strong in >> applications, but still mildly useful in documents. However, I'm >> willing to admit that CSS might not be the correct level for this. >> XSLT has its own problems (namely, being and requiring XML), but >> perhaps some other solution can be created for this. The feature is >> independent of the other flexbox-related features, at least. > > I wonder if it is the ability to set an arbitrary index number that causes > the most pain for implementation? Would something like 'move-to(start | end > | before | after | left | right | top | bottom) be any better? I imagine > that would handle most of the use cases for CSS reordering. If two elements > had the same thing (e.g. 'move-to(start)'), it could fall back to source > order to determine which came first. > > 'move-to(before)' and 'move-to(top)' in lr tb languages would move the > element to be in the first child position, but would not guarantee it was > actually above the other siblings. I think sorting with box-order would be useful and cool, actually. ^_^ I'd have to go back and examine places where I'd have liked to have this functionality to see if this sort of limited reordering would be useful. ~TJ
Received on Tuesday, 25 May 2010 19:33:26 UTC