6 ms·

HTML is half of the problem, the DOM is just fundamentally unsuited for app UI rendering, and CSS is a nightmare when applied to UI controls rather than text do

HTML is half of the problem, the DOM is just fundamentally unsuited for app UI rendering, and CSS is a nightmare when applied to UI controls rather than text documents. What we need is a cross platform well-thought-out scene graph like Flash had or Flutter (kinda) has.

deleted 6y ago
[deleted]
c-smile 6y ago
> the DOM is just fundamentally unsuited for app UI rendering... Consider the following: Native UI: is a tree of widgets. Each widget has sematic properties / attributes. Each widget may have style properties (colors ,fonts, etc.). Each widget has exactly on parent and may have multiple children. There is an API for all of these. HTML/DOM UI: Same as above, just replace "widget" by "element". Could you explain then why one of these is "fundamentally unsuited" and other is a perfect match?
- Sophistifunk 6y ago
  The most glaring is the ability to measure things (including text) in order to lay them out, rather than adding stuff to the tree and waiting a while for somebody else to lay them out in order to measure them. Followed closely by absolutely everything about the way overflow "works". After that I'd add the absolutely batshit insane hoops through which one still must jump to build any sort of text editing component without throwing away all the good things about HTML like accessibility; the things going on inside Visual Studio Code required to produce even an experience as good as that must haunt the team that builds it. The disconnect in process between "building something out of built-in components" against "build and using a new component", the list goes on. And just about all of these things are made worse by both the cascade rules and complicated precedence system of CSS.
  - c-smile 6y ago
    > The most glaring is the ability to measure things (including text) in order to lay them out ... This has nothing with the DOM (or HTML or CSS for that matter). Yes, sometimes in desktop UI you will need to know exact element position/dimensions. That's why in Sciter I've added: 1. element.update(); method, it will force dimensions to be calculated at this moment. 2. element.onSize = function() {...} called when dimensions of the element change. 3. element.paintContent = function(graphics) {} called to paint the element on graphics. Dimensions and position of the element is known at this moment. 4. There is a Graphics.Text object that allows to calculate (not just render) text and glyph positions. My main point with all this: it is a matter of API provided and has nothing with HTML/CSS per se. For that matter, Flutter also uses DOM (tree of widgets, etc.). It is just that its style system is not declarative and misses cascading - for some reasons they decided to use WPF/XAML way of doing business. But we've already sang "Sic transit gloria mundi" to WPF ... For the text editing... check html-notepad : https://html-notepad.com/ https://html-notepad.com/ . Left sidebar (structure outline) is computed and painted in immediate rendering painting mode - when paintContent of the document is invoked.
    - Sophistifunk 6y ago
      When I wrote "DOM" I meant the DOM as in the W3C one you're looking at right now, not Sciter, which I haven't used. Nothing wrong with the concept of trees of objects, other than the fact the tree usually forms part of the objects.
- tluyben2 6y ago
  The biggest problem I have with html/css is that the outcome seems unpredictable; I sit with very experienced web devs and still have to do trial and error sometimes to know where what will be and of what size. I hear, way to often, when I (backend/embedded dev) ask how to ‘not make X happen’ something like ‘try this or this’ after they check my css. How is that software development if you have to guess how things work? Maybe it is because I am a backend dev, but we have this issue far less with native dev; they just say ‘do this’ and indeed it works as expected.
- jbverschoor 6y ago
  HTML is for document/flow. Only with flexbox it became kind of usable for "apps". But still, the widgets are not native. You can keep emulating and emulating, but it's very easy to spot and quite frankly super annoying.

deleted 6y ago

[deleted]

c-smile 6y ago

> the DOM is just fundamentally unsuited for app UI rendering... Consider the following: Native UI: is a tree of widgets. Each widget has sematic properties / attributes. Each widget may have style properties (colors ,fonts, etc.). Each widget has exactly on parent and may have multiple children. There is an API for all of these. HTML/DOM UI: Same as above, just replace "widget" by "element". Could you explain then why one of these is "fundamentally unsuited" and other is a perfect match?

Sophistifunk 6y ago
The most glaring is the ability to measure things (including text) in order to lay them out, rather than adding stuff to the tree and waiting a while for somebody else to lay them out in order to measure them. Followed closely by absolutely everything about the way overflow "works". After that I'd add the absolutely batshit insane hoops through which one still must jump to build any sort of text editing component without throwing away all the good things about HTML like accessibility; the things going on inside Visual Studio Code required to produce even an experience as good as that must haunt the team that builds it. The disconnect in process between "building something out of built-in components" against "build and using a new component", the list goes on. And just about all of these things are made worse by both the cascade rules and complicated precedence system of CSS.
- c-smile 6y ago
  > The most glaring is the ability to measure things (including text) in order to lay them out ... This has nothing with the DOM (or HTML or CSS for that matter). Yes, sometimes in desktop UI you will need to know exact element position/dimensions. That's why in Sciter I've added: 1. element.update(); method, it will force dimensions to be calculated at this moment. 2. element.onSize = function() {...} called when dimensions of the element change. 3. element.paintContent = function(graphics) {} called to paint the element on graphics. Dimensions and position of the element is known at this moment. 4. There is a Graphics.Text object that allows to calculate (not just render) text and glyph positions. My main point with all this: it is a matter of API provided and has nothing with HTML/CSS per se. For that matter, Flutter also uses DOM (tree of widgets, etc.). It is just that its style system is not declarative and misses cascading - for some reasons they decided to use WPF/XAML way of doing business. But we've already sang "Sic transit gloria mundi" to WPF ... For the text editing... check html-notepad : https://html-notepad.com/ https://html-notepad.com/ . Left sidebar (structure outline) is computed and painted in immediate rendering painting mode - when paintContent of the document is invoked.
  - Sophistifunk 6y ago
    When I wrote "DOM" I meant the DOM as in the W3C one you're looking at right now, not Sciter, which I haven't used. Nothing wrong with the concept of trees of objects, other than the fact the tree usually forms part of the objects.
tluyben2 6y ago
The biggest problem I have with html/css is that the outcome seems unpredictable; I sit with very experienced web devs and still have to do trial and error sometimes to know where what will be and of what size. I hear, way to often, when I (backend/embedded dev) ask how to ‘not make X happen’ something like ‘try this or this’ after they check my css. How is that software development if you have to guess how things work? Maybe it is because I am a backend dev, but we have this issue far less with native dev; they just say ‘do this’ and indeed it works as expected.
jbverschoor 6y ago
HTML is for document/flow. Only with flexbox it became kind of usable for "apps". But still, the widgets are not native. You can keep emulating and emulating, but it's very easy to spot and quite frankly super annoying.