[focusgroup] after adding default modifiers, the axis restriction modifiers carry 2 meanings and can be confusing

Problem

With the recent focusgroup spec update, it added default modifiers to make it focusgroup values less verbose. For example, the toolbar behavior has inline as a default modifier, so the following author code are equivalent:

• focusgroup="toolbar inline"
• focusgroup="toolbar"

However, if the author does want to enable both inline and block navigation (a.k.a removing the axis restriction), they would need to do focusgroup="toolbar inline block".

Before we had the default modifiers, inline and block were disablers (disabling navigation along the other axis), and using both (inline block) was prohibited because semantically they are conflicted with each other:

• no value (default) = allow navigation on both the block and inline axes
• inline = don’t allow navigation on the block axis (or, only allow on the inline axis)
• block = don’t allow navigation on the inline axis (or, only allow on the block axis)
• inline block = invalid, or don’t allow navigation on either block or inline axis

After the default modifier is added, using a single value makes it a disabler, using both values together makes them enablers:

• no value =
  • in author land, it depends on the behavior’s default modifier
  • in implementor land, allow navigation on both the block and inline axes
• inline = don’t allow navigation on the block axis (or, only allow on the inline axis)
• block = don’t allow navigation on the inline axis (or, only allow on the block axis)
• inline block = allow navigation on both the block and inline axes

This makes it confusing if an author wants to enabling duo-axis navigation — depending on the behavior, it could either be no value, or inline block.

Solution 1: add default axis restriction modifiers to all behaviors

One way to “solve” this is to add inline block as the default modifier to the behaviors that currently don’t have axis restriction default modifiers, namely listbox and radiogroup. However, if makes it impossible for authors to override the default modifier to restrict the navigation to a single axis, say focusgroup="listbox inline", does it mean the default block modifier should be removed? It’s strange that one modifier has control over another.

Solution 2: add anothes modifier to enable navigation along both axes

This solution would make the modifier behave more consistantly:

• no value = invalid, or don’t allow navigation on either block or inline axis
• inline = allow navigation on the inline axis
• block = allow navigation on the block axis
• inlineandblock = allow navigation on both the block and inline axes

And add the new modifier to listbox and radiogroup’s default modifiers.

We’d need a better name for inlineandblock since it’s hard to read and long, considered names include:

• inlineblock
• both (feels too generic)
• norestriction (negative, consistant with nomemory but inconsisant with inline and block)

Other solutions considered

• Rename inline to noblock and block to noinline, but this makes impossible to enable duo-axis navigation because you can’t remove the default no* modifiers. Unless we also introduce another modifier, e.g. norestriction, which effectively the same as solution 2

No source file or test is named. Start by reading the linked scoped focusgroup explainer and the issue's modifier semantics, then determine which proposal and modifier naming should be adopted for listbox and radiogroup. Done means the axis restriction behavior and default modifiers have an agreed, unambiguous specification.