Switch order of matching conditions in Element Send Keys

In chapter 12. Elements, section 12.4 Interaction:

Below is an excerpt of step 8 of Element Send Keys where we must pick the "first matching" case. If, for example, the user attempts to send keys to a contenteditable p element, if the spec is followed precisely it will never reach the "Element is content editable" case as the above case always qualifies as "something other than a text input control"

The user agent renders element as something other than a text input control (for example an input element in the color state being presented as a colorwheel):

1. If element does not have an own property named value return an error with error code element not interactable

2. If element is not mutable return an error with error code element not interactable.

3. Set a property value to text on element.

4. If element is suffering from bad input return an error with error code invalid argument.

5. Return success with data null.

Element is content editable

1. Set the text insertion caret after any child content.

I believe the problem would be fixed if the two cases below have their order switched.

Start with step 8 of Element Send Keys in section 12.4 Interaction of the linked WebDriver specification and review the two quoted matching cases. Update their order so the intended contenteditable behavior is reachable, then check the surrounding normative text for consistency.