Distinguish beta from stable support in docs

[mhsmith]

This PR makes the following changes to the API support tables:

• Use a dimmed check mark to indicate beta support. Based on [widget audit] toga.Button #1761, everything is currently marked as beta except Button on macOS.
• Use a Unicode check mark rather than an image.
• Put RST replacements configuration in conf.rst rather than replicating it in every document

PR Checklist:

• All new features have been tested
• All new features have been documented
• I have read the CONTRIBUTING.md file
• I will abide by the code of conduct

[mhsmith]

These rules weren't previously working because the CSS class is on the div, not the table.

[mhsmith]

Actually, the reason they weren't working was that there was no div.body. The CSS class is on both elements, but in case this changes in the future, I've now removed the element name, leaving only the class.

[freakboy3742]

+1 to the idea; 1 small tweak needed to the execution, and a policy decision we need to make.

The gray being the only differentiator for beta isn't a good signal - if you're vision impaired, the difference my not be perceivable (my son is colour blind, and he wouldn't be able to tell the difference between the gray and black). A11y best practice is to use a different symbol as the key differentiating factor, with color/shade providing enhancement; I'd suggest "●", but I'm open to other suggestions.

The policy issue - what exactly does "beta" mean in this context?

There's a continuum of implementation here:

1. Widget doesn't exist
2. Widget exists, but has unimplemented features (e.g., set font on Android Selection)
3. Widget exists, but is deliberately missing features (e.g, "full screen" APIs on Mobile)
4. Widget exists and is fully featured.

Layered over this, there's testing/audit progress - Have we reached 100% coverage of the code that is there?

I'd like to suggest that we need a third state (alpha / ○), so that:

• blank The widget doesn't exist
• alpha / ○ The widget exists, but doesn't have 100% coverage
• beta / ● The widget exists, but there are unimplemented features; the features that are tested have 100% coverage (this will register as 100% coverage in tests, because we can # pragma nocover methods that aren't implemented.
• final / ✓ The widget exists, is fully implemented, and has 100% test coverage.

Whatever we land on as levels and their definition, we should also document what these mean; a short explanatory paragraph at the top of the full table should suffice; we should probably also add a "What do these symbols mean?" link from the individual widget tables back to that explanation.

[freakboy3742]

We should also add a "widget support table updated" item to the audit checklist so that updating this table isn't forgotten (I've just done this on Button).

[mhsmith]

As discussed, I don't think the distinction between incomplete-but-tested vs complete-but-untested is useful to show in the documentation. All the reader really wants to know is "can I rely on the full API being present and working".

The gray being the only differentiator for beta isn't a good signal - if you're vision impaired, the difference my not be perceivable

OK, I've replaced it with two different symbols, which also avoids all the complexity of dealing with dark mode.

we should probably also add a "What do these symbols mean?" link from the individual widget tables

I've added a small key table to each place where the symbols are used.

[freakboy3742]

Instead of including the same table on every page, how about adding a "What does this mean?" table caption that is a hyperlink to the main widget page, and a longer explanatory table on the widget-by-platform page. That would take up less space on the page, will result in less duplicated content, and gives us a chance to explain what we mean by "stable" and "beta".

Suggested change

	.. csv-filter::
	.. csv-filter:: :doc:`What does this mean? </reference/widgets_by_platform>`

with an extra CSS directive:

table.widget-support {
    caption-side: bottom;
}

[mhsmith]

OK, I've actually put the caption above the table, so it can replace the "Availability" headers you recently added to Label and Button.

[freakboy3742]

One suggested change inline.

[freakboy3742]

👍