| title | Wiki.js CSS & Layout Gallery |
|---|---|
| description | Responsive Wiki.js layout patterns using verified Iris documentation data |
| published | true |
| date | 2026-08-27 00:00:00 UTC |
| tags | meta, wikijs, css, layouts, examples |
| editor | markdown |
| dateCreated | 2026-08-27 00:00:00 UTC |
Use this page as a visual menu when designing a Volmit wiki page. Every preview uses real Iris documentation content, responsive CSS, semantic HTML, and Git-friendly page source. The patterns are intentionally different: choose one or combine two instead of putting every pattern on one production page.
For a finished plugin landing page that combines several of these ideas, see Adapt — Complete CSS Page Example.
These previews require Wiki.js Markdown Allow HTML and a sanitizer policy that permits inline
styleattributes. That matches the current Volmit home page. If inline styles are removed on your Wiki.js instance, use the class-based stylesheet near the end of this page. {.is-warning}
- 1 — Product hero
- 2 — Choose-your-path navigation
- 3 — Bento feature grid
- 4 — Quick-start steps
- 5 — Compatibility dashboard
- 6 — Command center
- 7 — Split feature panel
- 8 — Vertical timeline
- 9 — Platform comparison cards
- 10 — Operations checklist
- CSS building blocks
- Class-based stylesheet {.grid-list}
| Rule | Why it helps |
|---|---|
| One primary action per section | Readers can decide without scanning a wall of equal-weight links |
auto-fit grids |
Cards collapse naturally without page-specific breakpoints |
clamp() spacing and type |
The design scales smoothly between phone and desktop widths |
color: inherit on neutral cards |
Text remains readable in Wiki.js light and dark themes |
| Text plus color | Status never depends on color alone |
| Real links and headings | The page remains keyboard, screen-reader, and search friendly |
| Inline styles only for the demo | Production components are easier to maintain with scoped classes |
| {.dense} |
The examples use /home-assets/iris.png, current Iris routes, Minecraft 26.2,
Java 25, and current command syntax from the Iris documentation.
Best for: a plugin landing page with one sentence, two actions, and only the most important compatibility facts.
Build deterministic terrain, biomes, caves, objects, and structures from editable JSON packs—across Bukkit and mod-loader servers.
The useful CSS ideas are clamp() for fluid sizing, decorative shapes behind
content, flex-wrap for actions, and a constrained text width inside a
full-width panel.
Best for: a documentation index where readers arrive with different goals. This is usually easier to navigate than a flat list of twenty pages.
01 Run a server Choose the correct jar, install Iris, and create a managed world. Start installing → 02 Author a pack Learn dimensions, regions, biomes, generators, and pack layout. Learn the model → 03 Operate production Validate, pre-generate, back up, diagnose, and recover worlds. Open runbooks → 04 Use the API Query terrain and subscribe to engine, world, and pregen events. Build an integration →The whole card is a real anchor, so its click target is generous. The grid automatically changes column count as room becomes available.
Best for: showing product breadth without making every feature look equally important. Use short copy; this pattern becomes crowded quickly.
Dimensions connect regions, biomes, generators, objects, and structures. Production worlds keep a snapshot while Studio hotloads your working pack.
◒Noise, expressions, caves, carving, and image maps.
♣Surfaces, decorators, deposits, entities, and custom climate.
◇Single objects, multi-piece jigsaws, and vanilla passthrough.
⌘Disposable authoring worlds, schemas, previews, and hotload.
≋Matching artifacts, packs, seeds, and areas produce identical chunks.
grid-column: 1 / -1 makes the summary span every available column without a
media query. The smaller cards then flow beneath it.
Best for: installation, migration, authoring, or any sequence where order matters. Each step ends in an observable result.
Choose the plugin or mod jar, place it in the server, then start once.
RESULT: Iris enables cleanly 2Run /iris create name=demo type=overworld seed=1337.
Teleport in, inspect the terrain, and confirm the expected pack and seed.
RESULT: new chunks are Iris terrain 4Open a Studio world and edit the live pack with generated VSCode schemas.
NEXT: build your own dimensionRead the complete getting-started guide →
Best for: requirements, current support, release readiness, or a project status overview. The top row answers “will this run?” at a glance.
iris.all
/iris replace is Paper-family only; Spigot still supports managed iris:* worlds.var(--v-background-base, #fff) uses the Wiki.js theme value when present and
falls back safely. For stronger dark-mode control, use the class-based version
below.
Best for: a compact command overview. Show common tasks here, then link to the exhaustive reference instead of copying the entire command tree.
/iris create name=demo type=overworld seed=1337/iris pregen start radius=5000 world=demo center=0,0/iris pregen status.
Open a temporary authoring world
/iris studio open overworld seed=1337Open the full command and permission reference →
Best for: explaining one important concept with a visual on one side and the next action on the other.
A dimension is the root configuration for one world type. It defines the height range, generation modes, regions, and native content that Iris imports.
- One dimension file describes one world's rules.
- Regions divide the map; biomes fill regions.
- Generators produce the terrain height.
Because the two columns use auto-fit, the explanation stacks beneath the
visual when each side can no longer keep its minimum width.
Best for: release flows, world lifecycle, migrations, or “what happens next” explanations.
Use Studio, schemas, and pack validation before a production world exists.
CREATEIris copies the selected pack into <world>/iris/pack.
New chunks use the copied pack, seed, and current engine artifact.
CHANGEEditing the original live pack does not alter an existing production snapshot.
The line is a border on each item, and the marker is absolutely positioned relative to that item. The final item hides its continuing line.
Best for: helping the reader select one of a few mutually exclusive options. Put the recommendation in the heading instead of hiding it below a large table.
Paper, Purpur, Leaf, or Canvas using the plugin jar.
- Full managed world workflow
- Exact vanilla-slot replacement
- Broad Bukkit integrations
The same plugin jar with region-safe scheduling.
- Live managed world creation
- Folia-aware scheduling
- Platform-specific lifecycle notes
Choose the jar built for the server's exact loader.
- Same core generation engine
- Optional client HUD
- Brigadier command forms
display: flex; flex-direction: column plus margin-top: auto keeps the action
buttons aligned even when descriptions have different lengths.
Best for: deployment gates, maintenance windows, destructive procedures, and runbooks. The visual hierarchy separates readiness from the dangerous action.
World folder, Iris settings, and the exact pack snapshot Record identity
Platform artifact, Iris build, pack bytes, and seed Move players
Evacuate the target world before lifecycle changes Plan rollback
Know the restore point and exact validation command
/iris remove <world> delete=true deletes the managed world by default. Treat the backup as part of the command.
The checkboxes are disabled on purpose: this is a readable runbook, not a persistent task application. Use plain list markers if your sanitizer removes form controls.
These small declarations account for most of the layouts above.
display: grid;
grid-template-columns: repeat(auto-fit, minmax(220px, 1fr));
gap: 1rem;auto-fit fills the row; minmax() prevents unreadably narrow cards; 1fr
shares remaining space.
padding: clamp(1.25rem, 4vw, 3rem);
font-size: clamp(1.8rem, 6vw, 4rem);The first value is the minimum, the middle value scales with the viewport, and the final value is the maximum.
color: inherit;
background: rgba(127, 127, 127, 0.07);
border: 1px solid rgba(127, 127, 127, 0.26);
border-radius: 14px;Mid-gray with low opacity adapts to both light and dark backgrounds. Do not use
faint gray text for essential information; opacity also reduces contrast.
display: flex;
flex-direction: column;
height: 100%;Then give the final action margin-top: auto. This pins it to the bottom.
min-width: 0;
overflow-x: auto;
white-space: pre;min-width: 0 matters when the code block is inside a CSS grid or flex item.
Inline styles cannot express pseudo-classes or user preferences. Put these in the administrator stylesheet when using custom interactive cards:
.volmit-gallery a:focus-visible {
outline: 3px solid #52d7c2;
outline-offset: 3px;
}
@media (prefers-reduced-motion: no-preference) {
.volmit-gallery .interactive-card {
transition: transform 160ms ease, box-shadow 160ms ease;
}
.volmit-gallery .interactive-card:hover {
transform: translateY(-3px);
box-shadow: 0 12px 28px rgba(0, 0, 0, 0.16);
}
}Hover is enhancement only. Never hide content or the only action until hover.
For a reusable production design, an administrator can place the following
scoped CSS in Administration → Theme → CSS Override. The
.volmit-gallery prefix limits collisions, but the setting is still global to
the wiki.
.volmit-gallery {
--vg-accent: #7658d6;
--vg-accent-2: #0b8f82;
--vg-surface: rgba(127, 127, 127, 0.07);
--vg-border: rgba(127, 127, 127, 0.26);
--vg-radius: 16px;
}
.volmit-gallery .vg-grid {
display: grid;
grid-template-columns: repeat(auto-fit, minmax(220px, 1fr));
gap: 1rem;
}
.volmit-gallery .vg-card {
display: flex;
flex-direction: column;
min-width: 0;
padding: 1.25rem;
color: inherit;
background: var(--vg-surface);
border: 1px solid var(--vg-border);
border-radius: var(--vg-radius);
}
.volmit-gallery a.vg-card {
text-decoration: none;
}
.volmit-gallery .vg-card > :last-child {
margin-bottom: 0;
}
.volmit-gallery .vg-action {
display: inline-block;
align-self: flex-start;
margin-top: auto;
padding: 0.7rem 1rem;
color: #fff;
font-weight: 700;
text-decoration: none;
background: var(--vg-accent);
border-radius: 9px;
}
.volmit-gallery .vg-command-layout {
display: grid;
grid-template-columns: minmax(180px, 0.7fr) minmax(260px, 1.3fr);
}
.volmit-gallery a:focus-visible {
outline: 3px solid #52d7c2;
outline-offset: 3px;
}
@media (max-width: 720px) {
.volmit-gallery .vg-command-layout {
grid-template-columns: 1fr;
}
}
@media (prefers-reduced-motion: no-preference) {
.volmit-gallery .interactive-card {
transition: transform 160ms ease, box-shadow 160ms ease;
}
.volmit-gallery .interactive-card:hover {
transform: translateY(-3px);
box-shadow: 0 12px 28px rgba(0, 0, 0, 0.16);
}
}
@media (prefers-color-scheme: dark) {
.volmit-gallery {
--vg-surface: rgba(255, 255, 255, 0.06);
--vg-border: rgba(255, 255, 255, 0.16);
}
}Example class-only markup:
<section class="volmit-gallery">
<div class="vg-grid">
<article class="vg-card">
<h3>Author a pack</h3>
<p>Learn the content model, then build a minimal dimension.</p>
<a class="vg-action" href="/iris/05-concepts-pack-layout">Start authoring</a>
</article>
</div>
</section>CSS Override affects every page and must be managed outside this Git-backed Markdown repository. Keep the page understandable if the custom stylesheet is unavailable, and record any required global CSS in the repository. {.is-warning}
| Page type | Recommended combination |
|---|---|
| Plugin landing page | Layout 1 hero → Layout 2 paths → Layout 3 features → ordinary support links |
| Installation guide | Short intro → Layout 5 requirements → Layout 4 steps → Wiki.js warnings |
| Command reference | Ordinary table of contents → Layout 6 common jobs → searchable Markdown tables |
| Concept guide | Layout 7 split explanation → normal prose and examples → Layout 8 lifecycle |
| Platform chooser | Layout 9 cards → detailed comparison table → installation steps |
| Destructive runbook | Layout 10 gate → exact command → verification → rollback |
| {.dense} |
Do not use a hero, bento grid, dashboard, timeline, and comparison cards merely because they exist. A strong page normally needs one primary visual pattern and one supporting pattern; the rest should be headings, prose, tables, and code.
- Test the page at phone, tablet, and desktop widths.
- Tab through every link and make sure focus is visible.
- Confirm text remains readable in light and dark Wiki.js themes.
- Keep a real heading structure; cards do not replace document navigation.
- Use verified plugin data and exact command syntax.
- Prefer a standard Wiki.js alert for critical safety information.
- Check that the page still makes sense if custom CSS does not load.
- Link to the full reference instead of duplicating large tables. {.grid-list}
For syntax, renderer modules, Wiki.js attributes, diagrams, tabs, images, and other non-layout features, use Wiki.js Page Examples.