A responsive typography methodology for cleaner design systems and predictable web handoff.
rt-stylesheet gives every responsive typography style a predictable structure:
class-variant-breakpoint
Example:
title1-1-desktop
title1-1-tablet
title1-1-mobile
This gives designers a clear way to organise responsive text styles, and gives developers a reliable way to turn those styles into CSS.
Use rt-stylesheet to create typography systems that are easier to organise, review, complete, and hand off.
You should care about it if:
Start here: For Designers
Use rt-stylesheet as a naming contract for converting design typography into predictable responsive CSS.
You should care about it if:
Start here: For Developers
Typography in web design is not just one style.
A heading may be:
A paragraph may keep the same size but change line-height. A hero title may use the same desktop size as another heading, but scale down differently on mobile.
Without a system, teams often create text styles like:
Hero Heading
Hero Heading Mobile
Large Heading
Large Heading Tablet
Section Title
Section Title Mobile
Body Copy
Body Copy Small
These names may make sense in the moment, but they do not clearly explain how the styles relate to each other.
rt-stylesheet makes those relationships explicit.
Instead of naming styles only by how they look or where they are used, you name them by how they belong to the typography system.
Every responsive text style has three parts:
class-variant-breakpoint
Example:
title1-1-desktop
Read it like this:
title1 1 desktop
class variant breakpoint
In rt-stylesheet, a text style is a reusable typography decision that should become a reusable CSS output.
It should usually define:
A text style should not be created just because the text content changes.
Do not create new text styles only for:
Those are usually content, component, utility, or interaction decisions.
They should not become typography variants unless they also represent a reusable typography behaviour.
The class is a reusable name for a typography family in the system.
Examples:
title1
title2
title3
body1
body2
label1
caption1
eyebrow1
A class is not a visual ranking rule, and it is not tied to an HTML tag.
title1 does not have to mean “the largest heading”.
title2 does not have to be smaller than title1.
title1 does not have to be used only on an h1.
That older way of thinking mixes content structure with visual styling. In modern responsive systems, the HTML tag should describe the content structure, while the text style should describe the reusable typography treatment.
That means an h1, p, li, or any other element can use any approved text style when the design calls for it.
Use the class as a stable system name.
For example:
title1
can mean your first reusable title family.
body1
can mean your first reusable body family.
The number helps separate one reusable family from another. It should not be treated as a promise about size, importance, or HTML structure.
Class names must stay reusable and system-level.
Use:
title1-1-desktop
Do not use:
homepage-hero-heading-desktop
title1-1-desktop belongs to the typography system.
homepage-hero-heading-desktop is not valid in an rt-stylesheet setup because it describes a single layout instead of a reusable typography class.
If a hero needs its own reusable typography behaviour, create a structured variant instead:
title1-2-desktop
The variant is the number after the class.
Examples:
title1-1
title1-2
title1-3
Variants are useful when styles belong to the same typography family, but need a different reusable typography behaviour.
Example:
title1-1-desktop
title1-1-tablet
title1-1-mobile
title1-2-desktop
title1-2-tablet
title1-2-mobile
Both are title1 styles, but they are different variants.
Use variants when the style still belongs to the same typography level, but needs a meaningful difference such as:
Do not use variants only for text casing.
These should not become variants by themselves:
title1-2 = uppercase title1
title1-3 = lowercase title1
title1-4 = title case title1
Casing is usually a content or CSS utility decision. It does not change the responsive typography system.
Bold and italic should be handled carefully.
They can be part of a text style when the weight or italic style is a reusable typography decision.
Good examples:
body1-1-desktop
body1-1-tablet
body1-1-mobile
body1-2-desktop
body1-2-tablet
body1-2-mobile
This is okay if body1-2 is a deliberate reusable alternate body style, such as a stronger intro paragraph or a repeated editorial body treatment.
Do not create variants just because some words inside a paragraph are bold or italic.
Inline emphasis should usually stay as rich text content, such as bold or italic text inside a paragraph, rather than becoming a new rt-stylesheet variant.
Use this rule:
Reusable typography behaviour = text style or variant
Inline emphasis or casing = not a variant
This keeps the system flexible without becoming messy.
The breakpoint describes the screen-size version of the style.
The default breakpoint set is:
desktop
tablet
mobile
A complete default group looks like this:
title1-1-desktop
title1-1-tablet
title1-1-mobile
That tells everyone these three styles belong together.
If a style group only has:
title1-1-desktop
title1-1-mobile
then it is easy to see that the tablet version may be missing.
Some projects need more than desktop, tablet, and mobile.
rt-stylesheet can expand to support larger or more specific responsive systems.
Examples:
title1-1-desktop-xxl
title1-1-desktop-xl
title1-1-desktop
title1-1-tablet-xl
title1-1-tablet
title1-1-mobile-xl
title1-1-mobile
The same structure still applies:
class-variant-breakpoint
Only the breakpoint list grows.
This is useful for:
A small system might look like this:
title1-1-desktop
title1-1-tablet
title1-1-mobile
title2-1-desktop
title2-1-tablet
title2-1-mobile
body1-1-desktop
body1-1-tablet
body1-1-mobile
A larger system might include variants:
title1-1-desktop
title1-1-tablet
title1-1-mobile
title1-2-desktop
title1-2-tablet
title1-2-mobile
title2-1-desktop
title2-1-tablet
title2-1-mobile
body1-1-desktop
body1-1-tablet
body1-1-mobile
The important part is consistency.
Once the structure is clear, the system can grow without changing the logic.
You can immediately see which styles belong together.
title1-1-desktop
title1-1-tablet
title1-1-mobile
This is easier to audit than three unrelated names.
If your project uses desktop, tablet, and mobile styles, each class should usually have all three.
That makes missing styles obvious.
Instead of creating random alternate names, you can create structured variants.
title1-1
title1-2
title1-3
This keeps related styles grouped.
Developers do not need to guess which responsive styles belong together.
The structure already explains it.
A naming system should work when the project grows.
rt-stylesheet works whether you have 9 text styles or 90.
Before handoff, check:
Design typography is often visually organised but technically ambiguous.
A design file might include styles like:
Hero Heading
Hero Heading Mobile
Large Heading Tablet
Section Title
Body Copy Small
These names are readable, but they are not reliably parseable.
From those names alone, a developer cannot safely infer:
rt-stylesheet solves this by turning responsive typography names into structured input data.
The structure is:
class-variant-breakpoint
Example:
title1-1-desktop
Parsed:
{
"class": "title1",
"variant": "1",
"breakpoint": "desktop"
}
Generated CSS selector:
.title1-1
The generator also supports a direct attribute selector for the same style:
[rt-text-style="title1-1"]
This is useful when adding a class is not possible or not practical.
The breakpoint suffix determines where that style belongs in the responsive output.
A complete style group:
title1-1-desktop
title1-1-tablet
title1-1-mobile
can map to one responsive CSS class:
.title1-1,
[rt-text-style="title1-1"] {
font-family: var(--font-primary);
font-weight: 600;
font-size: 4rem;
line-height: 1.1;
letter-spacing: -0.02em;
}
@media screen and (max-width: 991.98px) {
.title1-1,
[rt-text-style="title1-1"] {
font-size: 3rem;
line-height: 1.15;
}
}
@media screen and (max-width: 479.98px) {
.title1-1,
[rt-text-style="title1-1"] {
font-size: 2.25rem;
line-height: 1.2;
}
}
The exact CSS output can vary by project.
The value of the methodology is that the source names contain enough structure to generate this safely.
Because the names are structured, responsive coverage can be calculated.
Example:
8 class variants
3 breakpoints
Expected styles:
8 × 3 = 24
If 22 styles are detected:
22 / 24 = 91.67% coverage
Missing styles:
24 - 22 = 2
So the system can report:
24 expected styles
22 detected styles
2 missing styles
91.67% coverage
This is a practical technical advantage.
The naming is not only readable. It is measurable.
Design files often need explicit breakpoint-specific styles.
Code usually needs fewer responsive classes.
Example:
24 text styles
8 class variants
3 breakpoints
With rt-stylesheet:
24 breakpoint-specific text styles
→ 8 responsive CSS classes
Example:
title1-1-desktop
title1-1-tablet
title1-1-mobile
becomes:
.title1-1
The breakpoint-specific values live inside the generated CSS rules.
Breakpoints are labels that can be mapped to viewport widths.
Example default map:
{
"mobile": 480,
"tablet": 992,
"desktop": 1440,
"desktop-xl": 1920,
"desktop-xxl": 3840
}
Example custom map:
{
"mobile": 390,
"mobile-xl": 640,
"tablet": 768,
"desktop": 1280,
"desktop-xl": 1440,
"desktop-xxl": 1920
}
The naming model stays the same.
Only the breakpoint map changes.
rt-stylesheet can support fixed responsive values or fluid interpolation.
Fixed output applies the value defined for each breakpoint.
.title1-1 {
font-size: 4rem;
}
@media screen and (max-width: 991.98px) {
.title1-1 {
font-size: 3rem;
}
}
@media screen and (max-width: 479.98px) {
.title1-1 {
font-size: 2.25rem;
}
}
Fluid output can interpolate between breakpoint values.
.title1-1 {
font-size: clamp(2.25rem, 1.5rem + 2vw, 4rem);
}
A structured naming system makes both approaches easier because each value belongs to a known class, variant, and breakpoint.
title1-1-desktop → .title1-1
title1-1-tablet → .title1-1
title1-1-mobile → .title1-1
Expected styles can be calculated from detected class variants and active breakpoints.
Structured names can be scanned, grouped, validated, and converted into CSS without relying on fragile manual mapping.
The system supports additional breakpoints without changing the naming model.
Designers own the typography decisions.
Developers receive predictable implementation data.
| Naming approach | Example | Designer-readable | Machine-parseable | Breakpoint-aware | Variant-aware | CSS-generation friendly |
|---|---|---|---|---|---|---|
| Visual naming | Hero Heading Mobile |
Yes | Weak | Inconsistent | Weak | Manual mapping needed |
| Page-specific naming | Homepage Hero Title |
Yes | Weak | Weak | Weak | Tied to layout |
| Token-only naming | font-size-heading-xl |
Medium | Strong | Needs extra structure | Weak | Partial |
| Utility naming | text-48 leading-110 |
Weak | Strong | Code-side only | Weak | Already implementation-focused |
rt-stylesheet |
title1-1-mobile |
Yes | Strong | Yes | Yes | Yes |
rt-stylesheet is designed specifically for responsive typography handoff, where class identity, variant identity, and breakpoint identity need to stay connected.
Coming soon: The ‘Rethink Stylesheet Generator’ Figma plugin is not yet live.
Rethink Stylesheet Generator is the Figma plugin built to help teams apply the rt-stylesheet methodology faster and more accurately.
The plugin can:
Create text styles using the methodology:
title1-1-desktop
title1-1-tablet
title1-1-mobile
Run the plugin and review:
If styles are missing, the plugin can generate suggested missing styles.
Generated styles are a starting point. Designers should review and refine them.
Choose:
Generate:
rt-stylesheet.css
Copy gives embed-ready code with a <style> wrapper.
Download gives a CSS file. If the rich text helper is enabled, download gives both the CSS file and the helper JS file.
You can also generate an editable typography stylesheet frame for handoff.
For designers, rt-stylesheet creates clarity.
For developers, it creates parseability.
For teams, it creates a cleaner handoff between responsive typography decisions and production CSS.
class-variant-breakpoint