Only accept styles which are applicable to the widget

[mhsmith]

Originally posted by @mhsmith in #3011

There's no documentation of which styles are applicable to which widgets.

There's no runtime validation either – inapplicable styles are silently ignored with no warnings or errors, so the developer doesn't know what they've done wrong.

Because of this, any interactive GUI builder would need to offer all styles on all widgets, cluttering the UI.

---

Originally posted by @freakboy3742 in #3011

This is definitely true of the current Toga implementation - but I don't agree that it's fundamentally unresolvable. It strikes me as a gap of metadata, not a limitation of Toga's existing design.

The manual solution is to annotate the "applicable" styles on each class. This doesn't strike me as an especially onerous task to add - certainly a lot less invasive than a full redesign of Toga's style implementation.

However, my initial impression is that all this metadata could be largely (if not entirely) determined by inspection Applicator implementations - if a widget doesn't declare an implementation of the set_font Applicator interface, you can infer that it won't honor font_face, font_size, etc.

[mhsmith]

The manual solution is to annotate the "applicable" styles on each class.

As discussed in #3011, containers would also need to list the layout-related styles that are applicable to their children, such as flex. And a root widget wouldn't be able to use any of these properties.

[freakboy3742]

For the sake of completeness - it's also worth noting that HTML doesn't prevent meaningless CSS styles from being set on a DOM element. That's arguably so that the cascading part of CSS can cascade without tripping over settings that aren't valid - but it's an argument that a "strict" API surface has precedent. Whether it's preferable is a matter of API design choice - but it's possible to differentiate between metadata that allows a GUI builder to have sufficient context to populate a GUI, and enforcement of an API surface.

There might even be space for a "sliding" verbosity scale here - making an "invalid" style an error, a warning, or silent, depending on preference.