Form Styling: Enklere og mer fleksibel stilsetting av forms

Problem

Form-blokken har begrenset stilsettingsfleksibilitet i builder-config. Flere vanlige bruksscenarier krever custom CSS som burde vart tilgjengelig som config-opsjoner. Dette gjor det vanskelig for ikke-tekniske brukere a lage enkle form-layouts.

I tillegg er templatene tungt pre-stylet, slik at brukere som vil ha en enkel form (bare inputs uten pynt) ma bruke mye tid pa a fjerne standardstyling.

Konkrete mangler i dag

Behov	Status i dag	Workaround
Hojde per input	Ikke mulig i config. Styres av padding/line-height/font-size globalt	Custom CSS: .ft1 .form-input-field { height: 36px }
Skjule label	Mulig ved a la label-feltet sta tomt. Men ingen template uten labels, sa brukere ma fjerne dem manuelt per input	Sett label til tom streng per input
Skjule required-stjerne	Ikke mulig. Hardkodet rod stjerne (#ef4444) nar required er pa	Custom CSS: .form-input .required-asterisk { display: none }
Required-stjerne farge/stil	Hardkodet #ef4444, bold, 16px	Custom CSS
Per-input typografi	labelStyle finnes i types.ts men er ikke eksponert i UI	Custom CSS
Per-input padding	Ikke tilgjengelig i config	Custom CSS
Template uten labels	Ikke tilgjengelig. Alle templates har labels satt, ma fjernes manuelt per input	Slett label-tekst per input
Enkel/blank form template	"Empty" template har fortsatt mye styling (bakgrunn, border, hover states)	Manuell fjerning av all styling
Rekkefoljendring av inputs	Kun via context menu (Bring Forward/Send Backward)	Ingen drag-and-drop
Submit-knapp ikke midtstilt	Nar width < 100%, legger wrapperen seg til venstre (mangler margin: 0 auto)	Custom CSS: .form-submit-button-wrapper { margin: 0 auto }
Autofill-styling	Nettleser overstyrer input-bakgrunn med bla farge via :-webkit-autofill	Custom CSS med -webkit-box-shadow: inset hack

Template-problemet

Alle 5 eksisterende templates (Empty, Contact, Lead Gen, Survey, Contest) har tung pre-styling:

Default-property	Verdi	Konsekvens
Form bakgrunn	#FFFFFF33 (semi-transparent)	Ma endres eller fjernes
Form border	1px solid svart	Ma fjernes for enkel look
Input bakgrunn	#D1D1D1FF (gra) / #FFFFFF (white)	Feil farge for de fleste designs
Input hover state	Bla bakgrunn #8AB0FF + border #0056B3 + shadow	Overveldende for enkle forms
Input focus state	Bla bakgrunn #A4C1FF + glow	Overveldende for enkle forms
Submit-knapp	Bla med hover-scale, shadow, 4 states	Ma styres helt om
Border radius	4-12px overalt	Ma nullstilles for skarpe hjorner

"Empty Form" er den reneste, men den har fortsatt full styling pa inputs, hover/focus states, submit-knapp med shadow og scale-animasjon. Det er ingen mate a starte fra scratch.

Sammenligning med andre blokktyper

Form-inputs mangler mange config-opsjoner som finnes i Text og Button:

Funksjon	Text	Button	Form Input
Typografi (font, size, weight)	Ja	Ja (per state)	Kun globalt
Padding	Ja	Ja	Kun globalt
Border radius	Ja	Ja	Kun globalt
Box shadow	Ja	Ja (per state)	Kun globalt
Text shadow	Ja	Nei	Nei
Filter/backdrop filter	Nei	Ja	Nei
Scale/transform	Nei	Ja (per state)	Nei
Per-element hojde	Via padding	height property	Nei
Rotation	Ja	Ja	Nei

---

Foreslatte endringer

Fase 1: Quick wins (lav kompleksitet)

Minimalt invasive endringer som loser de mest akutte problemene.

1.1 Submit-knapp midtstilling (bug)

Submit-knapp wrapperen far width fra config men mangler margin: 0 auto, sa den legger seg til venstre nar bredden er under 100%.

Engine (CE):

• I styles() linje ~877, legg til margin: '0 auto' pa submitButtonWrapper-stilen

Kompleksitet: Triviell. En linje.

1.2 Disabled submit-knapp hover (bug)

Nar submit-knappen er disabled (under innsending, etter submit, etc.) viser den fortsatt hover-effekter (bakgrunn, border, shadow, cursor pointer). Hover-stiler bor ikke gjelde nar knappen er disabled.

Engine (CE):

• I styles(), legg til .form-submit-button:disabled:hover og .form-submit-button:disabled som overstyrer hover-stilen
• Sett cursor: 'not-allowed', fjern hover-bakgrunn/shadow/transform, behold disabled-stilene

Kompleksitet: Triviell. Noen linjer i styles().

1.3 Required asterisk visibility

Frontend (AF):

• Legg til showRequiredIndicator: boolean (default true) i FormInputProperties eller globalt i globalInputStyling
• Toggle i RequiredFieldSection: "Show required indicator" (synlig bare nar required er pa)

Engine (CE):

• Wrap .required-asterisk rendering med sjekk pa showRequiredIndicator

Kompleksitet: Lav. Samme monster som label toggle.

1.4 Input height (global)

Frontend (AF):

• Legg til inputHeight: number | null i GlobalInputLayoutStyling (types.ts)
• Ny seksjon i FormConfiguration "Inputs"-tab: "Input height" med InputField (number, px)
• null = auto (styrt av padding/font som i dag)

Engine (CE):

• I styles(): Sett height pa .form-input-field nar verdi er satt

Kompleksitet: Lav. En property, en seksjon, en linje i styles().

1.5 Autofill-styling fix

Nettlesere (Chrome/Safari) overstyrer input-bakgrunn med bla farge via :-webkit-autofill. Dette bor fikses i engine slik at autofill respekterer input-bakgrunnsfargen.

Engine (CE):

• I styles(), legg til autofill-override pa .form-input-field:

  '&:-webkit-autofill, &:-webkit-autofill:hover, &:-webkit-autofill:focus': {
    '-webkit-box-shadow': `0 0 0 1000px ${bgColor} inset`,
    '-webkit-text-fill-color': textColor,
    'transition': 'background-color 5000s ease-in-out 0s',
  }

• bgColor og textColor hentes fra globalInputStyling.layout.background / .style.color

Kompleksitet: Lav. Noen linjer i styles(), ingen frontend-endringer.

1.6 "Blank" form template

Ny template: blankForm.ts med FormTemplate.BLANK:

• Ingen bakgrunn pa form-container (background: false)
• Ingen border pa form-container (border: false)
• Gjennomsiktige inputs med tynn border (background: false, border: true, 1px solid #ccc)
• Ingen labels -- bare placeholders (label-felt satt til tom streng)
• Ingen hover/focus state-effekter (bare border-color endring)
• Ingen box-shadow noe sted
• Enkel submit-knapp uten shadow/scale
• 2-3 text-inputs + email
• Minimal padding og margin

Kompleksitet: Lav. Ny template-fil, registrer i registry. Ingen engine-endringer.

Fase 2: Per-input overrides (medium kompleksitet)

2.1 Per-input height override

Frontend (AF):

• Legg til height: number | null i FormInputProperties
• Seksjon i BaseInputConfiguration: "Height" med InputField (px)
• null = bruk global height

Engine (CE):

• I per-input styles: Override .{shortCode} .form-input-field { height } nar satt

Kompleksitet: Medium. Krever at per-input styles merger med global styles riktig.

2.2 Per-input styling panel

Utvid per-input config med egne seksjoner for:

• Background (override global)
• Border (override global)
• Border radius (override global)
• Padding (override global)

Mye av dette er allerede delvis pa plass via customCSS per input og eksisterende properties i FormInputProperties (background, backgroundSettings, border, borderStyle), men det finnes ingen UI-seksjoner for dem i BaseInputConfiguration.vue. De eksisterer i typesystemet uten a vare eksponert.

Kompleksitet: Medium. Legge til eksisterende seksjonskomponenter (BackgroundStyleSection, BorderStyleSection osv.) i BaseInputConfiguration.

2.3 Fractional indexing for form input ordering

Form-inputs bruker i dag order-property og "Bring Forward"/"Send Backward" via context menu. Dette er tungvint og upresist. Block ordering i builder bruker allerede fractional indexing (PR under review, branch improve-change-operators), og form-inputs bor bruke samme system.

Tilnerming:

• Bytt fra heltalls order til fractional index (same som blokk-ordering)
• Gjenbruk generateFractionalIndex() / getOrderBetween() fra block ordering
• Muliggjor drag-and-drop reordning i config-panelet (ordnet liste av inputs)
• Alternativt: visuell DnD direkte i form-blokken i canvas

Fordeler:

• Konsistent ordering-system pa tvers av blokker og form-inputs
• Unnga race conditions og reordning-bugs som block ordering allerede har lost
• Naturlig stotte for "flytt mellom" to inputs uten a reindeksere alle

Kompleksitet: Medium. Mesteparten av logikken finnes allerede i block ordering. Krever UI for DnD i config-panel.

2.4 Opprydding av form-kode

Form-koden er tung og vanskelig a vedlikeholde. Konkrete oppryddingsomrader:

Engine (CreativeFormBlock.vue):

• styles() computed er svart stor (200+ linjer). Brekk opp i mindre metoder: getInputBaseStyles(), getLabelStyles(), getRequiredStyles(), getPerInputStyles(), getStateStyles()
• Hardkodede verdier (asterisk-farge #ef4444, placeholder-farge #9ca3af, focus ring #3B82F6) bor trekkes ut som konfigurerbare properties
• Required asterisk-logikk (label vs input-plassering) er duplisert og knotete

Frontend config:

• FormConfiguration.vue (529 linjer) gjor for mye. Tabs-logikken kan forenkles
• BaseInputConfiguration.vue har ubrukte slots og mangler UI for properties som finnes i typesystemet
• 11 type-spesifikke config-filer har mye duplisert kode (validering, label, placeholder). Vurder a samle mer i BaseInputConfiguration
• formInputDefaults i defaults.ts har tunge hover/focus defaults som sjelden brukes som de er

Kompleksitet: Medium. Refaktorering, ingen funksjonelle endringer. Kan gjores inkrementelt.

Fase 3: Avansert (hoy kompleksitet, fremtidig)

3.1 Required indicator customization

• Endre tekst (f.eks. "*" til "(required)" eller "(obligatorisk)")
• Endre farge, storrelse, posisjon
• Velge mellom inline (ved label) og floating (i input-feltet)

3.2 Label styling per input

• Per-input font, farge, storrelse for label (override global labelStyle)
• labelStyle eksisterer allerede i FormInputProperties men er ikke eksponert i UI
• Label posisjon: over input, ved siden av, floating label (material design-stil)

3.3 Form layout presets

• Preset layouts: "Stacked" (standard), "Compact" (liten padding, ingen labels), "Inline" (label ved siden av input), "Material" (floating labels)
• Preset velges i FormConfiguration, setter fornuftige defaults for label/height/padding
• Bruker kan overstyre enkeltinnstillinger etter valg av preset

3.4 Per-input state styling UI

stateConfig finnes allerede i FormInputProperties (types.ts linje 835), men det finnes ingen UI for a konfigurere det. Legg til hover/focus config-tabs per input, lik button-konfigurasjon.

3.5 Form submission event / success-state

Tre nivaer av post-submit-opplevelse:

Niva 1: Innebygd success-state (enklest)

• Form-blokken bytter innhold etter vellykket submit: skjuler inputs, viser en konfigurerbar "thank you"-melding
• Allerede delvis der med success-state pa submit-knappen, men ingen innholdsbytte
• Konfigurerbart i FormConfiguration: success-melding tekst, styling, auto-skjul etter X sekunder
• Krever: ny property successContent i formProperties, rendering-logikk i engine

Niva 2: Signal/event til flow (fleksibelt)

• Form sender en event (formSubmitted) som flow-systemet kan lytte pa
• Fungerer akkurat som button clicks trigger flow-steg (show/hide operatorer)
• Brukeren kan sette opp: "nar form er sendt inn, skjul form-operator og vis avslutningsskjerm-operator"
• Passer naturlig med eksisterende flow-arkitektur og operator show/hide
• Krever: event-emitting i engine etter submit, ny event-type i flow-systemet

Niva 3: Multipage form (avansert)

• Form-blokken handterer flere "sider" internt
• Neste/forrige-knapper mellom sider
• Validering per side (ikke submit for siste side)
• Progress-indikator (steg 1/3, 2/3, 3/3)
• Krever: ny datastruktur for sider, ny navigasjons-UI, per-side validering

Niva 1 og 2 kan implementeres uavhengig. Niva 2 er mest fleksibelt og gjenbruker eksisterende flow-infrastruktur. Niva 3 er en storre feature som kan bygges pa toppen av 1 og 2.

---

Pafirte filer

Frontend (Application-Frontend)

Fil	Endring
Blocks/data/types.ts	Nye properties i FormInputProperties og GlobalInputLayoutStyling
Blocks/data/defaults.ts	Default-verdier for nye properties
Configuration/configs/FormConfiguration.vue	Global input height seksjon
Configuration/configs/FormInputConfiguration.vue	Per-input height seksjon
Configuration/components/Form/BaseInputConfiguration.vue	Label toggle, height override, per-input styling seksjoner
Configuration/components/Form/RequiredFieldSection.vue	Asterisk visibility toggle
templates/form/blankForm.ts	Ny blank template
templates/form/index.ts	Eksporter blank template
templates/index.ts	Registrer i templateRegistry
Nye seksjoner (evt.)	InputHeightSection.vue, LabelVisibilitySection.vue

Engine (Creative-Engine)

Fil	Endring
CreativeFormBlock.vue	v-if for label, asterisk; height i styles()

Backend

Ingen endringer nodvendig. Properties lagres som del av blokkdata (JSON) som allerede stotter vilkarlige felter.

---

Estimert scope

Fase	Oppgaver	Risiko
Fase 1	6 features (submit midtstilling, disabled hover, required toggle, global height, autofill fix, blank template)	Lav. Isolerte endringer, ingen breaking changes
Fase 2	4 features (per-input height, styling panel, fractional ordering, kode-opprydding)	Medium. Per-input override-logikk, refaktorering
Fase 3	5 features (required customization, label styling, layout presets, per-input states, submission event/success)	Hoy. Krever redesign av form-rendering, flow-integrasjon og ny UI

Bakoverkompatibilitet

Alle nye properties har defaults som matcher dagens oppforsel:

• showRequiredIndicator: true (stjerne vises som for)
• inputHeight: null (auto-hojde som for)
• height: null per input (bruker global)

Eksisterende creatives pavirkes ikke.

Prioritet

Fase 1 bor prioriteres forst. De fire oppgavene loser de vanligste frustrasjonene med minimal innsats:

• Required toggle lar brukere ha required-validering uten synlig stjerne
• Global input height gir kontroll over form-layout uten custom CSS
• Autofill fix fjerner nettleserens bla autofill-bakgrunn for alle creatives
• Blank template lar brukere starte fra scratch -- ingen labels, ingen styling, bare inputs med placeholders

Fase 2.2 (per-input styling panel) er saerlig interessant fordi FormInputProperties allerede har background, backgroundSettings, border, borderStyle og stateConfig i typesystemet - de mangler bare UI-seksjoner. Dette er lavthengende frukt.

Fase 2.3 (fractional indexing) bor gjores sammen med eller rett etter at block ordering PR-en merges, sa logikken er fersk og kan gjenbrukes direkte.

Fase 2.4 (opprydding) bor gjores for eller parallelt med fase 2-features, sa ny kode bygges pa et renere fundament.