canonical / canonical/vanilla-framework

Purpose of notification’s “p-notification__status” isn’t obvious

Open
#2,669 7 comments 0 reactions 0 assignees View on GitHub
Documentation 📝 P3 Triaged Priority: Low Review: Code needed Triaged: v4
Dominant language
HTML
Stars
983
Forks
216
Avg merge
3d 13h
Merged PRs (30d)
3

Description

## Pattern to amend

[Notification](https://docs.vanillaframework.io/patterns/notification/)

## Visual

TBD

## Context

[Expanded from #2664]

Twice this week I’ve seen the boilerplate `p-notification__status` text from Vanilla’s examples copied into production code where it isn’t appropriate:
- [“Information: MicroStack requires at least 8 GB of RAM and a multi-core processor.”](https://github.com/canonical-web-and-design/microstack.run/pull/13#discussion_r347842298)
- [“Success: Thank you”](https://github.com/canonical-web-and-design/ubuntu.com/pull/6162#discussion_r349003857)

All else being equal, if it’s possible to convey something effectively with visual design, that’s better than doing it with text, because it’s quicker to comprehend.

That’s why in most component libraries — including Vanilla — an alert’s visual design conveys what kind of notification it is. That makes vague text like “Information” or “Success” an anti-pattern. Many libraries allow alerts to have headings, but they do not use headings for that purpose.

What should happen:
- In Vanilla’s code examples, `` should not contain “Warning:”, “Error:”, “Success:”, or “Information:” that could be mistaken for a real suggestion.
- The reference should describe when to use `p-notification__status`, and what kind of text it should contain.

Contributor guide

Open the contributing guide

Research direction

Start with the linked Notification pattern reference and its code examples, then review uses of p-notification__status. Update the examples so status text is not misleading boilerplate, and ensure the reference explains when to use the element and what its text should contain.

Written by the indexing model from the issue text.

Assessment

Tech stack
html
Domain
documentation
Issue type
Documentation
Difficulty
2/5
Estimated time
Half a day
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.