Komme i gang med Lily

Velg et rammeverk, klon monorepoet og åpne dets hodeløse bibliotek eller eksempelapp, og begynn å sette sammen dine egne sider. Foretrekker du en veiledet vei? Start med veiledningene.

Installer

Lily bor i ett Git-monorepo, med en katalog for hvert rammeverks hodeløse bibliotek, hjelperpakker og eksempelapp. Den raskeste måten å prøve det på er å klone monorepoet og åpne det hodeløse biblioteket for din stack:

git clone https://github.com/LilyDesignSystem/lily-design-system
cd lily-design-system/lily-design-system-react-headless
pnpm install

Det samme mønsteret fungerer for de andre rammeverkene:

  • @lilydesignsystem/html-headless — ingen installasjon nødvendig; kopier .html filene
  • @lilydesignsystem/svelte-headless — pnpm install
  • @lilydesignsystem/react-headless — pnpm install
  • @lilydesignsystem/vue-headless — pnpm install
  • @lilydesignsystem/angular-headless — pnpm install
  • @lilydesignsystem/nunjucks-headless — pnpm install
  • lily-design-system-blazor-headless — dotnet build

De hodeløse bibliotekene er utformet for å klones eller vendores — behandle kilden som sannhetskilden og kopier det du trenger. preferansehjelperne leveres i tillegg som installerbare pakker med bygge- og publiseringsløype (npm for JS-rammeverkene, NuGet for Blazor).

Bruk en hodeløs komponent

Hodeløse komponenter leverer semantisk HTML, ARIA og egenskaper — men ingen CSS. Her er en Button i hvert rammeverk:

HTML

<button class="button" type="button" aria-label="Save">
  Save
</button>

Svelte

<script>
  import Button from "lily-design-system-svelte-headless/components/Button/Button.svelte";
</script>

<Button onclick={save}>Save</Button>

React

import Button from "lily-design-system-react-headless/components/Button";

<Button onClick={save}>Save</Button>

Vue

<script setup>
  import Button from "lily-design-system-vue-headless/components/Button.vue";
</script>

<Button @click="save">Save</Button>

Angular

import { Button } from "@lilydesignsystem/angular-headless";

@Component({
  imports: [Button],
  template: `<lily-button (click)="save()">Save</lily-button>`,
})

Blazor

<Button OnClick="Save">Save</Button>

Nunjucks

{% from "components/button/macro.njk" import button %}

{{ button({ text: "Save", type: "button" }) }}

Bruk et stilet eksempel

Eksempelappene inkluderer CSS, ruter og fulle demosider. Den raskeste måten å eksperimentere på er å starte eksempelappen for SvelteKit, Next, Nuxt, Analog eller Eleventy og se demoen på /components.

git clone https://github.com/LilyDesignSystem/lily-design-system
cd lily-design-system/lily-design-system-svelte-sveltekit-examples
pnpm install
pnpm run dev

Åpne deretter http://localhost:5173 og bla gjennom /components.

Stiling og designtokener

Hver komponent gjengis med én kebab-case-klasse på rotelementet. For eksempel <Button> gjengir <button class="button">. Stil den som du vil:

.button {
  background: var(--my-primary);
  color: #fff;
  padding: 0.75rem 1.5rem;
  border-radius: 0.5rem;
}
.button:hover { background: var(--my-primary-hover); }

Lilys standard fargepalett (brukt i eksempelappene) er:

  • Primær: #2563eb
  • Fare: #dc2626
  • Advarsel: #f59e0b
  • Suksess: #16a34a
  • Sidebakgrunn: #f9fafb
  • Kortbakgrunn: #ffffff

Dette er forslag, ikke krav. Bytt dem ut med din egen merkevarepalett, så følger Lily gjerne med.

Ferdige temaer

Vil du ikke skrive CSS fra bunnen av? Lily leveres med 57 frittstående referansetemaer i katalogen themes/ . Hvert er ett stilark som retter seg mot Lilys klassekroker — lenk til det, så er du stilet:

<link rel="stylesheet" href="/assets/themes/united-kingdom-government-digital-service.css" />

Settet dekker:

  • Offentlig sektor — NHS England, NHS Scotland og NHS Wales (pasientrettede og utøverrettede varianter hver), GOV.UK GDS og U.S. Web Design System.
  • Leverandørinspirert — Adobe Spectrum, Mozilla Protocol.
  • Generelt formål — light, dark, nord, dracula, wireframe og tretti-noen til.

Temavelgere bruker :where(...), så din egen CSS vinner alltid på spesifisitet. Par dem med theme-picker -hjelperen nedenfor for bytte ved kjøretid, eller følg temaveiledning.

Preferansehjelpere

Hvert rammeverk har åtte små velgere, hver i sin egen lily-design-system-{framework}-{package} pakke (og en picker-bar som setter dem sammen). Hver er en hodeløs ikonknapp som åpner en popup — en listeboks, en liste med lenker, et søkeskjema eller (for date-time-picker) en datovelgerdialog — ikke en native <select>; er SSR-sikker; og leveres uten CSS:

  • theme-picker — laster temastilark ved kjøretid ved å bytte en administrert <link>, setter data-theme på dokumentet, og lagrer valgfritt i localStorage.
  • locale-picker — setter lang og dir (med automatisk RTL-gjenkjenning) slik at i18n-biblioteket ditt kan følge etter; den oversetter ikke selv.
  • text-size-picker — setter data-text-size på dokumentet; CSS-en din tilordner hver verdi til skriftstørrelse.
  • motion-picker — setter data-motion på dokumentet, med utgangspunkt i besøkerens innstilling for redusert bevegelse; CSS-en og skriptene dine bestemmer hva som undertrykkes.
  • search-picker — en ikonknapp som åpner et søkefelt; innsending navigerer til en søkeside. Eier en handling, ikke en preferanse.
  • link-picker — et hjem-ikon som åpner en meny med sidelenkene appen din definerer (Hjem, Om oss, Kontakt oss, Personvernerklæring, …). Eier en handling, ikke en preferanse.
  • share-picker — åpner det native delingsarket eller en forbruker-levert destinasjonsliste, pluss kopiering av URL. Eier en handling, ikke en preferanse: bruker ingenting, lagrer ingenting.
  • date-time-picker — et tekstfelt pluss en APG-datovelgerdialog for en dato, et tidspunkt eller begge deler. Eier en skjemaverdi, ikke en preferanse: ISO-strengen går tur-retur til <input type="date">.
git clone https://github.com/LilyDesignSystem/lily-design-system
cd lily-design-system/lily-design-system-svelte-theme-picker

Svelte-katalogen er den kanoniske referansen; React-, Vue-, Angular-, HTML-, Nunjucks-, Web Components- og Blazor-portene samsvarer med den kontrakt for kontrakt. Se hjelperveiledning.

Tilgjengelighet

Komponenter sikter mot WCAG 2.2 AAA. De følger disse mønstrene:

  • Semantiske HTML-elementer fremfor generiske <div>s.
  • <label for="id"> som knytter etiketter til inndatafelt.
  • aria-labelledby / aria-describedby for kryssreferanser.
  • aria-invalid + aria-errormessage for feiltilstander.
  • role="alert" og aria-live for dynamisk innhold.
  • aria-pressed, aria-expanded, aria-current for tilstand.
  • Roving tabindex for rutenett.

Fokusindikatorer leveres bevisst av forbrukeren — Lily maler aldri en standard fokusring som kolliderer med designet ditt. Eksempelappene holder en ren axe-core-baseline på tvers av rutene sine.

Internasjonalisering

Hver etikett, plassholder, feilmelding og knappetekst er en egenskap. Det finnes ingen hardkodede tekststrenger. Koble til oversettelsesrammeverket du foretrekker — Paraglide, i18next, vue-i18n, react-intl, .resx-filer, hva som helst.

For datoer, tall og valutaer tar komponentene imot forhåndsformaterte strenger: du formaterer med Intl.DateTimeFormat / Intl.NumberFormat / biblioteket du foretrekker og sender resultatet videre.

Hjelperen locale-picker signaliserer det valgte lokalet til i18n-biblioteket ditt ved å sette lang og dir på dokumentroten.

Testing

Hvert rammeverks delprosjekt leverer sine egne tester med sin idiomatiske stack:

  • HTML: WebDriverIO som kjører ekte nettlesere.
  • Svelte: Vitest + @testing-library/svelte.
  • React: Vitest + @testing-library/react.
  • Vue: Vitest + @testing-library/vue.
  • Angular: Vitest + TestBed (via Analog Vite-pluginen).
  • Nunjucks: Vitest med en gjengivelseshjelper.
  • Blazor: bUnit.

Tester bruker bare Vitests innebygde matchere — aldri jest-dom matchere. Dette holder testsuitene bærbare. Eksempelappene legger til Playwright ende-til-ende-suiter, axe-core-tilgjengelighetsbaselines og en responsiv visningsportsveip.

KI-agenter

Dette nettstedet publiserer llms.txt og llms.json i roten — et kuratert kart over de viktigste sidene, for ethvert verktøy som følger llms.txt-konvensjonen.

Det kanoniske monorepoet leverer i tillegg to Claude Skills: lily-design-system-skill, en generell ferdighet som dekker Lilys konsepter, terminologi og sammensetningsmønstre for alle som bygger med systemet, og lily-design-system-maintainer-skill, en teknisk ferdighet som dekker monorepoets obligatoriske filstruktur og verktøy for alle som jobber med det. Begge ligger i roten av det kanoniske monorepoet.

Feilsøking

En komponent gjengis, men ser ustilet ut

Det er hodeløs som fungerer som tiltenkt — ingen CSS følger med komponenten. Skriv enten CSS mot komponentens kebab-case-klasse (vist på hver katalogside) eller lenk til ett av de 57 ferdige temaene.

CSS-en min ser ikke ut til å gjelde over et tema

Den skal — temavelgere er pakket inn i :where(...), som har null spesifisitet. Hvis en regel likevel taper, sjekk at stilarket ditt lastes etter temaets <link> og at velgeren faktisk samsvarer med komponentens klassekrok.

pnpm install feiler med en peer- eller versjonsfeil

Bruk en nåværende pnpm (v10+) og Node 22+. Hvert delprosjekt fester rammeverksversjonene sine i sin egen package.json; hvis det globale verktøysettet ditt er eldre, pnpm env use --global lts er den raskeste løsningen.

Skjermleseren kunngjør feil navn på en kontroll

Sjekk komponentens påkrevde label -egenskap — komponenter uten synlig tekst krever en, og forbrukerlevert aria-label / aria-labelledby som sendes gjennom rest-props vinner bevisst over den innebygde koblingen. Hver katalogside dokumenterer komponentens ARIA-kontrakt.

theme-picker-hjelperen bytter ikke stilark

Bekreft at themesUrl peker til en katalog nettleseren kan hente (server themes/ -filene som statiske ressurser) og at temaslugene i themes -egenskapen samsvarer med filnavnene. Hjelperen bytter href til én administrert <link data-lily-theme-picker> — inspiser den i devtools for å se URL-en som forespørres.

Noe annet er ødelagt

Åpne en sak med en minimal reproduksjon på github.com/LilyDesignSystem/lily-design-system — eller se fellesskap og støtte.

Bidra

Lily er ung og ønsker samarbeid velkommen. De mest nyttige bidragene akkurat nå er:

  • Nye komponenter (spesielt mønstre fra etablerte designsystemer).
  • Nye temaer — hvert er ett frittstående stilark, en godt avgrenset første PR.
  • Bedre eksempelstiling — vis hva som er mulig.
  • Oversettelser av eksempelappenes tekststrenger.
  • Feilrapporter med minimal reproduksjon.
  • Tilgjengelighetsrevisjoner med skjermlesere og hjelpeteknologi.

Åpne saker og PR-er på github.com/LilyDesignSystem/lily-design-system.

Fellesskap og støtte

Vanlige spørsmål

Hvorfor hodeløs i stedet for stilet?

Ferdig stilede komponenter er praktiske — helt til de ikke passer merkevaren din. Hodeløse komponenter er litt mer jobb i starten, men gir deg full kontroll over det visuelle designet. Eksempelappene og de 57 temaene viser måter å style dem på; du kan ta dem eller bytte dem ut helt. Det lengre argumentet står på Hvorfor Lily.

Hvorfor så mange komponenter?

Lily vil dekke mønstrene de fleste apper trenger uten å tvinge deg til å bygge dem fra bunnen av — inkludert dypere ting som nasjonale identifikatorinndata og redaksjonell scrollytelling. Katalogen henter fra et dusin etablerte designsystemer pluss original innsats — se Om.

Kan jeg bruke Lily med Tailwind?

Ja. Hver komponent eksponerer én kebab-case-rotklasse pluss en forbrukerlevert className / class. Legg Tailwind-verktøyklasser på toppen som du vil.

Kan jeg bruke Lily med semantiske CSS-rammeverk som DaisyUI?

Ja. Kebab-case-klassenavnene på rotelementet fungerer som semantiske CSS-kroker. Par Lily med et semantisk rammeverk, så får du ferdig stilede komponenter som fortsatt respekterer ARIA og i18n.

Finnes det en npm-pakke?

Hjelperen preferansehjelperne leveres som pakker med en npm/NuGet-publiseringsløype. De hodeløse komponentbibliotekene er utformet for å klones eller vendores — kilden er leveransen, slik at du kan lese, trimme og eie akkurat det du leverer. Registerpublisering for de hodeløse bibliotekene står fortsatt på veikartet.

Hvorfor flere lisenser?

Ulike prosjekter har ulike lisensbehov. BSD og MIT er permissive, Apache-2.0 har en patentlisens, og GPL-alternativene støtter copyleft. Velg den som passer din situasjon.

Hvordan rapporterer jeg en feil eller ber om en funksjon?

Åpne en sak i GitHub-repoet, eller send e-post til joel@joelparkerhenderson.com.