Modernise component styling with CSS variables

Summary

Replace hardcoded CSS values in address-finder and postcode-lookup with CSS custom properties (variables) to enable easy customisation.

Motivation

Currently, users who want to customise the appearance of these widgets must:

• Override CSS rules with higher specificity
• Use inline *Style options for each element
• Completely replace the default stylesheet

CSS variables provide a cleaner approach where users can set a few tokens to match their brand without fighting specificity.

Proposed Solution

Convert hardcoded values to CSS variables with sensible defaults:

/* Before */
div.idpc_af {
  background: #fff;
  border-radius: 3px;
}

/* After */
div.idpc_af {
  background: var(--idpc-bg, #fff);
  border-radius: var(--idpc-radius, 3px);
}

Customisation Options

1. Pure CSS:

:root {
  --idpc-bg: #1a1a1a;
  --idpc-selected-bg: #ff6b6b;
}

2. Via JS config (optional):

AddressFinder.watch({
  inputField: '#address',
  variables: {
    '--idpc-bg': '#1a1a1a',
    '--idpc-selected-bg': '#ff6b6b',
  },
});

Variables to Expose

| Variable | Default | Controls |
|----------|---------|----------|
| --idpc-bg | #fff | Dropdown background |
| --idpc-text | #28282b | Text color |
| --idpc-border-color | rgba(0,0,0,.3) | Border color |
| --idpc-radius | 3px | Border radius |
| --idpc-shadow | 0.05em 0.2em 0.6em rgba(0,0,0,.2) | Box shadow |
| --idpc-hover-bg | #e5e4e2 | Hover background |
| --idpc-selected-bg | #3d6d8f | Selected item background |
| --idpc-selected-color | #fff | Selected item text |
| --idpc-error-bg | #eee | Error state background |
| --idpc-font-family | inherit | Font family |

Scope

address-finder

• Convert css/address-finder.css to use CSS variables
• Update embedded CSS string in lib/css.ts
• Add optional variables option to controller

postcode-lookup

• Create base CSS file with CSS variables
• Add injectStyle option (matching address-finder API)
• Add optional variables option to controller

Backward Compatibility

• Defaults match current appearance exactly
• No breaking changes to existing API
• Existing *Style inline options remain as escape hatch

Alternatives Considered

1. Stripe-style Appearance API with themes - More complex, adds theme presets. Decided against to keep scope minimal.
2. CSS-in-JS runtime generation - Potential CSP issues, larger bundle size.

References

• Stripe Elements Appearance API - inspiration for the approach