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

Re: [css3-flexbox] order

From: Ojan Vafai <ojan@chromium.org>
Date: Thu, 24 May 2012 10:16:06 -0700
Message-ID: <CANMdWTuayOHSddMuWuZa4OQ9pHVrEKaBsEaUj7pzXXUQwGGQYg@mail.gmail.com>
To: "Tab Atkins Jr." <jackalmage@gmail.com>
Cc: fantasai <fantasai.lists@inkedblade.net>, "www-style@w3.org" <www-style@w3.org>
On Thu, May 24, 2012 at 10:10 AM, Tab Atkins Jr. <jackalmage@gmail.com>wrote:

> On Thu, May 24, 2012 at 9:49 AM, Ojan Vafai <ojan@chromium.org> wrote:
> > On Wed, May 23, 2012 at 11:01 PM, Tab Atkins Jr. <jackalmage@gmail.com>
> > wrote:
> >>
> >> On Wed, May 23, 2012 at 6:15 PM, fantasai <
> fantasai.lists@inkedblade.net>
> >> wrote:
> >> > The WG resolved to change 'flex-order' to just 'order', rather than to
> >> > 'box-order'
> >> > or 'display-order', which were proposed before the call. This name is
> >> > *very*
> >> > generic,
> >> > and brings up the following questions:
> >> >
> >> >  1. Does it affect z-order?
> >> >  2. Does it affect tab-order?
> >> >  3. Does it take effect in speech media as well as visual?
> >> >
> >> > If the answer to the latter two is "no", then I'd like to reconsider
> >> > whether
> >> > 'order' is the right name here.
> >>
> >> 'order' won the poll by a wide margin.  I'd like to not reconsider it.
> >>
> >> Whether it affects tab-order is an interesting question.  I'd be okay
> >> with either answer.
> >
> > I think we probably have to make both order and the reverse values affect
> > tab order. Chromium has already received a number of bugs or our
> > half-finished implementation where people are unable to use these
> properties
> > because the tab order doesn't change (they have to move the nodes in the
> DOM
> > instead).
>
> That seems quite reasonable, then.
>
> > My preference would be to remove all of these sorts of box-reordering
> > methods though. The other problem is that selections don't work right.
> > Selections in nearly every browser are from on DOM position to another
> DOM
> > position. When elements aren't in document order, the selection doesn't
> > match what the user is actually selecting.
> >
> > We currently have the same problem with absolutely positioned elements as
> > well, but this will become worse as we add more ways of accomplishing
> > box-reordering.
>
> This is a general argument against *all* positioning schemes that
> don't maintain a close relationship with document order, including
> both Grid Layout and Regions.  Heck, it's actually an argument against
> row-reverse flexboxes, too, because dragging from one box to the
> "next" will suddenly flip the range around.
>

To be clear, I was suggesting that row-reverse/column-reverse/wrap-reverse
should also affect tab-order.

I think what it actually means is that we need a less naive treatment
> of selections.  (I don't know what that would be, though.)
>

Correct. We need to solve one problem or the other. The status quo is
really bad IMO. I suppose as these sorts of things become more prevalent,
there will be more pressure on browser vendors to do the more complicated
disjoint selections. It makes selection code much more CPU intensive
though. :(
Received on Thursday, 24 May 2012 17:17:00 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:54 GMT