DEV Community: Skovhugger Lund

Byg en gennemsigtig prisberegner med JavaScript

Skovhugger Lund — Fri, 13 Nov 2026 11:41:46 +0000

Prisen på en service virker ofte enkel, når man kun ser det endelige beløb.

Men hvad består prisen egentlig af?

Ved træfældning kan arbejdstid, udstyr, adgangsforhold og oprydning have betydning for den samlede udgift.

Det gør emnet interessant fra et webudviklingsperspektiv.

For hvordan bygger vi en lille prisberegner, der viser, hvordan forskellige beløb lægges sammen, uden at den giver brugeren en falsk forventning om en garanteret pris?

I denne tutorial bygger vi et enkelt værktøj med HTML og vanilla JavaScript.

Vi bruger ingen frameworks.

Vi fokuserer i stedet på tre ting:

Tydelige beregninger
Forståelig visning af moms
Ærlig kommunikation om usikkerhed

Vigtigt: Beregneren er et undervisningseksempel. Brugeren indtaster selv beløbene. Den indeholder ingen officielle timepriser fra en bestemt virksomhed, og resultatet er ikke et bindende tilbud på træfældning.

1. Hvorfor bygge en prisberegner?

Forestil dig, at en boligejer i Kolding undersøger, hvad det koster at få fjernet et træ.

Vedkommende har måske fået oplyst et forventet tidsforbrug og vil gerne forstå, hvordan en pris kan opdeles.

En beregner kan gøre regnestykket mere overskueligt.

Men den skal ikke forsøge at træffe en faglig beslutning om træet.

Det er vigtigt at skelne mellem to forskellige opgaver.

Den ene er at beregne et beløb ud fra givne tal.

Den anden er at vurdere, hvor lang tid det faktisk tager at fælde et træ, og hvilke sikkerhedsforanstaltninger opgaven kræver.

JavaScript er velegnet til det første.

Det andet kræver en konkret faglig vurdering.

Derfor bygger vi ikke en automatisk prisvurdering baseret på træhøjde eller billeder.

Vi bygger et værktøj, der viser matematikken bag et eksempel.

2. Vores beregningsmodel

Vi bruger tre oplysninger:

Et forventet antal arbejdstimer
En indtastet timepris
Et valgfrit beløb for ekstra ydelser

Beregningen bliver:

Arbejdsbeløb = timer × timepris

Beløb eksklusive moms = arbejdsbeløb + ekstra ydelser

Moms = beløb eksklusive moms × 0,25

Beløb inklusive moms = beløb eksklusive moms + moms

Vi bruger den almindelige danske momssats på 25 procent i eksemplet.

Det er en forenklet model.

En virkelig pris kan også afhænge af maskiner, transport, bemanding og andre forhold, som ikke er med i dette regnestykke.

3. HTML: Lad brugeren indtaste oplysningerne

Vi begynder med en enkelt formular.

Opret filen index.html.

<!doctype html>
<html lang="da">
<head>
  <meta charset="utf-8">

  <meta name="viewport"
        content="width=device-width, initial-scale=1">

  <title>Eksempel på prisberegner</title>

  <style>
    body {
      font-family: system-ui, sans-serif;
      max-width: 680px;
      margin: 40px auto;
      padding: 0 20px;
      line-height: 1.6;
      color: #26352c;
    }

    form {
      display: grid;
      gap: 16px;
      margin: 25px 0;
    }

    label {
      display: grid;
      gap: 6px;
      font-weight: 600;
    }

    input {
      padding: 11px;
      font: inherit;
      border: 1px solid #a3b2a7;
      border-radius: 6px;
    }

    button {
      padding: 12px;
      font: inherit;
      font-weight: 700;
      background: #24583b;
      color: #fff;
      border: 0;
      border-radius: 6px;
      cursor: pointer;
    }

    button:focus-visible,
    input:focus-visible {
      outline: 3px solid #608b70;
      outline-offset: 3px;
    }

    #resultat {
      padding: 20px;
      background: #edf4ee;
      border-radius: 10px;
    }

    .total {
      font-size: 1.25rem;
      font-weight: 700;
    }

    .note {
      color: #4e6455;
      font-size: 0.95rem;
    }

    [hidden] {
      display: none !important;
    }
  </style>
</head>

<body>
  <main>
    <h1>Prisberegner</h1>

    <p>
      Indtast dine egne tal for at se
      et eksempel på en samlet pris.
    </p>

    <form id="prisForm">
      <label for="timer">
        Forventede arbejdstimer
        <input
          id="timer"
          name="timer"
          type="number"
          min="0"
          max="10000"
          step="0.5"
          required
        >
      </label>

      <label for="timepris">
        Timepris ekskl. moms (kr.)
        <input
          id="timepris"
          name="timepris"
          type="number"
          min="0"
          max="10000000"
          step="0.01"
          required
        >
      </label>

      <label for="ekstra">
        Ekstra ydelser ekskl. moms (kr.)
        <input
          id="ekstra"
          name="ekstra"
          type="number"
          min="0"
          max="100000000"
          step="0.01"
          value="0"
          required
        >
      </label>

      <button type="submit">
        Beregn eksempel
      </button>
    </form>

    <p id="fejl" role="alert" hidden></p>

    <section
      id="resultat"
      aria-labelledby="resultatTitel"
      hidden
    >
      <h2 id="resultatTitel">Beregning</h2>

      <p id="arbejde"></p>
      <p id="ekstraVisning"></p>
      <p id="subtotal"></p>
      <p id="moms"></p>
      <p id="total" class="total"></p>
    </section>

    <p class="note">
      Kun et regneeksempel.
      Resultatet er ikke et pristilbud.
      Det tager ikke højde for alle
      forhold ved en virkelig opgave.
    </p>
  </main>

  <script src="app.js"></script>
</body>
</html>

Vi har nu en formular med tre felter.

Alle felter har tilhørende labels.

Vi bruger også type="number" og begrænser input til ikke-negative værdier.

Det giver brugeren en mere tydelig indtastningsoplevelse.

Men HTML-validering er ikke nok i sig selv.

Vi kontrollerer også tallene i JavaScript.

4. Beregn prisen med en ren funktion

Nu opretter vi filen app.js.

Vi starter med selve beregningen.

const MOMSSATS = 0.25;

function beregnPris(timer, timepris, ekstra) {
  const tal = [timer, timepris, ekstra];

  if (
    tal.some(
      (tal) =>
        !Number.isFinite(tal) || tal < 0
    )
  ) {
    throw new Error(
      "Alle beløb skal være gyldige, " +
      "ikke-negative tal."
    );
  }

  const arbejdsbeloeb = timer * timepris;
  const subtotal = arbejdsbeloeb + ekstra;
  const moms = subtotal * MOMSSATS;
  const total = subtotal + moms;

  if (
    !Number.isFinite(arbejdsbeloeb) ||
    !Number.isFinite(subtotal) ||
    !Number.isFinite(moms) ||
    !Number.isFinite(total)
  ) {
    throw new Error(
      "Beløbet er for stort til beregning."
    );
  }

  return {
    arbejdsbeloeb,
    ekstra,
    subtotal,
    moms,
    total
  };
}

Funktionen modtager tre tal og returnerer et objekt.

Den arbejder ikke direkte med HTML-elementerne.

Det gør den lettere at teste.

Det er også en nyttig adskillelse mellem beregning og præsentation.

Hvis vi senere ændrer designet, behøver vi ikke ændre regnemetoden.

5. Vis danske beløb korrekt

Danske priser vises normalt med komma som decimaltegn og punktum som tusindtalsseparator.

I stedet for selv at sætte tegnene ind bruger vi browserens indbyggede internationaliseringsfunktion.

const formatter = new Intl.NumberFormat(
  "da-DK",
  {
    style: "currency",
    currency: "DKK",
    minimumFractionDigits: 2,
    maximumFractionDigits: 2
  }
);

function formatPris(beloeb) {
  return formatter.format(beloeb);
}

Her bruger vi Intl.NumberFormat.

Den tager hensyn til sproglige konventioner.

Det er bedre end at skrive vores egen løsning, der manuelt forsøger at placere kommaer og punktummer.

Det betyder også, at samme princip kan bruges til andre valutaer og sprog.

Bemærk, at JavaScripts almindelige decimaltal ikke er ideelle til alle former for finansielle beregninger.

Til produktionsbrug med bogføring og betaling bør beløb normalt håndteres med en kontrolleret decimalmodel eller heltal i mindste valutaenhed og med tydelige afrundingsregler.

Vores løsning er et simpelt overslag.

6. Forbind formularen til beregningen

Nu skal vi hente brugerens tal og vise resultatet.

Tilføj følgende kode nederst i app.js.

const form = document.querySelector("#prisForm");
const resultat = document.querySelector("#resultat");
const fejl = document.querySelector("#fejl");

form.addEventListener("submit", (event) => {
  event.preventDefault();

  fejl.hidden = true;
  resultat.hidden = true;

  const timer = Number(form.elements.timer.value);
  const timepris = Number(
    form.elements.timepris.value
  );
  const ekstra = Number(form.elements.ekstra.value);

  try {
    const pris = beregnPris(
      timer,
      timepris,
      ekstra
    );

    document.querySelector("#arbejde").textContent =
      "Arbejde: " +
      formatPris(pris.arbejdsbeloeb);

    document.querySelector(
      "#ekstraVisning"
    ).textContent =
      "Ekstra ydelser: " +
      formatPris(pris.ekstra);

    document.querySelector("#subtotal").textContent =
      "Pris ekskl. moms: " +
      formatPris(pris.subtotal);

    document.querySelector("#moms").textContent =
      "Moms (25 %): " +
      formatPris(pris.moms);

    document.querySelector("#total").textContent =
      "Pris inkl. moms: " +
      formatPris(pris.total);

    resultat.hidden = false;
  } catch (error) {
    fejl.textContent = error.message;
    fejl.hidden = false;
  }
});

Når formularen bliver sendt, stopper vi browserens normale genindlæsning.

Derefter læser vi felterne.

Tallene bliver sendt videre til vores beregningsfunktion.

Til sidst viser vi resultatet i separate linjer.

Hvis input er ugyldigt, får brugeren en fejlbesked.

På den måde bliver regnestykket lettere at forstå end ved blot at vise et enkelt stort beløb.

7. Test med illustrative tal

Vi kan nu prøve et simpelt eksempel.

Forestil dig, at brugeren indtaster:

Arbejdstimer: 4
Timepris: 600 kr.
Ekstra ydelser: 800 kr.

Disse tal er udelukkende undervisningsdata.

De er ikke en virksomheds offentlige timepriser.

Beregningen giver:

Post	Beløb
Arbejde	2.400 kr.
Ekstra ydelser	800 kr.
Pris ekskl. moms	3.200 kr.
Moms 25 %	800 kr.
Pris inkl. moms	4.000 kr.

Det er et meget enkelt regnestykke.

Men netop derfor er det nyttigt.

Vi kan se, hvor hvert beløb kommer fra.

Og vi kan kontrollere, om beregningen virker som forventet.

8. Skriv nogle enkle tests

En prisberegner bør ikke kun se korrekt ud.

Den skal også regne korrekt.

Vi kan teste vores funktion direkte i browserens udviklerværktøjer.

console.assert(
  beregnPris(4, 600, 800).total === 4000,
  "Den samlede pris skal være 4000 kr."
);

console.assert(
  beregnPris(2, 500, 0).moms === 250,
  "Momsen skal være 250 kr."
);

console.assert(
  beregnPris(0, 0, 0).total === 0,
  "Nul skal give nul."
);

let fejlBlevFanget = false;

try {
  beregnPris(-1, 500, 0);
} catch {
  fejlBlevFanget = true;
}

console.assert(
  fejlBlevFanget,
  "Negative værdier skal afvises."
);

Testene er små, men de kontrollerer nogle vigtige regler.

Den samlede pris skal være korrekt.

Momsen skal være korrekt.

Og negative tal må ikke accepteres.

Hvis systemet skulle udvikles videre til egentlig fakturering, ville vi have brug for mere omfattende tests og håndtering af afrunding.

9. Hvad mangler vores beregner?

Der mangler en hel del.

Det er faktisk en vigtig del af denne tutorial.

Værktøjet kan lægge tal sammen.

Men det kan ikke selv afgøre:

Hvor mange medarbejdere opgaven kræver
Om et træ skal fjernes i sektioner
Om en lift er nødvendig
Hvor vanskelige adgangsforholdene er
Om træets tilstand kræver særlige forholdsregler
Hvordan oprydning og transport skal planlægges

Disse forhold kræver faglig vurdering.

Hvis vi forsøgte at gætte dem ud fra træhøjde alene, kunne beregneren skabe en falsk følelse af præcision.

Det ville ikke gøre værktøjet mere hjælpsomt.

Tværtimod kunne brugeren få et misvisende billede af den faktiske udgift.

Derfor er det bedre at vise en tydelig begrænsning end at lade et tal se mere sikkert ud, end det er.

10. Hvorfor er gennemsigtighed vigtig?

Når en bruger indtaster tal i en beregner, bør det være tydeligt, hvad resultatet betyder.

Hvis resultatet kun er et eksempel, skal det stå klart.

Hvis ekstra ydelser ikke er med, skal det også være tydeligt.

Det samme gælder moms.

En beregner, der viser en pris uden at forklare, om moms er inkluderet, kan skabe unødvendig forvirring.

Derfor er vores resultat opdelt i flere linjer.

Brugeren kan se arbejdsbeløbet, ekstra ydelser, moms og den samlede pris.

Vi har samtidig skrevet, at resultatet ikke er et bindende tilbud.

Det er ikke bare en juridisk detalje.

Det er en del af god brugeroplevelse.

11. Et virkeligt eksempel: Træfældning pris i Kolding

Skovhugger Lund har base i Kolding og udfører træfældning, beskæring og træpleje i Syddanmark.

På virksomhedens prisside forklares det, at prisen på træfældning beregnes ud fra et forventet tidsforbrug.

Træets størrelse, placering, tilstand og opgavens sværhedsgrad indgår i vurderingen.

Virksomheden offentliggør også vejledende priser for forskellige typer træarbejde.

Men en konkret opgave kræver stadig en vurdering af forholdene.

På siden om træfældning pris i Kolding beskriver Skovhugger Lund, hvorfor en simpel standardpris ikke passer til alle træer.

Det er en god illustration af forskellen mellem en teknisk beregning og en faglig prisvurdering.

Vores JavaScript-beregner er et selvstændigt undervisningseksempel.

Den er ikke udviklet af Skovhugger Lund, indeholder ikke virksomhedens faktiske timepriser og kan ikke bruges til at bestille eller prissætte dens ydelser.

12. Hvordan kunne vi forbedre projektet?

Hvis vi ville gøre værktøjet mere anvendeligt, kunne vi begynde med bedre input.

Eksempelvis kunne vi tilføje en valgfri beskrivelse af opgaven.

Men vi bør ikke lade den frie tekst bestemme en automatisk pris.

I stedet kunne den bruges til at dokumentere brugerens forudsætninger.

Vi kunne også tilføje en knap, der eksporterer selve regnestykket som tekst.

Det ville gøre det lettere at gennemgå de indtastede beløb.

En anden forbedring kunne være at gemme beregningens antagelser sammen med resultatet.

Så ville brugeren tydeligt kunne se, hvilke tal der blev brugt.

Men enhver udvidelse bør stadig bevare den vigtigste regel:

Et beregnet eksempel skal ikke præsenteres som et fagligt godkendt tilbud.

13. En nyttig regel for udviklere

Det er fristende at bygge en beregner, som altid giver brugeren et svar.

Men ikke alle spørgsmål kan besvares præcist med en formel.

Nogle kræver observationer, erfaring og vurdering af konkrete forhold.

Det gælder mange servicefag.

En prisberegner kan gøre matematikken tydelig.

Den kan hjælpe brugeren med at forstå moms og omkostninger.

Og den kan vise, hvordan forskellige beløb påvirker en samlet sum.

Men den bør ikke foregive at vide mere, end den faktisk gør.

God software viser ikke kun et resultat. Den viser også, hvor resultatet kommer fra, og hvad det ikke kan fortælle os.

Opsummering

I denne tutorial har vi bygget en enkel prisberegner med HTML og vanilla JavaScript.

Vi har arbejdet med:

Formularer og validering
Rene beregningsfunktioner
Intl.NumberFormat
Dansk momsberegning
Dynamisk resultatvisning
Simple browser-tests
Tydelig kommunikation af begrænsninger

Vi har også set, hvorfor et teknisk regnestykke ikke kan erstatte en faglig vurdering.

Det er måske den vigtigste pointe.

For en gennemsigtig beregner er ikke nødvendigvis den, der giver flest tal.

Det er den, der hjælper brugeren med at forstå, hvad tallene betyder.

Byg en tilgængelig informationsside med HTML og CSS

Skovhugger Lund — Fri, 13 Nov 2026 11:09:48 +0000

Forestil dig, at en boligforening skal have fjernet et stort træ fra et fællesareal.

Beboerne skal vide, hvornår arbejdet finder sted, hvilke områder der bliver berørt, og hvem de kan kontakte.

Det er en lille kommunikationsopgave, men den er oplagt til at lære noget om moderne HTML.

For hvordan bygger man en informationsside, som er nem at læse på mobil, fungerer med tastatur og giver mening for en skærmlæser?

I denne tutorial bygger vi en enkel side med semantisk HTML og almindelig CSS.

Ingen JavaScript-frameworks. Ingen eksterne komponentbiblioteker.

Og faktisk behøver vi slet ikke JavaScript.

Eksemplet handler om formidling af planlagt arbejde. Det er ikke et system til at vurdere træers stabilitet, godkende afspærringer eller planlægge sikkerheden ved træfældning.

1. Hvad skal siden kunne?

Vi tager udgangspunkt i et tænkt eksempel.

En boligforening i Kolding har planlagt professionel træfældning af et træ på et fællesareal.

Beboerne skal kunne finde fire oplysninger:

Hvad arbejdet handler om
Hvornår det forventes at foregå
Hvilke praktiske ændringer der er planlagt
Hvem de kan kontakte ved spørgsmål

Derudover ønsker vi, at siden fungerer godt på små skærme.

Indholdet skal være let at læse, og besøgende skal kunne åbne supplerende information med tastaturet.

Vi bygger det hele i én HTML-fil, så eksemplet er let at teste.

2. Start med semantisk HTML

En webside kan bygges med mange div-elementer.

Men HTML har allerede elementer, der beskriver indholdets funktion.

Vi bruger blandt andet:

header til sidens introduktion
main til hovedindholdet
section til selvstændige afsnit
time til tidsoplysninger
details og summary til supplerende information
footer til afsluttende oplysninger

Det gør dokumentet mere forståeligt for både udviklere og hjælpemidler.

Opret en fil med navnet index.html.

<!doctype html>
<html lang="da">
<head>
  <meta charset="utf-8">
  <meta name="viewport"
        content="width=device-width, initial-scale=1">

  <title>Information om planlagt træarbejde</title>
  <meta name="description"
        content="Praktisk information om planlagt træarbejde på et fællesareal.">

  <link rel="stylesheet" href="style.css">
</head>

<body>
  <header class="site-header">
    <div class="container">
      <p class="eyebrow">Beboerinformation</p>
      <h1>Planlagt træarbejde på fællesarealet</h1>
      <p>
        Her finder du den praktiske information
        om det kommende arbejde.
      </p>
    </div>
  </header>

  <main id="main-content" class="container">
    <section aria-labelledby="overview-title">
      <h2 id="overview-title">Overblik</h2>
      <p>
        Der er planlagt arbejde med et træ
        på ejendommens fællesareal.
      </p>
    </section>
  </main>

  <footer class="site-footer">
    <div class="container">
      <p>Eksempel på en informationsside.</p>
    </div>
  </footer>
</body>
</html>

Bemærk, at lang="da" står på html-elementet.

Det fortæller browseren og relevante hjælpemidler, at sidens primære sprog er dansk.

Vi bruger også kun ét h1-element og en naturlig rækkefølge af overskrifter.

Det er et godt udgangspunkt for en tydelig dokumentstruktur.

3. Vis tidspunktet med det rigtige HTML-element

En dato kan selvfølgelig skrives som almindelig tekst.

Men HTML har også elementet time.

Det gør det muligt at angive datoen i et maskinlæsbart format.

Tilføj denne sektion inde i main:

<section class="notice" aria-labelledby="when-title">
  <h2 id="when-title">Hvornår foregår arbejdet?</h2>

  <p>
    Forventet arbejdsdag:
    <time datetime="2027-04-15">
      15. april 2027
    </time>
  </p>

  <p>
    Forventet tidsrum:
    <time datetime="09:00">09.00</time>
    til
    <time datetime="14:00">14.00</time>
  </p>

  <p class="notice-note">
    Tidspunktet er foreløbigt og skal bekræftes
    af den ansvarlige for ejendommen.
  </p>
</section>

Datoen er kun eksempeldata, ikke en virkelig aftale.

I et rigtigt projekt skal den ansvarlige person bekræfte både dato og tidspunkt, før siden bliver offentliggjort.

En vigtig detalje er, at maskinlæsbar HTML ikke gør oplysningerne korrekte.

datetime beskriver datoens format.

Det kontrollerer ikke, om arbejdet faktisk er planlagt.

4. Beskriv praktiske ændringer tydeligt

En informationsside bør ikke gøre det svært for læseren at finde det vigtigste.

Forestil dig, at en parkeringsplads eller en sti bliver påvirket af arbejdet.

Så skal oplysningerne stå tydeligt.

Vi kan bruge en almindelig liste.

<section aria-labelledby="access-title">
  <h2 id="access-title">Praktiske forhold</h2>

  <p>
    Følgende forhold forventes at gælde,
    hvis arbejdsplanen godkendes:
  </p>

  <ul class="info-list">
    <li>
      En del af fællesarealet kan være afspærret.
    </li>
    <li>
      Enkelte adgangsveje kan blive påvirket.
    </li>
    <li>
      Beboerne får besked om eventuelle
      ændringer i parkeringen.
    </li>
    <li>
      Afspærringer skal respekteres.
    </li>
  </ul>

  <p>
    Den endelige afspærring og adgangsløsning
    fastlægges af de ansvarlige fagfolk
    og relevante parter.
  </p>
</section>

Det er vigtigt ikke at lade denne type eksempeltekst fremstå som en godkendt sikkerhedsplan.

En hjemmeside kan informere om en plan.

Den kan ikke erstatte den konkrete vurdering af arbejdsområdet.

Hvis en adgangsvej bliver ændret, skal informationen stemme med den faktiske, godkendte løsning.

5. Brug details og summary uden JavaScript

Nogle oplysninger behøver ikke være synlige hele tiden.

Det kan eksempelvis være en forklaring af, hvad beboerne skal gøre, hvis arbejdsdatoen ændrer sig.

Her er details og summary nyttige.

<section aria-labelledby="faq-title">
  <h2 id="faq-title">Ofte stillede spørgsmål</h2>

  <details>
    <summary>Kan tidspunktet blive ændret?</summary>
    <p>
      Ja. Hvis planen ændres, skal informationen
      på siden opdateres.
    </p>
  </details>

  <details>
    <summary>Må beboerne bruge fællesarealet?</summary>
    <p>
      Følg de konkrete oplysninger fra
      ejendommens ansvarlige og respekter
      eventuelle afspærringer.
    </p>
  </details>

  <details>
    <summary>Hvem kan svare på spørgsmål?</summary>
    <p>
      Kontakt ejendommens administrator
      via de officielle kontaktoplysninger.
    </p>
  </details>
</section>

Browseren håndterer selv åbning og lukning.

Det betyder, at vi ikke behøver skrive JavaScript til en almindelig informationsboks.

De indbyggede elementer giver også en tastaturbetjent kontrol.

Det er ofte bedre end at opfinde en klikbar div og derefter forsøge at tilføje alle de manglende funktioner.

6. Tilføj et synligt kontaktområde

Når noget ændrer sig på en ejendom, kan beboerne have spørgsmål.

Derfor bør kontaktoplysninger være lette at finde.

Vi laver en enkel kontaktsektion.

<section class="contact-box"
         aria-labelledby="contact-title">

  <h2 id="contact-title">Spørgsmål om arbejdet?</h2>

  <p>
    Kontakt ejendommens administrator
    for oplysninger om den planlagte opgave.
  </p>

  <p>
    <strong>Kontakt:</strong>
    Ejendommens administration
  </p>

  <p>
    De officielle kontaktoplysninger
    indsættes, når de er bekræftet.
  </p>
</section>

I dette eksempel indsætter vi ikke et opdigtet telefonnummer eller en e-mailadresse.

Det er bedre at vise tydeligt, at oplysningerne mangler, end at opfinde en kontaktperson.

I et rigtigt system bør siden ikke publiceres som færdig beboerinformation, før de nødvendige kontaktoplysninger er bekræftet.

7. Gør designet responsivt med CSS

Nu har vi en grundlæggende HTML-struktur.

Næste skridt er at gøre siden behagelig at læse på både mobil og computer.

Opret filen style.css.

:root {
  color-scheme: light;

  --page: #f6f8f5;
  --surface: #ffffff;
  --text: #223228;
  --muted: #526658;
  --accent: #235d40;
  --border: #d6e2d8;
  --notice: #edf5ee;
}

* {
  box-sizing: border-box;
}

body {
  margin: 0;
  background: var(--page);
  color: var(--text);
  font-family: system-ui, sans-serif;
  font-size: 1rem;
  line-height: 1.7;
}

.container {
  width: min(100% - 2rem, 780px);
  margin-inline: auto;
}

.site-header {
  padding: 3.5rem 0;
  background: var(--accent);
  color: white;
}

.eyebrow {
  font-size: 0.85rem;
  font-weight: 700;
  letter-spacing: 0.08em;
  text-transform: uppercase;
}

h1 {
  font-size: clamp(2rem, 5vw, 3rem);
  line-height: 1.2;
}

h2 {
  font-size: 1.5rem;
  line-height: 1.3;
}

main {
  padding-block: 2rem 4rem;
}

section {
  margin-block: 1.5rem;
  padding: 1.5rem;
  background: var(--surface);
  border: 1px solid var(--border);
  border-radius: 1rem;
}

.notice {
  background: var(--notice);
}

.notice-note {
  color: var(--muted);
}

.info-list {
  padding-left: 1.5rem;
}

.info-list li + li {
  margin-top: 0.75rem;
}

details {
  border-bottom: 1px solid var(--border);
  padding: 0.9rem 0;
}

summary {
  cursor: pointer;
  font-weight: 700;
}

summary:focus-visible {
  outline: 3px solid var(--accent);
  outline-offset: 4px;
  border-radius: 3px;
}

.contact-box {
  border-left: 5px solid var(--accent);
}

.site-footer {
  padding: 1.5rem 0;
  color: var(--muted);
  border-top: 1px solid var(--border);
}

@media (max-width: 600px) {
  .site-header {
    padding: 2rem 0;
  }

  section {
    padding: 1.1rem;
  }
}

CSS'en bruger relative størrelser og en fleksibel container.

Derfor kan siden tilpasse sig forskellige skærmbredder uden vandret scrolling fra selve layoutet.

Vi bruger clamp() til overskriften, så den bliver større på brede skærme og mindre på mobil.

Derudover har vi en tydelig fokusmarkering på summary.

Det hjælper brugere, som navigerer med tastaturet.

8. Test siden uden mus

En hurtig tilgængelighedstest kræver ikke et avanceret værktøj.

Åbn siden i browseren, og prøv at bruge den uden mus.

Tryk på Tab.

Når fokus når til en af vores summary-overskrifter, bør den kunne aktiveres med tastaturet.

Kontrollér også, at fokusmarkeringen er synlig.

Læs siden i en smal mobilvisning.

Er teksten stadig let at læse?

Bliver noget vigtigt skjult?

Er overskrifterne logisk organiseret?

Det er en god start.

Men en fuld tilgængelighedsvurdering kræver mere end en kort tastaturtest. Skærmlæsertest, zoom, kontrast og andre forhold bør også kontrolleres i et rigtigt projekt.

9. Hvorfor bør vi undgå farver som eneste signal?

Forestil dig, at vi viser en grøn boks for almindelig information og en rød boks for ændringer.

Hvis farven er det eneste, der forklarer betydningen, kan nogle brugere have svært ved at forstå informationen.

Derfor bør vigtige meddelelser også have tydelig tekst.

For eksempel:

<p class="notice-note">
  <strong>Ændret tidspunkt:</strong>
  Den tidligere planlagte dato gælder ikke længere.
  Et nyt tidspunkt bliver oplyst senere.
</p>

Her behøver læseren ikke kunne se en bestemt farve for at forstå beskeden.

Den samme tilgang kan bruges til fejl, advarsler og statusoplysninger.

10. Kan siden opdatere sig selv?

Ikke med den løsning, vi har bygget her.

Siden er statisk.

Hvis datoen ændrer sig, skal den ansvarlige opdatere HTML-indholdet og offentliggøre den nye version.

Det er ikke nødvendigvis en ulempe.

For en lille boligforening med få planlagte opgaver kan en simpel statisk side være lettere at vedligeholde end et stort system.

Hvis man senere ønsker et administrationspanel eller automatisk opdatering, kan projektet udvides.

Men først skal det være klart, hvem der må ændre oplysningerne, og hvordan ændringer bliver godkendt.

Automatisering er ikke en fordel, hvis den gør det lettere at offentliggøre forkerte oplysninger.

11. Hvorfor passer eksemplet til træfældning?

Når træer skal fjernes tæt på boliger, er det vigtigt, at arbejdet planlægges efter de konkrete forhold.

Skovhugger Lund er en træservicevirksomhed med base i Kolding.

Virksomheden arbejder med træfældning, beskæring og træpleje for private kunder, virksomheder samt grundejer- og boligforeninger.

På siden om professionel træfældning i Kolding beskriver virksomheden forskellige arbejdsmetoder, herunder retningsbestemt fældning, klatring og brug af lift.

Det viser, hvorfor en beboerinformation ikke bør fastlåse oplysninger om maskiner, adgang eller arbejdstid, før de konkrete forhold er vurderet.

En informationsside kan gøre det nemmere at formidle beslutningerne.

Men den skal bygge på bekræftede oplysninger.

Vores kode er et selvstændigt undervisningseksempel. Den beskriver ikke en eksisterende digital løsning hos Skovhugger Lund.

12. Hvad ville jeg forbedre i en rigtig løsning?

Hvis informationssiden skulle bruges i praksis, ville jeg begynde med indholdet.

Hvem godkender datoen?

Hvem skal informeres, hvis den ændrer sig?

Og hvem sikrer, at siden ikke indeholder forældede oplysninger?

Jeg ville også teste siden med forskellige skærmlæsere og kontrollere farvekontrast, tekstforstørrelse og tastaturnavigation.

Hvis siden blev udvidet til flere ejendomme, kunne man overveje en fælles indholdsmodel, så hver meddelelse har samme struktur.

Men det er vigtigt ikke at gøre løsningen mere kompleks end nødvendigt.

En lille, gennemarbejdet informationsside kan være mere nyttig end et stort system med mange funktioner, som ingen vedligeholder.

Afslutning

Vi har nu bygget en enkel informationsside med:

Semantisk HTML
Maskinlæsbare tidsoplysninger
En responsiv CSS-struktur
Tastaturbetjente informationsbokse
Tydelig tekst til praktiske meddelelser

Og vi gjorde det uden JavaScript.

Det er en nyttig påmindelse om, at moderne webudvikling ikke altid behøver begynde med et framework.

Nogle gange er den bedste løsning almindelig HTML, gennemtænkt CSS og indhold, som mennesker faktisk kan bruge.

God webudvikling handler ikke kun om, at en side ser flot ud. Den handler om, at informationen er tydelig, tilgængelig og til at stole på.

TypeScript i praksis: Datamodeller til stubfræsning

Skovhugger Lund — Fri, 13 Nov 2026 10:28:36 +0000

Forestil dig en virksomhed, som modtager forespørgsler om fjernelse af træstubbe.

Én kunde har en enkelt stub midt i græsplænen. En anden har fem stubbe langs en gammel hæk. En tredje ønsker også at få undersøgt rødder, der ligger i vejen for en ny sti.

Hvordan kan vi beskrive disse opgaver i et program uden at miste vigtige oplysninger?

Vi kan begynde med TypeScript.

I denne tutorial bygger vi en lille datamodel, validerer indholdet og skriver automatiske tests.

Vi beregner ikke priser og afgør ikke, om maskinarbejde kan udføres sikkert. De beslutninger kræver faglige oplysninger, som vores eksempel ikke har.

Målet er blot at skabe pålidelige administrative data.

1. Hvorfor bruge TypeScript?

JavaScript er fleksibelt.

Det kan være en fordel, men også en udfordring, hvis mange oplysninger skal registreres på samme måde.

Forestil dig, at et program modtager følgende objekt:

```javascript id="st01"
const job = {
area: "Kolding",
stumpCount: "three",
access: "unknown"
};




Her er `stumpCount` en tekst, selv om vi forventer et tal.

Det kan skabe problemer senere.

TypeScript kan hjælpe os med at beskrive den forventede struktur og opdage mange fejl under udviklingen.

Men der er en vigtig begrænsning:

**TypeScript-typer kontrollerer ikke automatisk data, der kommer udefra, mens programmet kører.**

Derfor skal vi både bruge typer og almindelig validering.

## 2. Definér opgavens oplysninger

Vi starter med en model til registrering af træstubbe.

Opret en fil med navnet `stump-jobs.ts`.



```typescript id="st02"
type AccessType =
  | "open"
  | "limited"
  | "unknown";

type GroundUse =
  | "lawn"
  | "planting"
  | "paving"
  | "undecided";

type StumpJob = {
  id: string;
  area: string;
  stumpCount: number;
  access: AccessType;
  futureUse: GroundUse;
  undergroundServicesChecked: boolean;
};

Modellen indeholder seks felter.

id identificerer registreringen.

area beskriver det overordnede geografiske område.

stumpCount fortæller, hvor mange stubbe der er registreret.

access beskriver de foreløbige adgangsforhold.

futureUse viser, hvad kunden ønsker at bruge området til bagefter.

undergroundServicesChecked angiver, om oplysninger om nedgravede installationer er blevet gennemgået administrativt.

Det sidste felt er vigtigt at forstå korrekt.

En værdi på true betyder ikke, at stedet er sikkert at fræse. Det betyder kun, at den definerede kontrol er registreret som gennemført.

Den faktiske vurdering kræver en separat arbejdsproces.

3. Opret et eksempel på en opgave

Nu kan vi oprette en registrering med den nye type.

```typescript id="st03"
const exampleJob: StumpJob = {
id: "JOB-001",
area: "Kolding",
stumpCount: 3,
access: "limited",
futureUse: "lawn",
undergroundServicesChecked: false
};




Denne opgave indeholder tre stubbe.

Adgangsforholdene er foreløbigt beskrevet som begrænsede.

Kunden ønsker at bruge området til græsplæne.

Og oplysninger om nedgravede installationer er endnu ikke markeret som gennemgået.

Det er fiktive data, som kun bruges i tutorialen.

## 4. Hvorfor skal vi validere data igen?

Forestil dig, at en anden del af programmet sender dette:



```typescript id="st04"
const incomingData: unknown = {
  id: "JOB-002",
  area: "Kolding",
  stumpCount: -4,
  access: "very easy",
  futureUse: "lawn",
  undergroundServicesChecked: "yes"
};

Objektet indeholder flere problemer.

Antallet af stubbe er negativt.

Adgangstypen findes ikke på vores liste.

Og den sidste værdi er en tekst i stedet for en boolean.

Når data kommer fra en formular, en fil eller en API, bør vi behandle dem som unknown, indtil de er kontrolleret.

Det er netop det, vi skal gøre nu.

5. Byg en valideringsfunktion

Først opretter vi en type til resultatet.

```typescript id="st05"
type ValidationResult =
| {
valid: true;
data: StumpJob;
}
| {
valid: false;
errors: string[];
};




Dette er en *discriminated union*.

Når `valid` er `true`, ved TypeScript, at resultatet indeholder `data`.

Når `valid` er `false`, indeholder det en liste over fejl.

Nu skriver vi selve funktionen:



```typescript id="st06"
function validateStumpJob(
  input: unknown
): ValidationResult {
  const errors: string[] = [];

  if (
    typeof input !== "object" ||
    input === null ||
    Array.isArray(input)
  ) {
    return {
      valid: false,
      errors: ["Opgaven skal være et objekt."]
    };
  }

  const item = input as Record<string, unknown>;

  if (
    typeof item.id !== "string" ||
    item.id.trim().length === 0
  ) {
    errors.push("Opgaven mangler et gyldigt ID.");
  }

  if (
    typeof item.area !== "string" ||
    item.area.trim().length === 0
  ) {
    errors.push("Område mangler.");
  }

  if (
    typeof item.stumpCount !== "number" ||
    !Number.isInteger(item.stumpCount) ||
    item.stumpCount < 1
  ) {
    errors.push(
      "Antal stubbe skal være et positivt heltal."
    );
  }

  const accessValues = [
    "open",
    "limited",
    "unknown"
  ];

  if (!accessValues.includes(String(item.access))) {
    errors.push("Ugyldig adgangstype.");
  }

  const groundUses = [
    "lawn",
    "planting",
    "paving",
    "undecided"
  ];

  if (!groundUses.includes(String(item.futureUse))) {
    errors.push("Ugyldig anvendelse af området.");
  }

  if (
    typeof item.undergroundServicesChecked !==
    "boolean"
  ) {
    errors.push(
      "Kontrolstatus skal være true eller false."
    );
  }

  if (errors.length > 0) {
    return {
      valid: false,
      errors
    };
  }

  return {
    valid: true,
    data: item as StumpJob
  };
}

Funktionen kontrollerer hvert felt.

Hvis noget mangler eller har en ugyldig værdi, returnerer den en fejl.

Hvis alle oplysninger opfylder vores model, returnerer den det validerede objekt.

Bemærk forskellen mellem en korrekt datastruktur og en korrekt faglig beslutning.

Funktionen kontrollerer kun strukturen.

Den kan ikke vide, om den registrerede information stemmer med de faktiske forhold i haven.

6. Test resultatet

Vi starter med det gyldige eksempel.

```typescript id="st07"
const result = validateStumpJob(exampleJob);

if (result.valid) {
console.log(
Registreret ${result.data.stumpCount} stubbe
);
} else {
console.log(result.errors);
}




For vores eksempel bliver resultatet:



```text id="st08"
Registreret 3 stubbe

Hvis vi bruger de ugyldige data, får vi i stedet en liste med fejl.

Det gør det nemmere at give præcis feedback til den del af programmet, der sender oplysningerne.

7. Tilføj en funktion til administrative opfølgninger

En registreret opgave kan være teknisk gyldig, selv om nogle oplysninger endnu mangler at blive undersøgt.

For eksempel kan adgangsforholdene være ukendte.

Det betyder ikke, at registreringen skal afvises.

I stedet kan vi oprette en liste over administrative opfølgninger.

```typescript id="st09"
function getFollowUps(job: StumpJob): string[] {
const followUps: string[] = [];

if (job.access === "unknown") {
followUps.push(
"Adgangsforhold skal beskrives."
);
}

if (job.access === "limited") {
followUps.push(
"Maskinadgang skal vurderes af fagperson."
);
}

if (job.futureUse === "undecided") {
followUps.push(
"Kundens planer for området skal afklares."
);
}

if (!job.undergroundServicesChecked) {
followUps.push(
"Oplysninger om nedgravede installationer " +
"skal gennemgås."
);
}

return followUps;
}




Funktionen returnerer ikke en pris.

Den vælger heller ikke maskine, arbejdsdybde eller sikkerhedsafstande.

Den gør kun opmærksom på oplysninger, der kræver yderligere behandling.

For vores eksempel får vi to opfølgninger:



```typescript id="st10"
console.log(getFollowUps(exampleJob));

Resultat:

```text id="st11"
[
"Maskinadgang skal vurderes af fagperson.",
"Oplysninger om nedgravede installationer skal gennemgås."
]




Det er et eksempel på automatisering, der hjælper en medarbejder uden at erstatte vedkommendes vurdering.

## 8. Skriv automatiske tests

Nu skal vi sikre, at vores funktioner opfører sig som forventet.

Vi holder eksemplet enkelt og bruger en lille testfunktion uden eksterne testbiblioteker.



```typescript id="st12"
function assert(
  condition: boolean,
  message: string
): void {
  if (!condition) {
    throw new Error(`Test fejlede: ${message}`);
  }
}

Herefter tilføjer vi vores tests.

```typescript id="st13"
const validResult = validateStumpJob(exampleJob);

assert(
validResult.valid,
"En gyldig opgave skal accepteres."
);

const invalidCount = validateStumpJob({
...exampleJob,
stumpCount: -2
});

assert(
!invalidCount.valid,
"Et negativt antal skal afvises."
);

const invalidAccess = validateStumpJob({
...exampleJob,
access: "very easy"
});

assert(
!invalidAccess.valid,
"Ukendte adgangstyper skal afvises."
);

const followUps = getFollowUps(exampleJob);

assert(
followUps.length === 2,
"Eksemplet skal give to opfølgninger."
);

console.log("Alle tests bestået.");




Hvis alle tests passerer, bliver resultatet:



```text id="st14"
Alle tests bestået.

Hvis en test fejler, bliver der kastet en fejl.

Det er en enkel måde at lære automatiseret testning på.

I en større applikation kan man bruge et egentligt testbibliotek, men principperne er de samme:

Definér den forventede adfærd, og kontrollér den automatisk.

9. Sådan kører du eksemplet

Du skal have Node.js og TypeScript installeret.

Opret et lille projekt:

```bash id="st15"
mkdir stump-jobs
cd stump-jobs
npm init -y
npm install --save-dev typescript




Gem alle TypeScript-eksemplerne i samme fil, `stump-jobs.ts`, i den rækkefølge, de er vist.

De ugyldige eksempeldata kan bruges direkte som testinput.

Kompilér filen:



```bash id="st16"
npx tsc stump-jobs.ts --target es2020 --module commonjs --strict

Kør derefter den genererede JavaScript-fil:

```bash id="st17"
node stump-jobs.js




Du bør se output fra både registreringen, opfølgningerne og testene.

Før koden bruges i et rigtigt system, bør tests og produktionskode placeres i separate filer.

## 10. Hvorfor må vi ikke automatisere arbejdsmetoden?

Nu har vi en datamodel, som kan håndtere oplysninger om stubfræsning.

Det kunne være fristende at udvide den med regler som:

"Hvis stubben er lille, skal der bruges en bestemt maskine."

Eller:

"Hvis der er god adgang, kan arbejdet udføres uden yderligere kontrol."

Men den slags regler ville være misvisende.

Størrelse og adgang fortæller ikke hele historien.

Der kan være kabler og rør under jorden, sten omkring stubben eller levende trærødder tæt på arbejdsområdet.

Derfor bør et almindeligt administrationssystem ikke automatisk fastslå, at en opgave er sikker.

Det bør i stedet gøre det tydeligt, hvilke oplysninger der er registreret, og hvad der kræver en faglig vurdering.

**Et gyldigt objekt er ikke det samme som en sikker arbejdsplads.**

## 11. En virkelig branchekontekst

Skovhugger Lund er en træservicevirksomhed med base i Kolding.

Virksomheden tilbyder blandt andet stubfræsning, rodfræsning og fjernelse af gamle hækstubbe i Syddanmark.

Opgaverne kan variere fra én enkelt stub i en privat have til større områder med mange stubbe og rødder.

På virksomhedens side om [stubfræsning i Kolding](https://www.skovhuggerlund.dk/stubfraesning/) beskrives både de forskellige maskintyper og muligheden for efterbehandling af området.

Det er et godt eksempel på, hvorfor en datamodel kan indeholde oplysninger om antal, adgang og fremtidig anvendelse.

Disse felter kan hjælpe med at organisere en forespørgsel, men de kan ikke alene afgøre, hvordan arbejdet skal udføres.

Tutorialen er et selvstændigt programmeringseksempel. Den beskriver ikke et system, som Skovhugger Lund bruger i dag.

## 12. Hvad ville jeg forbedre i en rigtig applikation?

Vores model er lille og overskuelig, men en produktionsløsning ville kræve mere arbejde.

Jeg ville især se på fire områder.

**Servervalidering:** Alle data, der kommer fra brugere eller eksterne tjenester, skal valideres på serveren.

**Databeskyttelse:** Et egentligt kundesystem skal håndtere personoplysninger sikkert og kun opbevare nødvendige data.

**Adgangskontrol:** Det skal være tydeligt, hvem der må oprette, læse og ændre opgaver.

**Sporbarhed:** Ændringer i administrative statusser bør kunne dokumenteres, så medarbejdere kan forstå, hvad der er blevet registreret.

Man kan også overveje at bruge et bibliotek til skemavalidering, hvis datamodellen bliver større.

Men det er en god øvelse først at forstå valideringen uden ekstra afhængigheder.

## Afslutning

Vi har nu oprettet en typesikker datamodel, bygget en valideringsfunktion og skrevet automatiske tests.

Eksemplet viser, hvordan TypeScript kan hjælpe med at skabe mere ensartede registreringer.

Det viser også, hvorfor et godt system skal kende sine egne begrænsninger.

Software kan sikre, at et antal er positivt, og at en opgavetype findes på en godkendt liste.

Men den kan ikke ud fra disse oplysninger alene vurdere jordforhold, maskinsikkerhed eller arbejdsmetoder.

Den forskel er vigtig.

**God kode organiserer det, vi ved, og gør det tydeligt, hvad vi stadig mangler at undersøge.**

Byg en enkel formular til træbeskæring med JavaScript

Skovhugger Lund — Fri, 13 Nov 2026 09:48:01 +0000

En kunde skriver: "Vi har et træ, der skal beskæres."

Det lyder som en enkel henvendelse. Men for virksomheden mangler der stadig flere oplysninger.

Hvor står træet? Hvilken type arbejde drejer det sig om? Hvad ønsker kunden at få ændret?

En digital formular kan hjælpe med at samle svarene.

I denne tutorial bygger vi en lille JavaScript-løsning til at kontrollere og organisere forespørgsler om træbeskæring.

Vi bruger almindelig HTML og JavaScript uden eksterne biblioteker.

Eksemplet handler om datahåndtering, ikke om at automatisere faglige beslutninger om træers sundhed eller sikkerhed.

1. Hvad skal formularen kunne?

Vi forestiller os en mindre træservicevirksomhed i Kolding.

Virksomheden modtager forespørgsler om blandt andet beskæring, kroneløft og vurdering af beskadigede træer.

Vores eksempel skal kunne:

Registrere kundens område.
Lade brugeren vælge en opgavetype.
Modtage en kort beskrivelse.
Kontrollere obligatoriske oplysninger.
Oprette et struktureret JavaScript-objekt.
Vise en bekræftelse uden at sende data til en server.

Vi gemmer ikke navn, adresse eller telefonnummer i denne demonstration.

Det gør eksemplet lettere at teste uden rigtige personoplysninger.

2. Start med en enkel HTML-formular

Opret filen index.html.

<!doctype html>
<html lang="da">
<head>
  <meta charset="UTF-8">
  <meta name="viewport"
        content="width=device-width, initial-scale=1">
  <title>Registrering af træopgave</title>
</head>
<body>
  <main>
    <h1>Beskriv din træopgave</h1>

    <form id="treeForm">
      <label for="area">Område</label>
      <select id="area" name="area" required>
        <option value="">Vælg område</option>
        <option value="Kolding">Kolding</option>
        <option value="Fredericia">Fredericia</option>
        <option value="Vejle">Vejle</option>
        <option value="Middelfart">Middelfart</option>
      </select>

      <label for="service">Opgavetype</label>
      <select id="service" name="service" required>
        <option value="">Vælg opgave</option>
        <option value="Beskæring">Beskæring</option>
        <option value="Kroneløft">Kroneløft</option>
        <option value="Vurdering">Faglig vurdering</option>
      </select>

      <label for="details">Beskrivelse</label>
      <textarea
        id="details"
        name="details"
        minlength="15"
        maxlength="1000"
        required
      ></textarea>

      <button type="submit">
        Kontrollér oplysninger
      </button>
    </form>

    <p id="feedback" role="status"
       aria-live="polite"></p>
  </main>

  <script src="app.js"></script>
</body>
</html>

Formularen bruger almindelige HTML-felter.

required fortæller browseren, at et felt skal udfyldes.

minlength og maxlength begrænser længden af beskrivelsen.

aria-live="polite" gør det muligt for understøttede hjælpemidler at opfange ændringer i statusbeskeden.

Dette er en lille demonstration, ikke et færdigt tilgængelighedsdesign. En rigtig løsning bør også testes med tastatur og skærmlæser.

3. Beskriv data med et enkelt objekt

Når formularen bliver udfyldt, vil vi omsætte værdierne til et ensartet objekt.

Det kan eksempelvis se sådan ud:

const request = {
  area: "Kolding",
  service: "Beskæring",
  details: "En gren vokser tæt på terrassen.",
  status: "Afventer faglig vurdering"
};

Bemærk feltet status.

Vi registrerer ikke, at træet er farligt, eller at en bestemt beskæringsmetode er korrekt.

Vi registrerer kun, at forespørgslen kræver faglig vurdering.

Det er en vigtig designbeslutning.

4. Valider oplysningerne med JavaScript

Opret nu filen app.js.

Vi starter med en funktion, der kontrollerer vores data.

const allowedAreas = new Set([
  "Kolding",
  "Fredericia",
  "Vejle",
  "Middelfart"
]);

const allowedServices = new Set([
  "Beskæring",
  "Kroneløft",
  "Vurdering"
]);

function validateRequest(request) {
  const errors = [];

  if (!allowedAreas.has(request.area)) {
    errors.push("Vælg et gyldigt område.");
  }

  if (!allowedServices.has(request.service)) {
    errors.push("Vælg en gyldig opgavetype.");
  }

  if (
    typeof request.details !== "string" ||
    request.details.trim().length < 15
  ) {
    errors.push(
      "Beskrivelsen skal være mindst 15 tegn."
    );
  }

  if (
    typeof request.details === "string" &&
    request.details.length > 1000
  ) {
    errors.push(
      "Beskrivelsen må højst være 1000 tegn."
    );
  }

  return {
    valid: errors.length === 0,
    errors
  };
}

Vi bruger Set, fordi vi ønsker at kontrollere, om en værdi findes på en liste over tilladte muligheder.

Det er enklere end at skrive mange individuelle betingelser.

Funktionen returnerer både et resultat og eventuelle fejl.

Den kan derfor bruges af en formular, en test eller en fremtidig API-integration.

5. Håndtér formularens submit-event

Nu skal vi forbinde HTML og JavaScript.

Tilføj dette nederst i app.js:

const form = document.querySelector("#treeForm");
const feedback = document.querySelector("#feedback");

form.addEventListener("submit", (event) => {
  event.preventDefault();

  const formData = new FormData(form);

  const request = {
    area: String(formData.get("area") ?? ""),
    service: String(formData.get("service") ?? ""),
    details: String(
      formData.get("details") ?? ""
    ).trim(),
    status: "Afventer faglig vurdering"
  };

  const result = validateRequest(request);

  if (!result.valid) {
    feedback.textContent =
      result.errors.join(" ");
    return;
  }

  feedback.textContent =
    "Oplysningerne er kontrolleret. " +
    "De er ikke blevet sendt eller gemt.";

  // Her kan en rigtig applikation senere
  // integreres med en sikker backend.
});

event.preventDefault() forhindrer formularens normale indsendelse.

Vi bruger FormData til at hente værdierne.

Dernæst kalder vi valideringsfunktionen.

Hvis oplysningerne er gyldige, viser programmet en bekræftelse.

Der bliver ikke sendt nogen oplysninger til en server.

Derfor skal denne demonstration heller ikke beskrives som et fungerende bookingsystem.

6. Test valideringen

En god formular skal ikke kun virke, når brugeren gør alt korrekt.

Den skal også håndtere fejl.

Vi kan teste funktionen direkte i browserens konsol.

const testRequest = {
  area: "Kolding",
  service: "Beskæring",
  details: "Kort",
  status: "Afventer faglig vurdering"
};

console.log(validateRequest(testRequest));

Resultatet bliver:

{
  valid: false,
  errors: [
    "Beskrivelsen skal være mindst 15 tegn."
  ]
}

Ændr derefter beskrivelsen:

testRequest.details =
  "En gren hænger lavt over indkørslen.";

console.log(validateRequest(testRequest));

Nu bliver resultatet:

{
  valid: true,
  errors: []
}

Vi har dermed en grundlæggende kontrol, som også kan testes uden at udfylde formularen manuelt.

7. Gør fejlbeskederne nyttige

En god fejlbesked fortæller brugeren, hvad der skal ændres.

Sammenlign disse to beskeder.

Uklar besked:

Ugyldige data.

Mere hjælpsom besked:

Beskrivelsen skal være mindst 15 tegn.

Den sidste besked gør det lettere at rette fejlen.

I en større løsning kan man også vise fejlbeskeder ved de enkelte felter og sørge for korrekt tilknytning med aria-describedby.

Man bør ikke kun bruge farver til at vise fejl.

Teksten skal også forklare problemet.

8. Hvorfor bør vi ikke beregne træets risiko automatisk?

Forestil dig, at en bruger skriver:

"Træet hælder mod huset."

Det kan være en vigtig observation.

Men teksten fortæller ikke, om træet er ustabilt.

Et træ kan have vokset med en naturlig hældning i mange år.

Et andet træ kan have ændret hældning pludseligt på grund af problemer omkring rødderne.

Forskellen kan være meget vigtig.

Derfor bør en simpel formular ikke omsætte bestemte ord til konklusioner som:

Træet er sikkert.
Træet er farligt.
Træet skal fældes.
En bestemt gren skal fjernes.

Det kræver en faglig vurdering af de konkrete forhold.

Software kan indsamle observationer. Det betyder ikke, at softwaren kan vurdere træets stabilitet.

Ved mistanke om akut fare bør brugeren heller ikke være afhængig af en almindelig onlineformular. En virkelig løsning skal tydeligt oplyse, hvordan sådanne situationer håndteres.

9. Hvad med databeskyttelse?

Vores demonstration bruger kun område, opgavetype og beskrivelse.

Men et frit tekstfelt kan stadig indeholde personoplysninger.

En bruger kan eksempelvis skrive en privat adresse eller et telefonnummer i beskrivelsen.

Derfor bør man ikke automatisk logge eller offentliggøre formularens indhold.

Hvis løsningen senere skal håndtere rigtige henvendelser, bliver der behov for flere overvejelser:

Sikker overførsel med HTTPS
Serverbaseret validering
Passende adgangskontrol
Begrænset opbevaring af personoplysninger
Retningslinjer for sletning
Et relevant behandlingsgrundlag

Browserbaseret validering er nyttig for brugeroplevelsen, men den kan omgås.

En backend skal derfor altid validere oplysningerne igen.

10. Den virkelige kontekst: Træbeskæring i Kolding

En træservicevirksomhed kan modtage meget forskellige henvendelser.

En kunde ønsker måske fri passage under et træ. En anden vil have vurderet en beskadiget gren.

Det er ikke nødvendigvis samme type opgave.

Skovhugger Lund er en træservicevirksomhed med base i Kolding. Virksomheden tilbyder blandt andet kroneløft, beskæring ved klatring og beskæring fra lift.

På virksomhedens side om beskæring af træer i Kolding kan man læse om arbejdet og de faglige hensyn, som indgår i professionel træpleje.

Det gør branchen til et godt eksempel på, hvorfor software skal skelne mellem en kundes beskrivelse og en professionel vurdering.

En formular kan hjælpe med at samle oplysninger.

Men den kan ikke alene fastlægge beskæringsmetode, pris eller sikkerhed.

Dette tutorial er et selvstændigt softwareeksempel. Det er ikke en beskrivelse af Skovhugger Lunds faktiske interne systemer.

11. Hvad kunne være næste udviklingstrin?

Hvis vi skulle videreudvikle løsningen, ville jeg prioritere tre forbedringer.

A. Bedre tilgængelighed

Felterne skal være lette at bruge med tastatur og skærmlæser.

Det er også vigtigt at teste fejlbeskeder og fokusstyring.

B. En sikker backend

En rigtig løsning skal have servervalidering, adgangskontrol og en gennemtænkt håndtering af data.

C. En tydelig arbejdsgang

En forespørgsel bør kunne bevæge sig gennem administrative statusser som:

Modtaget
    |
    v
Afventer faglig vurdering
    |
    v
Tilbud under udarbejdelse
    |
    v
Afsluttet

Det er administrative trin.

De siger ikke noget om, hvorvidt træet er sikkert, eller om en bestemt arbejdsmetode er forsvarlig.

Afslutning

Vi har bygget en lille HTML- og JavaScript-formular, som kan indsamle, kontrollere og strukturere oplysninger om træopgaver.

Løsningen bruger ingen eksterne biblioteker.

Den er enkel at forstå og kan testes direkte i browseren.

Det vigtigste er dog ikke mængden af kode.

Det er grænsen mellem det, programmet ved, og det, et menneske skal vurdere.

God software hjælper med at organisere arbejdet.

Den foregiver ikke at have faglig viden, som ikke findes i dataene.

Fra have til data: Organisér træfældningsopgaver med CSV og Python

Skovhugger Lund — Fri, 13 Nov 2026 09:02:58 +0000

En træfældningsopgave begynder ofte med en enkel besked:

"Vi har et stort træ i haven. Kan I komme og se på det?"

Men hvad sker der, når virksomheden får mange henvendelser?

Nogle handler om almindelig træfældning. Andre drejer sig om beskæring, stormskader eller stubfræsning. Oplysningerne kan hurtigt ende i forskellige e-mails, noter og regneark.

Her kan selv et lille digitalt system gøre en forskel.

I denne guide bygger vi et enkelt eksempel med CSV og Python. Målet er ikke at erstatte professionel planlægning eller vurdering af træer. Vi vil blot vise, hvordan data kan organiseres, så administrative opgaver bliver lettere at overskue.

Du behøver ingen database eller avanceret software for at komme i gang.

1. Hvilke oplysninger er nyttige?

Forestil dig en mindre virksomhed, der arbejder med træfældning i Kolding.

Når en kunde kontakter virksomheden, er det nyttigt at registrere, hvilken type opgave henvendelsen handler om.

Et simpelt system kunne indeholde disse felter:

Felt	Formål
opgave_id	Unikt nummer for opgaven
omraade	Område eller by
ydelse	Type af arbejde
adgang	Foreløbig beskrivelse af adgang
status	Administrativ status
vurdering	Om faglig vurdering mangler

Det er vigtigt at skelne mellem oplysninger fra kunden og en egentlig faglig vurdering.

En kunde kan eksempelvis skrive, at et træ ser ustabilt ud. Det betyder ikke, at systemet må registrere træet som farligt.

Det kræver en konkret undersøgelse af kvalificerede fagfolk.

2. Opret en CSV-fil

CSV er et enkelt tekstformat, der kan bruges til at gemme tabeldata.

Vi kalder filen traeopgaver.csv.

Eksemplet bruger semikolon som separator. Det er praktisk i mange danske regnearksmiljøer.

opgave_id;omraade;ydelse;adgang;status;vurdering
101;Kolding;Træfældning;Begrænset;Ny;Mangler
102;Fredericia;Beskæring;God;Planlagt;Udført
103;Kolding;Stubfræsning;Begrænset;Ny;Mangler
104;Vejle;Træfældning;God;Afsluttet;Udført
105;Kolding;Træpleje;Ukendt;Ny;Mangler

Alle poster er opdigtede eksempeldata. De beskriver ikke faktiske kunder eller opgaver hos Skovhugger Lund.

Fordelen ved denne struktur er, at oplysningerne kan læses af både mennesker og programmer.

Man kan åbne filen i et regneark eller behandle den med Python.

3. Læs data med Python

Python har et indbygget CSV-modul.

Derfor behøver vi ikke installere ekstra pakker.

Opret filen analyse.py i samme mappe som CSV-filen.

import csv

with open(
    "traeopgaver.csv",
    "r",
    encoding="utf-8-sig",
    newline=""
) as fil:
    reader = csv.DictReader(fil, delimiter=";")
    opgaver = list(reader)

for opgave in opgaver:
    print(
        opgave["opgave_id"],
        opgave["omraade"],
        opgave["ydelse"],
        opgave["status"]
    )

Koden gør tre ting:

Åbner CSV-filen.
Læser hver række som en dictionary.
Udskriver udvalgte oplysninger.

DictReader gør det muligt at bruge kolonnenavne i stedet for kolonnenumre.

Det gør koden mere læsbar.

utf-8-sig hjælper også med at håndtere filer, der er gemt med UTF-8 BOM fra visse regnearksprogrammer.

4. Find opgaver, der mangler vurdering

Det næste skridt er at få overblik over, hvilke henvendelser der endnu ikke er gennemgået.

mangler_vurdering = [
    opgave
    for opgave in opgaver
    if opgave["vurdering"] == "Mangler"
]

print("Opgaver uden afsluttet vurdering:")

for opgave in mangler_vurdering:
    print(
        f"#{opgave['opgave_id']} - "
        f"{opgave['ydelse']} i "
        f"{opgave['omraade']}"
    )

Med vores eksempeldata får vi:

Opgaver uden afsluttet vurdering:
#101 - Træfældning i Kolding
#103 - Stubfræsning i Kolding
#105 - Træpleje i Kolding

Nu kan den administrative medarbejder se, hvilke opgaver der mangler opfølgning.

Bemærk, at vurdering kun beskriver den administrative registrering.

Programmet afgør ikke, om en opgave er sikker eller teknisk forsvarlig.

5. Skab overblik over opgavetyper

Hvis vi vil vide, hvilke typer henvendelser der findes i datasættet, kan vi bruge Counter.

from collections import Counter

fordeling = Counter(
    opgave["ydelse"]
    for opgave in opgaver
)

for ydelse, antal in sorted(fordeling.items()):
    print(f"{ydelse}: {antal}")

Resultatet bliver:

Beskæring: 1
Stubfræsning: 1
Træfældning: 2
Træpleje: 1

Denne type optælling kan bruges til at forstå fordelingen af registrerede henvendelser.

Det er dog vigtigt at læse tallene rigtigt.

Fem registrerede opgaver siger ikke noget sikkert om efterspørgslen i hele Kolding.

Et lille datasæt kan give et internt overblik, men det er ikke en markedsundersøgelse.

6. Kontrollér data før analyse

Et problem med CSV-filer er, at brugere kan skrive den samme opgavetype på forskellige måder.

Eksempelvis:

Træfældning
træfældning
Traefaeldning

For et menneske er betydningen tydelig.

For et program er det forskellige tekstværdier.

Derfor kan vi definere tilladte værdier.

gyldige_ydelser = {
    "Træfældning",
    "Beskæring",
    "Stubfræsning",
    "Træpleje"
}

for opgave in opgaver:
    if opgave["ydelse"] not in gyldige_ydelser:
        print(
            "Ukendt ydelse:",
            opgave["opgave_id"],
            opgave["ydelse"]
        )

Denne kontrol hjælper med at opdage tastefejl og uventede værdier.

Et større system kunne vise en dropdown-menu, så medarbejderen vælger en ydelse fra en fast liste.

Det kan mindske behovet for manuel oprydning i data.

7. Lav en enkel Markdown-rapport

Når oplysningerne er læst og kontrolleret, kan vi lave en lille rapport.

Markdown er praktisk, fordi formatet kan læses direkte som tekst og vises pænt på platforme som GitHub.

from collections import Counter

fordeling = Counter(
    opgave["ydelse"]
    for opgave in opgaver
)

linjer = [
    "# Oversigt over træopgaver",
    "",
    f"Antal registrerede opgaver: {len(opgaver)}",
    "",
    "## Fordeling efter ydelse",
    ""
]

for ydelse, antal in sorted(fordeling.items()):
    linjer.append(f"- {ydelse}: {antal}")

rapport = "\n".join(linjer) + "\n"

with open(
    "rapport.md",
    "w",
    encoding="utf-8"
) as fil:
    fil.write(rapport)

print("Rapporten er gemt.")

Resultatet bliver en fil med denne struktur:

# Oversigt over træopgaver

Antal registrerede opgaver: 5

## Fordeling efter ydelse

- Beskæring: 1
- Stubfræsning: 1
- Træfældning: 2
- Træpleje: 1

Det er et lille eksempel, men det viser en nyttig arbejdsgang:

CSV-data bliver til en læsbar oversigt uden manuel optælling.

8. Hvorfor bør man ikke automatisere selve sikkerhedsvurderingen?

Her kommer en vigtig forskel mellem almindelig datahåndtering og fagligt træarbejde.

Et program kan godt registrere oplysninger som:

Træfældning ønskes
Adgangsforhold er begrænsede
Kunden har meldt om en knækket gren
Faglig vurdering mangler

Men programmet kan ikke alene afgøre, om træet er stabilt, eller hvilken fældningsmetode der er sikker.

Det kræver en vurdering af blandt andet træets tilstand, omgivelserne og de konkrete arbejdsforhold.

Et stort træ tæt på et hus kan eksempelvis kræve sektionsfældning, klatring eller andet specialudstyr.

De metoder skal vælges af kvalificerede fagfolk.

Derfor er det en god idé at holde administrative data adskilt fra faglige beslutninger.

Et digitalt system bør støtte medarbejdernes arbejde, ikke erstatte deres professionelle vurdering.

9. Hvad med persondata?

Eksemplet bruger kun fiktive opgave-ID'er og generelle områdenavne.

Virkelige kundeoplysninger kræver større omtanke.

Navne, telefonnumre, adresser og billeder af private ejendomme kan være personoplysninger.

Hvis oplysningerne kan knyttes til en identificerbar person, skal de håndteres efter relevante databeskyttelsesregler.

Man bør blandt andet overveje:

Hvilke oplysninger der faktisk er nødvendige
Hvem der må læse dem
Hvordan de opbevares sikkert
Hvornår de skal slettes
Om der er et lovligt grundlag for behandlingen

Undgå at lægge virkelige kundedata i offentlige GitHub-repositories.

Hvis du vil dele et kodeeksempel, bør du bruge opdigtede eller korrekt anonymiserede data.

10. Et praktisk eksempel fra træservicebranchen

Skovhugger Lund er en træservicevirksomhed med base i Kolding.

Virksomheden arbejder blandt andet med træfældning, beskæring, stubfræsning og skovpleje.

Opgaverne kan variere fra almindelige havetræer til træer, som står tæt på bygninger eller har vanskelige adgangsforhold.

På virksomhedens side om professionel træfældning i Kolding kan man læse mere om de forskellige arbejdsmetoder og forhold, som kræver faglig vurdering.

Det er netop denne forskel mellem administrative oplysninger og praktisk arbejde, der gør et enkelt digitalt system interessant.

Et system kan organisere henvendelser, dokumentere status og hjælpe med opfølgning.

Men det skal stadig være medarbejderne, der vurderer den konkrete opgave.

Dette tutorial er et generelt softwareeksempel. Det beskriver ikke et internt system, som Skovhugger Lund anvender.

11. Mulige forbedringer

Når den enkle løsning fungerer, kan man bygge videre på den.

Et naturligt næste skridt kunne være at tilføje:

Validering af obligatoriske felter
Kontrol af dublerede opgave-ID'er
Filtrering efter område
En intern oversigt over administrative opgavestatusser
Eksport til et regneark
Adgangskontrol, hvis rigtige kundeoplysninger indgår

For større datasæt kan en database være mere passende end CSV.

Men til at lære grundlæggende datahåndtering er CSV et godt sted at begynde.

Det kræver få værktøjer og gør det let at forstå, hvordan oplysninger bevæger sig fra en tekstfil til en rapport.

Afsluttende tanke

Digitalisering behøver ikke begynde med en stor platform.

Nogle gange er en tydelig datastruktur og et kort Python-script nok til at skabe et bedre administrativt overblik.

Det gælder også i praktiske brancher som træpleje og skovarbejde.

Teknologien kan hjælpe med at holde styr på oplysningerne.

Fagligheden afgør stadig, hvordan arbejdet skal udføres.