Re: [css-flexbox]

On 1/13/16 6:52 PM, "François REMY" <francois.remy.dev@outlook.com> wrote:

>>>It was decided that, while the problem you raise is a real one, the
>>>proposed solution was suboptimal. A better solution is to reorder the
>>>DOM instead of using the 'order' property, as explained in this
>>>message.
>>>https://lists.w3.org/Archives/Public/www-style/2015Aug/0347.html
>>That is sadly a lack of resolution to the problem rather than a solution.
>>I would like to echo my sentiments and offer a suggestion, in parallel to
>what
>>Richard[1] posted today.
>
>I think the whole problem here is that you use flexbox for the layout of
>items of diverse natures.
>
>Flexbox, in its nature, is tailored for the display of lists of elements,
>or more globally linear layouts of items of similar natures (toolbars,
>search
>bars, ...). I am not sure at all why we introduced the order property for
>flexbox (though I guess it was to make it more useful to web developers
>while we waited for better alternatives like grids), but to me this looks
>like it was a mistake. This property now exists, we cannot remove it, but
>that doesn't mean that using it is a good idea, nor that we should make
>updates to make it easier to use for use-cases it should not have
>attempted to solve in the first place.

I disagree. IMO reordering fits right into what responsive design needed.

Tab's words were: "Part of the reason for including 'order';
at all was to allow authors to order their source in the best, most
logical way, with the important content up front and the lesser
content later in the document, and then lay it out in whatever way
makes the most sense."

That's precisely what I am using it for in RWD 'orientationChange' context.

>In the long term, I believe the layout of elements of diverse nature
>should be solved using CSS Grids instead,

Not really. Personally I don't see myself using CSS Grid very much. Grid
doesn't seem well suited to flip a horizontal layout (desktop'ish) into a
vertical one (for portrait tablet/phone/split-mode) or vice versa, like
Flexbox is.

>Regarding tab-order, I believe that if you built your initial DOM order
>properly, it should hardly ever become an issue for you.

With RWD there isn't always a clear choice. It either starts from Desktop
to be collapsed into a Phone; a Mobile-First/Mobile-only abused non-sense
(usually a lazy mobile copycat layout just made larger with oversized text
and images, like everybody seems to unfortunately be doing);
or considering a more careful balance between both at the same time.

But whatever the design, a portrait order will not always match the
landscape one if the designer actually cares for a good desktop layout.

e.g. Choices have to be made as to whether what's on the right side in
landscape should appear first on a portrait Phone or not. Or, what is the
best way to collapse a header made of 3 columns into 2 or 3 rows for a
phone. The middle column of that header may have to be placed differently
according to content length, and therefore may need reordering. Something
presented on top at desktop/tablet size could be moved at the bottom on
mobile etc... Portrait layouts (which will increasingly include desktop
size split views) often requires repositioning elements in all kind of
creative ways.

IMO not using reorder put designers in a box for having to either
use floats and position:absolute; (both with their own tab-order issues),
or having design limitations for a good compact layout utilizing the
multiple device's screen space in the best possible way.

>However, it is true that it sometimes would be great to customize
>tab-order in css, and you should probably support specifications for
>dealing with this, like the currently stalled "nav-index" property, or
>better yet "nav-before" and "nav-after" properties.
>
>However, nav-index was in a CSS3-UI CR draft for MANY years and there was
>No implementation. Thus only when there is a strong demonstration of
>implementer interest (2+ commitment to implement) should we consider
>Adding it to CSS4-UI.

I had not heard of nav-index, nav-before and nav-after before. It looks
like a solution for what we are after.

>So, if solving the general issue does not seem worth enough to
>implementers, I do not seem them try to implement something
>for the specific issue of flexbox alone.

Agreed. I meant to aim at a solution that could work within the specific
scope of particular display mode. Not far from something along the line of
this thread suggestion, I just now read:
http://lists.w3.org/Archives/Public/www-style/2012Jun/0479.html

But ultimately, the issue isn't only flexbox. There needs to be a way to
affect tab-index with CSS, or accessibility will always suffer in one way
or another when going from one device's or orientation's layout to another.

If that mean extending 'nav-index' more broadly and putting it back on
track, then it appears that may solve the larger problem.

Received on Thursday, 14 January 2016 06:39:48 UTC