Document the use of last-body-child for top-most positioning

[fergald]

We should explain that we are going to use the fact that last element of is top-most on the screen.

I'm also bit concerned about this. For showToast we can do that but is the page author responsible for making sure their <std-toast> elements are last in the body, this seems to break modularity, e.g. a custom element couldn't come with a built-in toast (or at least that built-in toast couldn't live inside the custom element DOM tree, maybe that's OK). Will we move toasts around? If we allow multiple toasts to stack, are we going to reorder them in the DOM so they stack correctly?

[domenic]

This is a good thing to explore.

What I had in my head is that people who don't put it as the last child of the body, are explicitly wanting to scope their toast to a component. (This is a feature of the majority of libraries, "Display in Container".) So that would be more rare.

One potential outcome here is that we deemphasize the markup-based approach, guiding people toward showToast() as the primary entry point to the API. The element still needs to exist, as there needs to be a DOM representation of the toast somewhere since we're rendering it. But it would be deemphasized. This approach would be hard to do right now because of the uncertainties around the showToast() API options for actions and HTML (#11, #12), so the current README doesn't go in that direction. But it's something to keep in mind.

[scottaohara]

Noting of offline comments:

The placement of the component in the DOM is going to have an impact on how easily accessible the messaging component will be to people using keyboards/screen readers, especially in instances where the component is injected with JavaScript and not manually set in the DOM.

But that lead to the discussion of If there was inherit browser functionality to "jump to / cycle through messages" that could be a potential solution for providing equal access to these sorts of pop-up messages. With the addition of some sort of audio indicator to ensure people using screen magnification would be aware something has popped-up but is out of their current magnification view. And we noted that it'd be important for someone cycling through these messages to return to the last element in the DOM that had focus prior to using a potential keyboard shortcut to navigate to / through the messages/notifications.