Add More Pseudoclasses To ContainerButton

[Aeshus]

About the PR

Instead of only allowing for one pseudoclass for a ContainerButton, I've made it set all applicable pseudoclasses.

I also added a new Pressing pseudoclass to cover the case that they are AttemptingPress.

The DrawMode variable is now obsoleted as they should just read the properties they want directly.

Unlike a previous version, there shouldn't be any inheritance breaking changes.

Why / Balance

This is useful for working with the CheckBox, which needs a specific hover state for when it's already Pressed which is different from the normal hover. Plus, we can have it so that now hovering or trying to click a disabled button looks different.

With the pressing state, we're now able to specifically style when the user is attempting to press, which used to default to Pressed even if not toggled yet, which caused some issues when styling PressedHover vs. just Hover.

Media

Content with new styles (w/ RT):

Current (w/ RT):

Content with flipped style properties (w/ RT):

Current:

Migration(s)

Most states will have no style changes, except for when it's in the new Pressing state. Currently it will default to StylePropertyHover + Pressed/Normal when hovered, and default to Pressed/Normal when the mouse is still pressed down but moved away, which is different from the old default to Pressed.

The rest will all be the same except if there's a conflict over selector precedence. If a fork (doesn't happen in content) defines e.g. Disabled before Pressed or Normal after Hover, it will just pick the rule that comes later iirc, which will cause visual inconsistancies.

Changes

Added a new Pressing StylePseudoClass to ContainerButton, for when the user in attempting to hover.

Changed the StylePseudoClass in ContainerButton to now set all applicable PseudoClasses (Hover/Normal/Pressed/Pressing/Disabled) for more styling opportunities. This may require some stylesheet adjustments.

Created a new public field, AttemptingPress, which tells if the user is trying to press a BaseButton.

[PJB3005]

I hate to do this but the way this is implemented, this is a breaking change for inheritors. Can that be avoided?

[Aeshus]

I hate to do this but the way this is implemented, this is a breaking change for inheritors. Can that be avoided?

Do you mean the case where a control like Content's MenuButton now needs to check another case DrawMode.PressedHover (and if it doesn't do so, it can hit a default case and look weird as it reads the DrawMode directly) or do you mean how there's now two PseudoClasses that can cause selector issues?

[PJB3005]

Do you mean the case where a control like Content's MenuButton now needs to check another case DrawMode.PressedHover (and if it doesn't do so, it can hit a default case and look weird as it reads the DrawMode directly

Yes, that one

[Aeshus]

Yes, that one

Yeah I think I can get that to work.

I'll get to this later, but: it should be possible to expose more of BaseButton's visual state (either through a bitmask enum similar to DrawMode or just added some new fields) and then read those in ContainerButton to set the appropriate PseudoClasses. I'd keep DrawMode the same and [Obsolete] it so people will switch to reading the specific fields they want.

[Aeshus]

This should hopefully address your concerns with the inheritance problem, though I'll need to write up a new PR description & title as I made some changes.

Basically I did what I described earlier, but I also added the Pressing StylePseudoClass as I had to make the AttemptingPress thing public, and because I want it anyways. (Though this causes a breaking styling change as it no longer jumps to StylePseudoClassPressed when attempting to press, but I think it's worth it...).

Also documented the StylePseudoClasses for clarity + because Julian has been bugging us about RT documentation...

Let me know if you'd rather me split up this PR into two.