A discussion on HTML rendering: Can the HTML/CSS structure be "translated" and rendered natively by Slint?

[NLazyCat]

I've noticed a recurring demand in the community: the desire to render HTML within the Slint application. Currently, the mainstream suggestion seems to be integrating a WebView (e.g., via Wry) or integrating servo, but this essentially brings us back to the old path of embedding a heavyweight browser engine.

This has made me start thinking about a more "native" and potentially more challenging alternative. I'd like to propose this idea here, though it may not be practical.

Core Concept: A "Translation" Rather Than "Embedding" Rendering Pipeline

Our goal is to completely avoid using WebView. Instead, we can create a workflow that "translates" the class Web structures into Slint's native UI components.

1. Parsing Layer: Use a Rust library that excels at parsing HTML/CSS structures, such as DioxusLabs's Blitz (https://github.com/DioxusLabs/blitz). The advantage of such libraries lies in their ability to parse our familiar web markup languages (HTML) and CSS styles into a structured UI tree (an intermediate representation).
2. Rendering Layer: This is where the magic happens. The intermediate UI tree is passed to a "transformation layer," which dynamically converts it into Slint's native UI representation. This might involve generating .slint code, or ideally, directly constructing Slint component instances in memory. The final drawing work is then handed over to Slint's efficient renderer.

In short: Blitz (or similar libraries) is responsible for "understanding" HTML/CSS, and Slint is responsible for "drawing."

Technical Challenges and a Suggested Direction Forward

1. Core Architecture: Adopt a "Headless UI" pattern?

Instead of trying to directly map HTML tags to Slint's existing, styled components, can we build this system around a more flexible "headless UI" paradigm?

Specific suggestions are as follows:

a. First, we create a set of "headless" or "unstyled" base components in Slint. For example, a HeadlessButton component that only contains core logic (such as clicked callbacks and disabled states) but completely lacks any predefined visual styles (no default colors, borders, padding, etc.).

b. Our translator instantiates the HeadlessButton when it encounters the HTML <button> tag. Then, it parses the associated CSS and applies these style rules (such as background-color, border-radius, etc.) directly to the underlying rendering primitives that make up the HeadlessButton (e.g., its internal Rectangle and Text elements).

This approach completely separates structure from presentation, perfectly replicating the working model of HTML + CSS. It avoids the tedious work of creating corresponding property on the component for each CSS attribute, providing the greatest design flexibility.

2. Layout System Mapping (Core Challenge)

How can we efficiently and accurately "translate" the powerful CSS Flexbox and Grid layout models into Slint's layout system (HorizontalLayout, VerticalLayout, GridLayout)?

• A possible solution: Following the "headless" approach, the answer might not be mapping to existing layout components. Can we create a new custom component in Slint, such as a FlexBox component? The API of this component is designed to directly mimic CSS's display: flex and its related properties (flex-direction, justify-content, etc.). This way, the complexity of implementing the Flexbox algorithm is encapsulated within this highly optimized component. The translator's work is also simplified from complex logic 判断 to direct attribute passing. Is this a more manageable path?

Thank you all for your time!