PedanticDesign System · aCo

Buttons

Buttons trigger an action. In Pedantic they are always filled pills — never blue, never underlined — with Title Case labels that say what happens.

Variants

Live example — button variants

<button class="pds-btn pds-btn--primary" type="submit">Save Changes</button>
<button class="pds-btn pds-btn--secondary" type="button">Cancel</button>
<button class="pds-btn pds-btn--navy" type="button">View Report</button>
<button class="pds-btn pds-btn--danger" type="button">Delete Project</button>

Sizes

Live example — button sizes

<button class="pds-btn pds-btn--primary pds-btn--sm" type="button">Small</button>
<button class="pds-btn pds-btn--primary" type="button">Default</button>
<button class="pds-btn pds-btn--primary pds-btn--lg" type="button">Large</button>

Links that act like buttons

When an action navigates — a call to action that goes somewhere — use an <a> with the button classes. It keeps the pill shape and drops the underline in every state.

Live example — link styled as a button

Read the Foundations

<a class="pds-btn pds-btn--primary" href="/foundations.html">Read the Foundations</a>

Disabled state

Live example — disabled button

<button class="pds-btn pds-btn--primary" type="button" disabled>Save Changes</button>

Rules

Do

Use Title Case labels that name the outcome: “Save Changes”, “Download Report”, “Add Contact”.

Keep one primary button per view.

Don’t

Never style a button blue or as an underlined link.

Never label a button “Click Here”, “OK”, or “Submit” when the outcome can be named.

Never disable a button without a visible reason nearby — prefer keeping it enabled and explaining what is missing.

Accessibility notes