W3C home > Mailing lists > Public > www-style@w3.org > May 2010

Re: Box Reordering

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Tue, 25 May 2010 12:32:29 -0700
Message-ID: <AANLkTilz5sDDMoc-dUlugM82NpQEfnhLehxbRKYsMcDQ@mail.gmail.com>
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.

Received on Tuesday, 25 May 2010 19:33:26 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 11 February 2015 12:34:37 UTC