We could make the splitters focusable and add keyboard controls following the "widget" specification in https://www.w3.org/TR/wai-aria-1.1/#separator.

@darktrojan I'll need to set the aria-orientation for this to work. Currently orientation is calculated as-needed (https://searchfox.org/comm-central/rev/44a1db4edca6679b6b711ecba7b640fe58baef04/mail/base/content/widgets/pane-splitter.js#78), rather than set. Were you trying to avoid an explicit orientation attribute, and would you mind if I changed this to be an explicit attribute and value to easily keep this in-sync with the aria-orientation?

Similarly, what do you think about:

• Using a boolean attribute and property instead of a string orientation value? e.g. <hr is="pane-splitter" resize-vertically="" />? I.e. it is horizontal by default like <hr> itself.
• Using a boolean resize-next attribute and property instead of resize="next"?
• Reducing width, height, min-width, min-height, --${this.id}-width and --${this.id}-height properties and attributes to just size and min-size and --${this.id}-size? In most situations you wouldn't need both widths and heights simultaneously. Maybe it would be useful if you want to preserve the height between two rotations, but this could be handled in the part of the code that already handles the rotation.

(In reply to Henry Wilkes [:henry] from comment #1)

@darktrojan I'll need to set the aria-orientation for this to work. Currently orientation is calculated as-needed (https://searchfox.org/comm-central/rev/44a1db4edca6679b6b711ecba7b640fe58baef04/mail/base/content/widgets/pane-splitter.js#78), rather than set. Were you trying to avoid an explicit orientation attribute, and would you mind if I changed this to be an explicit attribute and value to easily keep this in-sync with the aria-orientation?

My main reason for doing it this way was to avoid having to tell the splitter about layout changes. That's not a big deal though, so you could just update the getter to read aria-orientation and add a setter to set it. Then it's just one extra line in the appropriate places.

Similarly, what do you think about:

• Using a boolean attribute and property instead of a string orientation value? e.g. <hr is="pane-splitter" resize-vertically="" />? I.e. it is horizontal by default like <hr> itself.

Not opposed to that. I guess you'd call it isVertical or something like that.

• Using a boolean resize-next attribute and property instead of resize="next"?

We've already been there and changed it to what we have now. I don't see any great advantage either way.

• Reducing width, height, min-width, min-height, --${this.id}-width and --${this.id}-height properties and attributes to just size and min-size and --${this.id}-size? In most situations you wouldn't need both widths and heights simultaneously. Maybe it would be useful if you want to preserve the height between two rotations, but this could be handled in the part of the code that already handles the rotation.

No, I think we should keep this as-is. Sure, it's not common to have a splitter that can work in both orientations, but where it happens it's a lot less friction to be able to set both sets of values and pick which is used depending on the current orientation. In all other cases you can just ignore the unused values.

See also bug 1755036

@aleca pointed out before that the problem with making this focusable is it creates an extra focus stop on something that will likely never be needed to be adjusted. It might be better to provide some other keyboard functionality to change the size.