Wind 1.1.0: a Flutter text field with no MaterialApp

I was building a screen inside a CupertinoApp last week and dropped a Wind text field into it. It crashed.

Wind is utility-first styling for Flutter: you write className strings like p-3 border rounded-lg instead of nesting six widgets by hand. But WInput, the one input widget, still leaned on Material under the hood. Outside a MaterialApp it threw. The workaround was ugly: wrap a Cupertino screen in a MaterialApp just to render one field.

So in Wind 1.1.0 I rebuilt it. WInput is now Material-free.

The problem

WInput used to wrap Material's TextField, which needs a Material ancestor for its theme and ink. Drop it under a CupertinoApp or a bare WidgetsApp and you got a layout exception, not a text field. For a utility-first library that is supposed to style anything, depending on Material to render an input was the wrong shape.

// Before 1.1.0: a Wind input outside MaterialApp threw.
// The workaround was to nest a MaterialApp just to render one field.
CupertinoApp(
  home: MaterialApp(
    home: WInput(value: email, onChanged: (v) => email = v),
  ),
);

How 1.1.0 handles it

WInput now renders on EditableText with a plain BoxDecoration border. No Material ancestor required. It works under MaterialApp, CupertinoApp, or a bare WidgetsApp.

// After 1.1.0: works directly under CupertinoApp, no MaterialApp.
CupertinoApp(
  home: WInput(
    value: email,
    onChanged: (v) => setState(() => email = v),
    type: InputType.email,
    placeholder: 'you@example.com',
    className: 'p-3 border border-gray-300 rounded-lg focus:ring-2 focus:ring-sky-500',
  ),
);

One honest caveat: the long-press selection toolbar and handles need an Overlay in the tree. CupertinoApp and MaterialApp both provide one. Under a bare WidgetsApp with no Overlay, typing, cursor movement, and focus all work; only the selection toolbar is suppressed, instead of crashing like before.

className aliases

The other change I am happy with is aliases. Wind ships a token catalog, but every project has shorthands that are not in it. Before, an unknown token was a silent no-op (issue #101): you wrote a class, saw nothing, and could not tell why. Now you register your own shortcuts once, on the theme:

WindTheme(
  data: WindThemeData(
    aliases: {
      'btn': 'px-4 py-2 rounded-lg bg-sky-600 text-white',
      'btn-lg': 'btn px-6 py-4 text-lg', // aliases expand recursively
    },
  ),
  child: const MyApp(),
);

Then a bare btn works in any widget, including WDynamic (the server-driven renderer), with no extra wiring:

WDiv(className: 'btn', child: WText('Save'));

Expansion is bounded three ways (a per-chain cycle guard, a depth cap, and a total-output budget), so a circular or fan-out alias map can never hang the parser.

Also in 1.1.0

WIcon.foregroundColor: a runtime-dynamic icon color that overrides the text-* class, for state-driven UI. It stays out of the parser cache key, so dynamic colors do not bloat the cache.
WInput polish: a readonly state (so readonly: prefixed classes style it), signed-decimal number input that holds on web too, Cupertino-style selection on every platform, dark-mode label pairs on the form widgets, and a disabled field that is genuinely non-interactive.