How Taro Enables W3C‑Standard CSS to Run on HarmonyOS: Full CSS Processing Workflow

Based on the Taro framework, the JD HarmonyOS app follows the HarmonyOS Next public test; this second article in the series explains how to run W3C‑standard CSS on HarmonyOS.

HarmonyOS uses the self‑developed ArkUI UI framework, whose layout system and style control differ from standard CSS, causing compatibility problems for Taro developers; smoothing the differences between ArkUI standards and W3C CSS is a key task.

CSS and ArkUI CAPI styles differ in unit systems and data representation: CSS offers many size and color units, while ArkUI CAPI unifies sizes to vp and colors to 0xAARRGGBB . Complex properties such as gradients, transforms, and matrices must be converted to ArkUI‑compatible formats.

To avoid runtime performance penalties, static CSS is transformed at compile time using a Rust plugin built on lightningCSS. The plugin traverses the CSS AST and generates data structures directly usable by ArkUI CAPI.

Inline style attributes are parsed at runtime. Taro implements a set of lightweight CSS parsers that can extract values from strings or key‑value pairs, enabling accurate conversion with negligible overhead and laying the groundwork for CSS‑variable support.

Layout behavior also diverges: HarmonyOS absolute positioning is relative to the parent, lacks right / bottom , and does not support calc() or percentage values. The solution is to adopt the Yoga layout engine (Facebook’s open‑source FlexBox implementation) to emulate Web layout semantics on HarmonyOS.

During node construction, a parallel Yoga node tree is built. After Yoga computes layout, the resulting width , height , x , and y values are copied back to the corresponding HarmonyOS nodes, ensuring layout consistency across platforms.

The full style workflow includes:

Style initialization: loading compiled style files, generating StyleRule objects for each selector.

ClassName matching: extracting relevant StyleRule s from the stylesheet, merging by specificity, and merging with inline Style rules.

Handling pseudo‑elements and keyframes: pseudo‑elements are inserted as child nodes; keyframe animations are collected and processed in a separate thread to guarantee highest priority.

Style application: SetStyle updates layout‑related properties on Yoga nodes (marking them layout_dirty ) and drawing‑related properties on the node itself (marking draw_dirty ), deferring actual updates to the next frame.

Yoga layout calculation: invoking calcYGLayout , detecting nodes with has_new_layout , and propagating new layout values to HarmonyOS nodes.

Style updates: inline Style updates are merged directly; ClassName changes trigger selector re‑matching, dirty‑marking of affected nodes (including direct children and descendants), and batch processing in the next frame to minimise recomputation.

In summary, the article explains the end‑to‑end process by which Taro reconciles CSS with ArkUI, addressing syntax differences, layout mismatches, and update strategies to provide a unified, high‑performance cross‑platform development experience.