One placement's worth of [`duxt.announcements`](/reference/configuration). The layout draws two of these — `above-header` and `below-header` — and the documentation page draws the third, `above-content`, in its own column. ## Usage ```vue ``` ## API | Prop | Type | Notes | | :---------- | :------------------------------------------------ | :---------------------------- | | `placement` | `above-header`, `below-header` or `above-content` | Required. Which strip to draw | Everything else it reads from `duxt.announcements` and `duxt.announcementOptions.maxVisible`. With nothing configured for that placement it renders no element at all — not an empty bar, and no space held open for one. ## Notes It draws **after hydration**, never in the prerendered HTML. Both of the questions it answers belong to the reader rather than to the build: whether they have already closed a notice, which lives in their browser, and whether the notice is inside its window, which is their clock. A page written out at build time would carry both answers from whenever the site was last deployed. The window is watched with **one timer for the whole page**, set to the next moment any announcement opens or closes — so a notice scheduled for next week costs a sleeping timer rather than a tick a second, and a page left open overnight is right in the morning. A dismissal is remembered against the announcement's identity, which is [locale-independent](/reference/configuration): the same notice closed in English stays closed in German. Overriding it is [overriding any component](/guides/override-the-theme) — a `DuxtAnnouncements.vue` of your own in `app/components/` wins. The selection logic is separate from the markup for exactly that reason: `duxtVisibleAnnouncements`, `duxtAnnouncementKey` and `duxtAnnouncementActive` are auto-imported, so a replacement decides how a notice looks without re-deriving when it shows.