dibk-designsystemet 1.0.0-rc.1 → 1.0.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/CHANGELOG.md +2 -2
- package/README.md +48 -90
- package/package.json +1 -1
package/CHANGELOG.md
CHANGED
|
@@ -5,9 +5,9 @@ Notable changes to `dibk-designsystemet`. Format follows
|
|
|
5
5
|
[semver](https://semver.org/), where a minor release may adjust visual details and a
|
|
6
6
|
major release changes the component API.
|
|
7
7
|
|
|
8
|
-
## 1.0.0-
|
|
8
|
+
## 1.0.0 - 2026-08-31
|
|
9
9
|
|
|
10
|
-
First release
|
|
10
|
+
First release.
|
|
11
11
|
|
|
12
12
|
### Added
|
|
13
13
|
|
package/README.md
CHANGED
|
@@ -1,9 +1,8 @@
|
|
|
1
1
|
# dibk-designsystemet
|
|
2
2
|
|
|
3
|
-
The DIBK design system.
|
|
4
|
-
|
|
5
|
-
|
|
6
|
-
Designsystemet has no equivalent for. One package, one install.
|
|
3
|
+
The DIBK design system. Takes [Designsystemet](https://designsystemet.no/), Digdir's design
|
|
4
|
+
system, applies the DIBK theme and adds the brand components, brand icons and layout
|
|
5
|
+
primitives that Designsystemet has no equivalent for.
|
|
7
6
|
|
|
8
7
|
```tsx
|
|
9
8
|
import { Button, Card, Table, DibkHeader, DibkFooter } from "dibk-designsystemet";
|
|
@@ -16,17 +15,17 @@ npm install dibk-designsystemet \
|
|
|
16
15
|
react react-dom @digdir/designsystemet-react @digdir/designsystemet-css @fontsource/poppins
|
|
17
16
|
```
|
|
18
17
|
|
|
19
|
-
Everything after the package name is a peer dependency, so
|
|
20
|
-
of React, of Designsystemet and of the font. Keep the two `@digdir/designsystemet-*`
|
|
18
|
+
Everything after the package name is a peer dependency, so the consuming app owns exactly
|
|
19
|
+
one copy of React, of Designsystemet and of the font. Keep the two `@digdir/designsystemet-*`
|
|
21
20
|
packages on the same version: their CSS class contract is version-coupled upstream, and npm
|
|
22
|
-
won't catch a mismatch
|
|
21
|
+
won't catch a mismatch.
|
|
23
22
|
|
|
24
|
-
|
|
23
|
+
Published to public npmjs, so there's no registry configuration to do, and the package
|
|
25
24
|
ships both ESM and CJS.
|
|
26
25
|
|
|
27
26
|
## Setup
|
|
28
27
|
|
|
29
|
-
Two CSS imports at
|
|
28
|
+
Two CSS imports at the app entry:
|
|
30
29
|
|
|
31
30
|
```ts
|
|
32
31
|
import "dibk-designsystemet/fonts.css"; // Poppins @font-face declarations
|
|
@@ -34,7 +33,7 @@ import "dibk-designsystemet/styles.css"; // everything else, in cascade order
|
|
|
34
33
|
```
|
|
35
34
|
|
|
36
35
|
`styles.css` pulls in Designsystemet's component CSS, the DIBK theme tokens, the brand base
|
|
37
|
-
(which puts the font on `<body>`),
|
|
36
|
+
(which puts the font on `<body>`), the component styles, the DIBK tailoring of Designsystemet's
|
|
38
37
|
components, and the layout primitives, in that order.
|
|
39
38
|
|
|
40
39
|
The JS entries import no CSS of their own, so Node can load them for SSR and so the CJS
|
|
@@ -47,8 +46,8 @@ resolves those inside CSS: Vite, webpack with css-loader, Next, Parcel or esbuil
|
|
|
47
46
|
|
|
48
47
|
## Usage
|
|
49
48
|
|
|
50
|
-
|
|
51
|
-
from here rather than from the base package:
|
|
49
|
+
Everything from `@digdir/designsystemet-react` is re-exported and already themed, so import
|
|
50
|
+
it from here rather than from the base package:
|
|
52
51
|
|
|
53
52
|
```tsx
|
|
54
53
|
import { Heading, Paragraph, Button, Card, Alert, Details } from "dibk-designsystemet";
|
|
@@ -64,8 +63,7 @@ function Example() {
|
|
|
64
63
|
}
|
|
65
64
|
```
|
|
66
65
|
|
|
67
|
-
|
|
68
|
-
Designsystemet's:
|
|
66
|
+
The DIBK components are prefixed `Dibk`, so it stays obvious which are which:
|
|
69
67
|
|
|
70
68
|
```tsx
|
|
71
69
|
import { DibkHeader, DibkMegaMenu, DibkFooter } from "dibk-designsystemet";
|
|
@@ -86,7 +84,7 @@ import { DibkHeader, DibkMegaMenu, DibkFooter } from "dibk-designsystemet";
|
|
|
86
84
|
| `DibkAccountMenu` | Header account control: initials avatar and dropdown (name, email, role, Logg ut) |
|
|
87
85
|
| `DibkMenuLogin` | "Logg inn" row for the mega-menu's `menuExtra` slot |
|
|
88
86
|
| `DibkCopyButton` / `DibkCopyIconButton` | "Kopier" button that flips to "✓ Kopiert!", plus a quiet icon-only variant |
|
|
89
|
-
| `DibkCodeBlock` |
|
|
87
|
+
| `DibkCodeBlock` | Labeled monospace block with an optional Kopier button |
|
|
90
88
|
|
|
91
89
|
All of them forward `className`, `style`, `ref`, `data-*` and the rest of their root
|
|
92
90
|
element's props, so they'll compose into whatever layout you have.
|
|
@@ -96,7 +94,7 @@ element's props, so they'll compose into whatever layout you have.
|
|
|
96
94
|
`DibkAppShell` is the page frame. It wires up the header, mega-menu, content container and
|
|
97
95
|
footer, and it owns the page width: children render inside the canonical container, so they
|
|
98
96
|
line up with the header and footer at every viewport width. Write one thin shell wrapper
|
|
99
|
-
|
|
97
|
+
per app and let the pages render content only.
|
|
100
98
|
|
|
101
99
|
```tsx
|
|
102
100
|
<DibkAppShell
|
|
@@ -109,36 +107,19 @@ for your app and let your pages render content only.
|
|
|
109
107
|
</DibkAppShell>
|
|
110
108
|
```
|
|
111
109
|
|
|
112
|
-
|
|
113
|
-
|
|
114
|
-
|
|
115
|
-
|
|
116
|
-
|
|
117
|
-
`DibkHeader`, `DibkMegaMenu`, `DibkFooter` and the shell's content container all use this
|
|
118
|
-
geometry, which is what makes their content edges line up. Two things will break that, and
|
|
119
|
-
both are easy to do by accident:
|
|
120
|
-
|
|
121
|
-
1. Painting a background or border on an element that has the container geometry. The color
|
|
122
|
-
fills the gutter padding too, and the panel then reads as wider than the top bar.
|
|
123
|
-
Colored panels go *inside* the container: they span the content column, and their own
|
|
124
|
-
padding is the panel's inset.
|
|
125
|
-
2. Hand-rolling the page width. Inside the shell your sections need no `max-width`,
|
|
126
|
-
`margin: auto` or side padding. If some surface genuinely can't use the shell, copy the
|
|
127
|
-
geometry exactly (`max-width: var(--dibk-container-max); margin-inline: auto;
|
|
128
|
-
padding-inline: var(--dibk-container-pad)`). A fixed side padding lines up at one window
|
|
129
|
-
size and drifts at every other, because the gutter is fluid.
|
|
110
|
+
`DibkHeader`, `DibkMegaMenu`, `DibkFooter` and the shell's content container share the same
|
|
111
|
+
page geometry, which is what makes their content edges line up. Inside the shell,
|
|
112
|
+
sections need no `max-width`, `margin: auto` or side padding; adding them will break the
|
|
113
|
+
alignment, because the side gutter is fluid rather than a fixed width.
|
|
130
114
|
|
|
131
115
|
## Layout primitives
|
|
132
116
|
|
|
133
117
|
Four composable layout components, the [Every Layout](https://every-layout.dev/) patterns,
|
|
134
|
-
so you don't hand-roll flex and grid CSS or invent a spacing scale per app.
|
|
135
|
-
|
|
136
|
-
`gap` prop mapped onto the design tokens.
|
|
118
|
+
so you don't hand-roll flex and grid CSS or invent a spacing scale per app. They have no
|
|
119
|
+
runtime, and spacing is a single `gap` prop mapped onto the design tokens.
|
|
137
120
|
|
|
138
|
-
They're unprefixed, because layout is
|
|
139
|
-
|
|
140
|
-
two star-exports is dropped from both rather than shadowing, so if we put them in the barrel
|
|
141
|
-
an upstream release adding its own `Grid` or `Stack` would break your imports.
|
|
121
|
+
They're unprefixed, because layout is generic, and they live on their own subpath so their
|
|
122
|
+
names can't collide with Designsystemet's.
|
|
142
123
|
|
|
143
124
|
```tsx
|
|
144
125
|
import { Stack, Cluster, Sidebar, Grid } from "dibk-designsystemet/layout";
|
|
@@ -156,8 +137,8 @@ import { Stack, Cluster, Sidebar, Grid } from "dibk-designsystemet/layout";
|
|
|
156
137
|
forwards `ref` plus the element's own props.
|
|
157
138
|
|
|
158
139
|
Spacing belongs to the layout, not to the component. Rather than putting a `margin` on a
|
|
159
|
-
component to push it off its neighbour, wrap the group in a `Stack` and let `gap` do it
|
|
160
|
-
|
|
140
|
+
component to push it off its neighbour, wrap the group in a `Stack` and let `gap` do it,
|
|
141
|
+
which keeps one spacing scale and avoids margin-collapsing surprises.
|
|
161
142
|
|
|
162
143
|
```tsx
|
|
163
144
|
// page sections
|
|
@@ -204,28 +185,10 @@ Tune it with `--l-sidebar-width` (side column, default `18rem`) and
|
|
|
204
185
|
`--l-grid-min` sets the minimum column width (default `16rem`). The grid fits as many equal
|
|
205
186
|
columns as that allows and reflows down without breakpoints.
|
|
206
187
|
|
|
207
|
-
### Container queries
|
|
208
|
-
|
|
209
|
-
Because the primitives reflow by available space, most layouts need no media queries at
|
|
210
|
-
all. When a component does have to restyle by its own width rather than the screen's, give
|
|
211
|
-
it a container context and query that. It'll then behave whether it lands in a wide `Stack`
|
|
212
|
-
list, a narrow `Grid` cell or a `Sidebar`:
|
|
213
|
-
|
|
214
|
-
```css
|
|
215
|
-
.card-frame { container: card / inline-size; } /* a wrapper the component renders */
|
|
216
|
-
@container card (min-width: 30rem) {
|
|
217
|
-
.card { grid-template-columns: auto 1fr; } /* reads the slot, not the viewport */
|
|
218
|
-
}
|
|
219
|
-
```
|
|
220
|
-
|
|
221
|
-
Watch out for one thing: a `@container` query reads an ancestor marked `container-type`,
|
|
222
|
-
never the element itself. That's why the component renders `frame > content` and the content
|
|
223
|
-
queries the frame. Keep viewport media queries for genuine page-level chrome.
|
|
224
|
-
|
|
225
188
|
## Theming
|
|
226
189
|
|
|
227
|
-
The theme is a set of `--ds-*` and `--dibk-*` CSS custom properties
|
|
228
|
-
provider. The DIBK signature:
|
|
190
|
+
The theme is a set of `--ds-*` and `--dibk-*` CSS custom properties, so there's no runtime
|
|
191
|
+
and no provider component to wrap the app in. The DIBK signature:
|
|
229
192
|
|
|
230
193
|
- Accent navy `#003045` and `border-radius: 0` everywhere.
|
|
231
194
|
- Poppins, with the weight tokens toned down a notch, because Poppins renders heavy.
|
|
@@ -236,7 +199,7 @@ provider. The DIBK signature:
|
|
|
236
199
|
### Card surfaces
|
|
237
200
|
|
|
238
201
|
Cards are flat, with no border. Pick the background with `data-dibk-color`, which tints the
|
|
239
|
-
panel and leaves buttons and headings navy.
|
|
202
|
+
panel and leaves buttons and headings navy. It's a dedicated attribute because
|
|
240
203
|
Designsystemet's `data-color` would cascade the whole color family and turn the buttons
|
|
241
204
|
blue too.
|
|
242
205
|
|
|
@@ -249,19 +212,11 @@ blue too.
|
|
|
249
212
|
<Card data-dibk-color="pink">…</Card>
|
|
250
213
|
```
|
|
251
214
|
|
|
252
|
-
### Changing the theme
|
|
253
|
-
|
|
254
|
-
`theme.css` is generated from a single brand color by `scripts/build-theme.mjs`, which calls
|
|
255
|
-
Designsystemet's `formatThemeCSS`. Change the script and run `pnpm theme`, don't edit the
|
|
256
|
-
generated file. Our tailoring of individual Designsystemet components lives in
|
|
257
|
-
`src/overrides.css` as plain unlayered rules, which win over Designsystemet's `@layer ds`
|
|
258
|
-
without needing `!important`.
|
|
259
|
-
|
|
260
215
|
## Icons
|
|
261
216
|
|
|
262
217
|
Thirteen DIBK brand illustrations as React components, on the `/icons` subpath. They're
|
|
263
|
-
multi-
|
|
264
|
-
and you can't
|
|
218
|
+
multi-color brand artwork (navy, orange, light blue, green), so they ignore `currentColor`
|
|
219
|
+
and you can't recolor them. For general UI iconography use Designsystemet's icons, which
|
|
265
220
|
come with `@digdir/designsystemet-react`.
|
|
266
221
|
|
|
267
222
|
```tsx
|
|
@@ -278,21 +233,21 @@ Available: `bygge-endre`, `byggevarer`, `byggteknisk`, `forskrift`, `forskrift-s
|
|
|
278
233
|
|
|
279
234
|
## Fonts
|
|
280
235
|
|
|
281
|
-
The brand font is Poppins, delivered through `@fontsource/poppins` as a peer
|
|
282
|
-
|
|
236
|
+
The brand font is Poppins, delivered through `@fontsource/poppins` (OFL-1.1) as a peer
|
|
237
|
+
dependency.
|
|
283
238
|
|
|
284
239
|
`fonts.css` declares the latin and latin-ext subsets at weights 300 to 700 as woff2,
|
|
285
|
-
pointing at the font files in
|
|
240
|
+
pointing at the font files in the installed `@fontsource/poppins`. The `unicode-range`
|
|
286
241
|
declarations mean a browser only downloads the subsets and weights a page actually renders.
|
|
287
242
|
|
|
288
|
-
|
|
243
|
+
For a different typeface, skip `fonts.css`, import `styles.css` alone and set
|
|
289
244
|
`--ds-font-family` yourself.
|
|
290
245
|
|
|
291
246
|
## Swagger UI skin
|
|
292
247
|
|
|
293
248
|
`swagger.css` is a standalone DIBK skin for [Swagger UI](https://swagger.io/tools/swagger-ui/),
|
|
294
249
|
for apps that expose an API browser. Swagger UI brings its own DOM and its own bundle, so
|
|
295
|
-
this is plain static CSS targeting its class names rather than a bundled entry:
|
|
250
|
+
this is plain static CSS targeting its class names rather than a bundled entry: the host
|
|
296
251
|
serves it as a static file and tells Swagger UI to inject it.
|
|
297
252
|
|
|
298
253
|
Two things have to end up on disk in this layout, because the stylesheet's `@font-face`
|
|
@@ -307,11 +262,11 @@ URLs are relative to the stylesheet:
|
|
|
307
262
|
<served-root>/fonts/poppins-latin-700-normal.woff2
|
|
308
263
|
```
|
|
309
264
|
|
|
310
|
-
The fonts come from the `@fontsource/poppins`
|
|
311
|
-
|
|
265
|
+
The fonts come from the `@fontsource/poppins` already installed as a peer dependency. They
|
|
266
|
+
are not bundled here, because Swagger UI has no bundler to resolve them through. Skip the
|
|
312
267
|
fonts and the skin still applies, it just falls back to system-ui.
|
|
313
268
|
|
|
314
|
-
Assemble the directory during
|
|
269
|
+
Assemble the directory during the build, for example in a Docker stage that has already
|
|
315
270
|
run `npm ci`:
|
|
316
271
|
|
|
317
272
|
```dockerfile
|
|
@@ -350,16 +305,19 @@ else to configure.
|
|
|
350
305
|
| `dibk-designsystemet/layout.css` | Layout primitive CSS alone |
|
|
351
306
|
| `dibk-designsystemet/swagger.css` | Standalone Swagger UI skin (see [above](#swagger-ui-skin)) |
|
|
352
307
|
|
|
353
|
-
|
|
354
|
-
compose a different cascade.
|
|
308
|
+
Use `styles.css` unless you have a reason not to; the granular CSS entries are there for
|
|
309
|
+
apps that need to compose a different cascade.
|
|
355
310
|
|
|
356
|
-
##
|
|
311
|
+
## Demo and support
|
|
357
312
|
|
|
358
|
-
|
|
313
|
+
`apps/demo` in the repository is a runnable app built on this package: an information page,
|
|
314
|
+
a component catalog and a full example site. The
|
|
315
|
+
[repository README](https://github.com/Arkitektum/dibk-designsystemet#readme) says how to
|
|
316
|
+
run it.
|
|
359
317
|
|
|
360
|
-
Missing a component, or
|
|
318
|
+
Missing a component, or having trouble with one? Open an
|
|
361
319
|
[issue](https://github.com/Arkitektum/dibk-designsystemet/issues).
|
|
362
320
|
|
|
363
|
-
|
|
364
|
-
|
|
365
|
-
|
|
321
|
+
## License
|
|
322
|
+
|
|
323
|
+
Copyright DIBK. All rights reserved. See `LICENSE.md`.
|
package/package.json
CHANGED