tuix-webcomponents 0.0.29 → 0.0.31

package/README.md

@@ -12,8 +12,8 @@ npm i tuix-webcomponents
 
 ### Webbundle version
 
-Webbundle Link: https://tuix-webcomponents.s3.eu-central-1.amazonaws.com/build-22f6faf@0.91.1.js  
-Styles Link: https://tuix-webcomponents.s3.eu-central-1.amazonaws.com/build-22f6faf@0.91.1.css
+Webbundle Link: https://tuix-webcomponents.s3.eu-central-1.amazonaws.com/build-b6e1565@0.92.0.js  
+Styles Link: https://tuix-webcomponents.s3.eu-central-1.amazonaws.com/build-b6e1565@0.92.0.css
 
 ### React
 
@@ -68,9 +68,6 @@ is enough. To start the request earlier, add the link to the document head:
 <link rel="stylesheet" href="https://hccdn.tuix.ch/rubik_d444e2375d.css" />
 ```
 
-There is no `loadFonts()` helper any more: injecting the stylesheet from
-JavaScript reflowed the page once the face arrived.
-
 ## Repository setup
 
 ```bash
@@ -97,7 +94,7 @@ npm run docs:build   # static export into docs/dist
 ```
 
 All three are `npm --prefix docs`, so the same commands run from inside `docs/`
-do the same thing — with one difference: `docs:install` is `npm ci`, a clean
+do the same thing, with one difference: `docs:install` is `npm ci`, a clean
 install of exactly what `docs/package-lock.json` pins. Adding or bumping a
 dependency therefore means an `npm install` inside `docs/`, to write the
 lockfile that `docs:install` then reproduces.
@@ -108,9 +105,9 @@ German. Pages are MDX files in `docs/content/docs/` (`*.mdx` English,
 `*.de.mdx` German), ordered by `meta.json` and `meta.de.json`.
 
 The site is public-facing: it shows and documents the components, and carries no
-contributor workflow. That lives here and in
-`docs/src/modules/docs/README.md`, which covers how the site is put together —
-content locations, the live previews, the framework selector and the locales.
+contributor workflow. That lives here and in `docs/src/modules/docs/README.md`,
+which covers how the site is put together: content locations, the live previews,
+the framework selector and the locales.
 
 ## Building the package
 
@@ -121,15 +118,15 @@ npm run build
 writes `package-build/`, and `npm run stage:package` copies that into `dist/`,
 which is what `npm publish` ships (`files: ["dist"]`):
 
-| Path                             | Entry point                                  |
-| -------------------------------- | -------------------------------------------- |
-| `dist/src/index.js` + `.d.ts`    | `tuix-webcomponents` — the custom elements   |
-| `dist/src/react/index.js`        | `tuix-webcomponents/react` — the wrappers    |
-| `dist/assets/tuix-styles.css`    | `tuix-webcomponents/dist/assets/tuix-styles.css` — the design tokens |
+| Path                          | Entry point                                                         |
+| ----------------------------- | ------------------------------------------------------------------- |
+| `dist/src/index.js` + `.d.ts` | `tuix-webcomponents`, the custom elements                           |
+| `dist/src/react/index.js`     | `tuix-webcomponents/react`, the wrappers                            |
+| `dist/assets/tuix-styles.css` | `tuix-webcomponents/dist/assets/tuix-styles.css`, the design tokens |
 
 The two steps are separate on purpose: `dist/` is also where the site is
-assembled, so the package build never writes it. Only the staging step does,
-and that runs in `bin/publish.sh` — i.e. in the publish job, after the site has
+assembled, so the package build never writes it. Only the staging step does, and
+that runs in `bin/publish.sh`, i.e. in the publish job, after the site has
 already been uploaded from its own job.
 
 The steps behind it: `cem analyze` refreshes `custom-elements.json`,
@@ -163,7 +160,7 @@ The branch decides the dist-tag, and the two paths differ:
 Both paths build the bundle as `build-<short hash>@<version>.{js,css}` and
 upload it, so every deployment is immutable. Only `latest` rewrites the
 `Webbundle Link:` and `Styles Link:` lines under [Usage](#usage) and commits
-them — which is why those two lines are the one place in the repository that
+them, which is why those two lines are the one place in the repository that
 tracks the current bundle. `docs/scripts/build-bundle-links.ts` reads them at
 docs build time rather than copying the URLs into a page, so the documentation
 cannot fall a release behind.
@@ -201,7 +198,7 @@ The site root is the documentation, and the Storybook sidebar brand links back
 to it. `scripts/build.sh` is what assembles both into `dist/` for CI.
 
 Two builds, two folders, so neither clears the other: the site into `dist/`
-(`scripts/build.sh` — Storybook under `dist/storybook`, the docs export at the
+(`scripts/build.sh`: Storybook under `dist/storybook`, the docs export at the
 root) and the npm package into `package-build/` (`npm run build`). `dist/` is
 reused for the package only by `npm run stage:package`, which `bin/publish.sh`
 runs in the publish job.