Re: [w3c/webcomponents] Add custom element default focusability proposal (#834)

domenic approved this pull request.

LGTM with nits

> +<input type="button" value="Click me">
+<my-button>Click me</my-button>
+```
+
+## Proposal
+
+Add a new property `matchFocusBehaviorOf` to `ElementInternals`, which accepts a string containing a tagname and optionally an attribute with a value (so it will accept values like `div`, `a[href]`, `input[type='checkbox']` , but not `.class`, `*`, etc.). The custom element will then be treated as if it has that tagname and attribute in terms of focus.
+
+## Alternatives considered
+
+### Using other ways to represent the built-in elements
+
+The proposed API above uses a CSS selectors to represent the built-in elements, but we’ve also considered some variants:
+
+ - Using “tagname + one attribute name + attribute’s value” combination,
+   e.g. `elementInternals.matchFocusBehaviorOf = {"input", "type," "button"}`

This isn't valid JS syntax. Maybe `matchFocusBehaviorOf("input", "type", "button")` or three separate attributes or something like that.

> +## Proposal
+
+Add a new property `matchFocusBehaviorOf` to `ElementInternals`, which accepts a string containing a tagname and optionally an attribute with a value (so it will accept values like `div`, `a[href]`, `input[type='checkbox']` , but not `.class`, `*`, etc.). The custom element will then be treated as if it has that tagname and attribute in terms of focus.
+
+## Alternatives considered
+
+### Using other ways to represent the built-in elements
+
+The proposed API above uses a CSS selectors to represent the built-in elements, but we’ve also considered some variants:
+
+ - Using “tagname + one attribute name + attribute’s value” combination,
+   e.g. `elementInternals.matchFocusBehaviorOf = {"input", "type," "button"}`
+   
+ - Using a predefined list of items representing the built-in elements.
+   The list would include all html tag names, `a[href]`,
+   `input[type=X]`, etc.

```suggestion
   `input[type=X]`, and any other special cases for elements whose focusability changes in interesting ways based on attributes.
```

> +### Using other ways to represent the built-in elements
+
+The proposed API above uses a CSS selectors to represent the built-in elements, but we’ve also considered some variants:
+
+ - Using “tagname + one attribute name + attribute’s value” combination,
+   e.g. `elementInternals.matchFocusBehaviorOf = {"input", "type," "button"}`
+   
+ - Using a predefined list of items representing the built-in elements.
+   The list would include all html tag names, `a[href]`,
+   `input[type=X]`, etc.
+   
+-  Using an element instance to follow, e.g. `elementInternals.matchFocusBehaviorOf = buttonElement;`
+
+All of the alternative API shapes below can be considered to replace the currently proposed API.
+
+### Follow focus behavior from an enumerated list of high-level concepts (e.g. `"text entry", "clickable", etc)

```suggestion
### Follow focus behavior from an enumerated list of high-level concepts (e.g. `"text entry"`, `"clickable"`, etc.)
```

> +
+All of the alternative API shapes below can be considered to replace the currently proposed API.
+
+### Follow focus behavior from an enumerated list of high-level concepts (e.g. `"text entry", "clickable", etc)
+
+Instead of following a certain tagname, we would instead follow a certain “high level” concept that covers all the built-in elements, so the enum list would be like like “option”, “button”, “text entry”, etc.
+
+Although this approach would be more descriptive, it might get out of date when a new way of focusing is added to the platform or other conventions change.
+
+### Allow setting default tabindex values
+
+One simple way to allow default focusability is to just add an `ElementInternals` version of `tabindex` so that even after being overridden by the custom element user, the default value can still be restored later.
+
+However, this means the custom element can’t exactly emulate the behavior of built-in elements that are skipped/not focusable in certain conditions depending on preferences, etc. For example, if someone wants to make a new awesome-checkbox element, they would probably want to follow the behavior of `<input type="checkbox>` to be consistent---even though that behavior varies across platforms.
+
+Additionally, `tabindex` is not powerful enough to emulate the built-in focus behaviors entirely. The possible behaviors are not focusable (omitted), programmatically-focusable/click-focusable/not sequentially-focusable (-1), and programmatically-focusable/click-focusable/sequentially-focusable (>=0). Such a `tabindex`-based API does not allow combinations such as programmatically-focusable/not click-focusable/not sequentially-focusable, like macOS Safari checkboxes, or programmatically-focusable/not click-focusable/sequentially-focusable, like macOS Safari checkboxes with the `Option` key held down.

```suggestion
Additionally, `tabindex` is not powerful enough to emulate the built-in focus behaviors entirely. The possible behaviors are not focusable (omitted), programmatically-focusable/click-focusable/not sequentially-focusable (< 0), and programmatically-focusable/click-focusable/sequentially-focusable (>=0). Such a `tabindex`-based API does not allow combinations such as programmatically-focusable/not click-focusable/not sequentially-focusable, like macOS Safari checkboxes, or programmatically-focusable/not click-focusable/sequentially-focusable, like macOS Safari checkboxes with the `Option` key held down.
```

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/webcomponents/pull/834#pullrequestreview-283704444