wow-ui-skinning

Skin Blizzard UI without a framework dependency

Use this skill when the requested interface already belongs to Blizzard. For new addon-owned windows or controls with native styling, use wow-native-ui. For the overall design and testing choices, follow wow-addon-development, honoring answers already given.

Establish the surface and target

Resolve Retail, Forever, Classic progression, or their requested combination with wow-client-targets. Identify the exact window, intended visual change, and behaviors to retain. A character-frame redesign can alter ornament, spacing, fonts and layout while preserving equipment interaction, tooltips, tabs and the model. A request to replace those behaviors is a larger functional feature, not an incidental skin change.

Pin the selected client's source, then trace its owning TOC, selected XML/Lua variants, construction, update methods and data binding. Confirm frame and region identities from source and the actual client. A similarly named frame on another client is not a compatibility contract. Use the character and spellbook recipes as researched entry points, not universal object paths.

Implement a small skin layer

Read skinning architecture for module boundaries, load timing, repeated updates, pooling, safe hooks and disable behavior. Keep theme tokens separate from client adapters and per-window modules. Enable only the modules the user requested.

• Style existing controls where that meets the design. Keep their scripts, action attributes, hit targets, keyboard/gamepad behavior and state indicators. Add addon-owned decoration only when its layering and input behavior are understood.
• Separate one-time setup from state refresh. A frame may survive many different spell, item or list-row bindings. Repaint when Blizzard changes state; do not repeatedly create frames or install hooks.
• Prefer a narrow post-hook or documented callback at the actual visual update point. hooksecurefunc does not grant protected access or make mutations within its callback safe. Verify the selected client's hook and widget contracts through FrameXML and widget APIs.
• Treat NineSlice pieces, border art, masks, icon state, selected tabs and disabled states separately. Do not recursively strip every texture, hide every region, replace existing scripts, or disable a whole draw layer just to remove an ornament.
• Defer restricted mutations while in combat; re-resolve the current object and desired state afterward. Do not cache restricted values or assume an unprotected parent makes every child safe. Apply secret-value and taint rules for the verified client and operation.
• If another addon already skins the same surface, expose a per-module opt-out or explicitly coordinate ownership. Avoid competing hooks that continually undo each other's changes.