[c-smile]

It uses its own HTML/CSS engine designed by myself to be embeddable from ground up. Check this: https://sciter.com/10-years-road-to-sciter/

As of HTML: most of HTML5 constructs (I participated in HTML5 spec development at W3C as Invited Expert)

As of CSS: CSS2.1 in full. Some practically useful modules of CSS3 - transitions, transforms, etc.

I haven't added FlexBox as I think it is an architectural disaster - will not survive on the long run. Instead Sciter offers "flow and flex units" module: https://sciter.com/docs/flex-flow/flex-layout.htm that covers as FlexBox as Grid in unified manner. Yet check this: https://terrainformatica.com/w3/flex-layout/flex-vs-flexbox....

Yet, I've added quite a lot of HTML/CSS features that are the must for specifically desktop UI:

- <menu class=popup> and <popup> elements and their CSS support - windowed DOM elements that are rendered outside of main window canvas.

- <frame type=pager> - print preview and print feature.

- view.dialog("some.html"), view.window("some.html"), view.msgbox("some.html") - HTML defined windows and dialogs.

- <htmlarea> - native WYSIWYG HTML editing widget.

More on this: https://sciter.com/developers/for-web-programmers/

[the_duke]

Out of curiosity, what is your criticism of flexbox?

I only very rarely do CSS, but from a user perspective it's a huge improvement to what we had before.

Are you talking about implementation complexity?

[c-smile]

1. FlexBox breaks existing CSS Box model that mandates that dimensions of the element are defined by its width/height properties.

2. FlexBox introduces 12 (sic!) new properties in already overcrowded CSS property map. But as demonstrated by Sciter that can be achieved by just one property `flow` and flex units.

3. Flexbox and Grid are conflicting in the sense that the flexibility (as a feature) is defined in two different ways: separate properties (FlexBox) and 'fr' units (Grid) - overall CSS architecture becomes a zoo. Yet CSS has that famous 'auto' value that in some cases is just 1fr ( 1* in Sciter terms).

4. FlexBox is applied through 'display' property that is conceptually wrong. 'display' specifies how the element itself is replaced among its siblings but flexbox is rather about layout of element's children. These two entities are orthogonal. Example:

display:list-item; or display:table-cell; cannot be flexboxes. Just because of architectural specification error but physically nothing prevents <td> to use flexbox layout for their children.

5. Flexbox arrived too late. We started talking about the feature 12 years ago on www-style WG at W3C. And all these years Sciter already used flexibility (the must for desktop UI).

More on this: https://terrainformatica.com/2018/12/11/10-years-of-flexboxi...

[kroltan]

Not the parent, but in my view it is basically a 1-dimensional subset of Grid, which is great for mostly-1D website design. But when it comes to making applications (which often use the whole screen, with tabs and whatnot, instead of being scroll-oriented), it makes some things either really difficult, either still requiring custom code to get it just right, or having a handful of wrapper elements for relatively simple layouts.

Don't get me wrong, it's _miles_ better for web layout than the old systems, but since Sciter seems to be focused on application-style layouts, it makes sense to prefer a layout system that can better represent common patterns in that domain.

Also, if you plan on go responsive, the required flex wrappers kind of hold you back when you need to reorient a bunch of your layout to fit a vertical screen (or horizontal, if you're doing mobile-first), while Grid's `grid-area` is beautifully flexible in that regard.

TL;DR: If you're gonna have to have Grid, then just having Grid is perfectly fine as it can do everything Flex can and more.