+
+When the `on_key` method returns, Textual will get the next event from the the queue and repeat the process for the remaining keys. At some point the queue will be empty and the widget is said to be in an *idle* state.
+
+!!! note
+
+ This example illustrates a point, but a typical app will be fast enough to have processed a key before the next event arrives. So it is unlikely you will have so many key events in the message queue.
+
+
+
+
+## Default behaviors
+
+You may be familiar with Python's [super](https://docs.python.org/3/library/functions.html#super) function to call a function defined in a base class. You will not have to use this in event handlers as Textual will automatically call handler methods defined in a widget's base class(es).
+
+For instance, let's say we are building the classic game of Pong and we have written a `Paddle` widget which extends [Static][textual.widgets.Static]. When a [Key][textual.events.Key] event arrives, Textual calls `Paddle.on_key` (to respond to ++left++ and ++right++ keys), then `Static.on_key`, and finally `Widget.on_key`.
+
+### Preventing default behaviors
+
+If you don't want this behavior you can call [prevent_default()][textual.message.Message.prevent_default] on the event object. This tells Textual not to call any more handlers on base classes.
+
+!!! warning
+
+ You won't need `prevent_default` very often. Be sure to know what your base classes do before calling it, or you risk disabling some core features builtin to Textual.
+
+## Bubbling
+
+Messages have a `bubble` attribute. If this is set to `True` then events will be sent to a widget's parent after processing. Input events typically bubble so that a widget will have the opportunity to respond to input events if they aren't handled by their children.
+
+The following diagram shows an (abbreviated) DOM for a UI with a container and two buttons. With the "No" button [focused](#), it will receive the key event first.
+
+
+
+The App class is always the root of the DOM, so there is no where for the event to bubble to.
+
+### Stopping bubbling
+
+Event handlers may stop this bubble behavior by calling the [stop()][textual.message.Message.stop] method on the event or message. You might want to do this if a widget has responded to the event in an authoritative way. For instance when a text input widget responds to a key event it stops the bubbling so that the key doesn't also invoke a key binding.
+
+## Custom messages
+
+You can create custom messages for your application that may be used in the same way as events (recall that events are simply messages reserved for use by Textual).
+
+The most common reason to do this is if you are building a custom widget and you need to inform a parent widget about a state change.
+
+Let's look at an example which defines a custom message. The following example creates color buttons which—when clicked—send a custom message.
+
+=== "custom01.py"
+
+ ```python title="custom01.py" hl_lines="10-15 27-29 42-43"
+ --8<-- "docs/examples/events/custom01.py"
+ ```
+=== "Output"
+
+ ```{.textual path="docs/examples/events/custom01.py"}
+ ```
+
+
+Note the custom message class which extends [Message][textual.message.Message]. The constructor stores a [color][textual.color.Color] object which handler methods will be able to inspect.
+
+The message class is defined within the widget class itself. This is not strictly required but recommended, for these reasons:
+
+- It reduces the amount of imports. If you import `ColorButton`, you have access to the message class via `ColorButton.Selected`.
+- It creates a namespace for the handler. So rather than `on_selected`, the handler name becomes `on_color_button_selected`. This makes it less likely that your chosen name will clash with another message.
+
+
+## Sending events
+
+In the previous example we used [emit()][textual.message_pump.MessagePump.emit] to send an event to it's parent. We could also have used [emit_no_wait()][textual.message_pump.MessagePump.emit_no_wait] for non async code. Sending messages in this way allows you to write custom widgets without needing to know in what context they will be used.
+
+There are other ways of sending (posting) messages, which you may need to use less frequently.
+
+- [post_message][textual.message_pump.MessagePump.post_message] To post a message to a particular widget.
+- [post_message_no_wait][textual.message_pump.MessagePump.post_message_no_wait] The non-async version of `post_message`.
+
+
+## Message handlers
+
+Most of the logic in a Textual app will be written in message handlers. Let's explore handlers in more detail.
+
+### Handler naming
+
+Textual uses the following scheme to map messages classes on to a Python method.
+
+- Start with `"on_"`.
+- Add the messages namespace (if any) converted from CamelCase to snake_case plus an underscore `"_"`
+- Add the name of the class converted from CamelCase to snake_case.
+
+