If possible better Markup,flexbox layout

[sgf]

If possible,
hope that future versions will support better markup , similar to https://github.com/VincentH-Net/CSharpForMarkup
as well as Flex layouts support.

I am not entirely sure, but wouldn't it be more appropriate to address these tasks during the early stages of the project, given that they likely constitute foundational features?

Furthermore—unless support for mobile platforms is a specific requirement—I would advise against introducing external dependencies like SkiaSharp too readily; doing so would, after all, compromise the purity of the UI library.

Your UI library is excellent; it aligns almost perfectly with my aesthetic preferences for a UI framework.

[shonescript]

Based on the controls and basic markup capabilities provided by author, it is easy to extend the markup to the style you need, just writing some static wrapper classes. The key is that once the author's core graphics and control architecture is stable, this kind of markup can be fully extended by the community.
I question about your view on Skia, thinking it is bloated. Skia has already been a great and mature cross-platform rendering technology, highly adaptable, with many high-performance libraries implemented on it. Similarly, there are many useful libraries on System.Drawing, and migrating to other platforms is costly.
Personally, I feel that we can use MewUI for core interfaces as needed, and use Skia, or even WPF, WinForm, Avalonia, Uno for extended interfaces. There is no need to import every graphics or controls into MewUI at once, as that workload is unbearable; no one has that much time, and there is no need to reinvent many wheels.
On one hand, I completely agree that the MewUI core should maintain its current extremely streamlined approach and AOT-compatible path. On the other hand, I hope the core library would simply reserve some slots (or interfaces) to support compatibility and extensibility, and these extensions can be implemented by the community without being included in the core project.

[sgf]

Regarding Skia support, I think there are many Skia-based UI projects in the community, such as MordenForms and Avalonia. So I really can't think of any reason for MewUI to be another project similar to this kind of project, which violates the DRY principle. The .NET community already has many competing products based on Skia; MewUI should not become a new, overly homogenous copy.
Once MewUI supports Skia, MewUI output size will inevitably expand by at least 10mb.
The MewUI author' vision of keeping its AOT output size consistently below 10MB will immediately be dashed.
This will cause MewUI to immediately lose its size advantage. How to reflect the advanced nature of MewUI? What are the advantages of MewUI?

At the same time, Skia isn't good enough. If it were good enough, Flutter wouldn't need to develop a completely new rendering engine like Impeller from scratch. Currently, MewUI has zero dependencies and is 100% pure C#; adding external dependencies would have a huge negative impact on MewUI.

If Skia must be supported, I would prefer it to be an optional rendering backend, rather than a primary dependency on it.

Markup and Flex layout are important because they involve early development of underlying components.
If we have to wait until the future to support this feature, and it's only an optional extension, then it will inevitably mean that the underlying components will need to be updated on a large scale.
This leaves many hidden dangers for future work. If it can be supported in advance, the complexity of the component layout code will be reduced, and the code size will also be reduced (the binary output will be reduced), which will undoubtedly bring huge benefits. After all, once the ecology is built, if you want to reverse it, you will inevitably face huge difficulties.