Proposal: Add 'Opened' event to InfoBar

[gabbybilka]

Proposal: Add 'Opened' event to InfoBar

Summary

Add an 'Opened' event to InfoBar that would fire immediately after an InfoBar opened. See ContentDialog.Opened and ToolTip.Opened for similar events.

Rationale

• Would let the developer to account for any layout shifting that may need to occur due to the addition of an InfoBar.

Important Notes

Due to accessibility concerns, we do not recommend that a developer use this event to auto-close an InfoBar. Transient inline content, especially when the content is intended to be read/acknowledged, is not usable. See W3 links on predictability and time for more information.

Open Questions

• Is this a baseline requirement for the InfoBar control?
• How would you take advantage of the 'Opened' event in your application? Could you include a description of your application and intended situation of use?
  • Is an 'Opening' event also valuable for your usecase?

Note: I will do my best to keep up with community insights and contributions and add them to this proposal.

[michael-hawker]

Agree that adding this would help with folks transitioning from the InAppNotification in the Toolkit to InfoBar.

I know InfoBar isn't mean to fully encompass those scenarios currently, but it should in the future. This would be an initial step at least making it easier to use InfoBar for a more fully-featured InAppNotification wrapper if it never fully reaches parity.

Seems like TeachingTip is missing Opening / Opened as well.

[mdtauk]

Opening and Opened
Closing and Closed
IsOpen

These seem to be a basic structure for most of these kinds of Controls. What devs do with these basic states and actions doesn't matter all that much - but they should be overridable even if they probably do nothing by default.

[lukasf]

IMO it should be considered base behavior that a control communicates it's state. It does not really matter what this will be used for. While I agree that normal end user apps / store apps should try to comply with W3 standards as far as possible, it is not absolutely neccessary, and even Microsoft does not follow these guidelines strictly. Plus, the majority of software is developed in companies for internal use. If you only have a few, well known users for your app, it does not make sense to annoy them with accessibility stuff they don't even need.

A control should be designed to allow easy compliance with accessiblity standards, out-of-the-box. But we should not prohibit functionality, just because it could allow implementing behaviors that are not compliant with accessibility standards.

[XamlBrewer]

An 'Opened' event would be indeed an appropriate place for adapting layout, updating a counter, and/or starting a timer. The -already defined- 'Closed' event could then host the opposite action. Currently the API is unbalanced in this domain, with several events around closing ('CloseButtonClick', 'Closing', and 'Closed'), and not a single event on opening (although PropertyChanged could be used here).