Examples
Default sizes
Each heading level rendered without a size override. The visual styling tracks the
heading element's default styling — h1 is largest, h6 smallest.
h1 — default
h2 — default
h3 — default
h4 — default
h5 — default
h6 — default
Custom sizes
Same h1–h6 elements, each with an explicit size that intentionally mismatches the
semantic level. Demonstrates that the semantic heading level and the visual size are picked independently.
4xl title
3xl title
2xl title
xl title
lg title
md title
Heading level modifiers
pf-m-h1 through pf-m-h6 decouple heading STYLE from the semantic element level.
H1-styled title
H2-styled title
H3-styled title
H4-styled title
H5-styled title
H6-styled title
Page title
pf-m-page-title layers the page-heading treatment on a size or level modifier.
2xl page title
H1 page title
Documentation
Title props
Parameters accepted by
{#include components/data-display/title ... /}. Model mode: pass
titleModel=<Title> built in Java instead — the Java tab on each example shows the
builder. All are passed as Qute named parameters.
| Name | Type | Default | Description |
|---|---|---|---|
| * (content slot) | Slot | — |
Heading text, passed as the include body:
{#include components/data-display/title headingLevel="h2"}My title{/include}.
|
headingLevel
|
"h1" | "h2" | "h3" | "h4" | "h5" | "h6"
|
"h1"
|
Semantic heading tag. Drives the document outline and the accessibility tree — pick based on document structure, not visual size. |
size
|
"md" | "lg" | "xl" | "2xl" | "3xl" | "4xl"
|
pf-m-{headingLevel} (e.g. pf-m-h2 for an
h2)
|
Visual size. Renders pf-m-{size} on the heading. Choose independently of
headingLevel — large visual emphasis can sit at any semantic level. When
omitted, defaults to pf-m-{headingLevel} so the visual size tracks the
semantic level (matches PF React's default-sizes behavior).
|
id
|
String | — | DOM id, attached to the heading element. Useful for in-page jump links and ARIA labelling. |
Divergence from PF React. PF's React component marks headingLevel as
required and exposes ouiaId / ouiaSafe testing-tooling
attrs. We default headingLevel to "h1" (more forgiving for
callers) and skip the OUIA attrs — we don't use OUIA-based assertions anywhere in this project yet.
Usage
Semantic level vs. visual size. Pick headingLevel based on the
document outline — the order of sections under the page's h1. Pick
size based on the visual emphasis you want. The two are independent. A sidebar callout
might be h2 for the outline but only rendered at
size="lg"; a hero unit might be h1 at
size="4xl".
One h1 per page. The heading level you pick participates in the
accessibility tree — keep one h1 per route (typically the page title), and nest deeper
levels under it. The Title component doesn't enforce this; it's a markup rule you maintain at the page level.
Jump-link anchors. Pass id when you want to link to the heading from a
TOC or another part of the page. Combine with the jump-links pattern (see
structure/jump-links) for in-page navigation.
When to compose by hand instead. Some PF runtime components (about-modal, login-page, empty-state) hard-code
<h1 class="pf-v6-c-title pf-m-4xl">
directly because they need the heading inside very specific sibling chrome. Both approaches ship the same markup —
the include just centralises the heading-level switch.