W3C home > Mailing lists > Public > www-style@w3.org > June 2016

Re: FlexBox keyboard disconnect - new property proposal

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Fri, 17 Jun 2016 14:06:33 -0700
Message-ID: <CAAWBYDC7-OCCXWj83uO94JhfWnNLu9BBq-=Nid4j-8iX=+yEvg@mail.gmail.com>
To: Brian Kardell <bkardell@gmail.com>
Cc: Léonie Watson <tink@tink.uk>, "www-style@w3.org" <www-style@w3.org>
On Fri, Jun 17, 2016 at 7:52 AM, Brian Kardell <bkardell@gmail.com> wrote:
> On Fri, Jun 17, 2016 at 5:53 AM, Léonie Watson <tink@tink.uk> wrote:
>> On the face of it this seems
>> like a good solution, but Simon made a good point - what happens when the
>> keyboard disconnect is actually useful?
>
> Can you provide an example where the keyboard disconnect is actually useful?
> I'm not saying such a case doesn't exist, simply that it is non-obvious and
> if that is a use-case it would be helpful to have an example documented.

Long-standing accessibility advice is to put your "main content" first
in the DOM and things like sidebars and advertising later, using CSS
to arrange them as desired.  This is the origin of the "holy grail
layout" (float-based) and similar CSS hackery - Flexbox handles these
cases much easier (example in
<https://drafts.csswg.org/css-flexbox/#order-accessibility>).  Or
check out the Grid example
<https://drafts.csswg.org/css-grid/#source-independence> - the
portrait and landscape layouts are slightly different in visual order,
but each layout makes a lot of sense individually.

As Henrik said (and fantasai and I and others have repeatedly said in
the past), this has nothing to do with flexbox itself - CSS offers a
wealth of ways to lay out a page such that the visual and DOM orders
don't match.  And there's more than just tab order that are affected
by the mismatch - for example, selecting text across element
boundaries gets frankly *silly* when you move elements around in
interesting ways, where highlighting from one point to another can end
up highlighting completely unexpected parts of the page.

So there are some complicated intersections of issues.  Tab order is
relatively simple conceptually - one can imagine a simple switch (in
CSS or elsewhere) that resets the way tab-ordering is figured within
the subtree to match the (writing-mode determined?) visual order.
There's more detail to be worked out there, but it's not too hard to
imagine.

Selection is a much thornier issue, because (a) I think you might
*always* want visual selection? Can't think of when you'd *want* DOM
selection, and (b) you actually have to change the relevant API, to
return a multi-range object.

Anyway, I'm supportive of an effort to help things here, but we'll
need implementor interest in changing their tab-order implementation
to be significantly more complex.

~TJ
Received on Friday, 17 June 2016 21:07:20 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:52:47 UTC