3 ms·

If to speak about browser technology as a GUI toolkit then there are three big things that are greatly underestimated. 1. Bubbling/Sinking(Capturing) event pro

If to speak about browser technology as a GUI toolkit then there are three big things that are greatly underestimated. 1. Bubbling/Sinking(Capturing) event propagation schema. With that schema a container knows what event is passed to a child and did child process it or not. On desktop, windowed widget handles all its events without notifying/asking its container. This actually is pretty big - it enables composition of atomic input widgets. On Web you can use <input|text> as part of more complex widget. 2. CSS and CSS selectors in particular. As the way of styling component from outside - independently from its event handlers/code. So code changes DOM state and CSS defines how that state shall be presented. And not only that but styling of elements in context (cascading). That is "separation of concerns" at its best. 3. And the DOM. While each UI system has DOM ( tree of windows/widgets ) in one form or another the Web pushes its further: it adds unification of widget (attributes/states) interface. Any widget or element may have ID, class or other attributes defined. And those can be used for styling.

admax88q 7y ago
In practice CSS rarely lives up to the aeparation between state and presentation. In most projects the to are updated in tandem. DOM is not expressive enough to represent state, it moreso represents UI state, but CSS also represents UI state.
- c-smile 7y ago
  That is more about architecture actually. Ideally Web/UI component has two sets of styles: So called "primordial" or "base" - the one that defines layout of sub-components and parts and that is essential for component operation. And another set is about decoration - colors, fonts, sizes. For example in Sciter (https://sciter.com https://sciter.com) component is defined by so called style sets: @set nullable-input-base { :root { flow:horizontal; } :root > input { display:block; width:*; } :root > button.clear { display:block; } } // concrete nullable-input styling: // derives from nullable-input-base @set nullable-input < nullable-input-base { :root { background-color: var(inputback) } :root > button.clear { width:2em; background: url(x-cross.svg) 50% 50% no-repeat; } } And in script: class NullableInput : Reactor.Component { const styleset = ["nullable-input", url("widgets.css") ]; function render() { return <widget.nullable-input> <input|text /> <button.clear /> </widget>; } } This way you can redefine nullable-input in the way you want without putting any styles into code.
thu2111 7y ago
Some GUI toolkits have adopted these patterns. In JavaFX events bubble/capture in the same way as on the web. JavaFX has CSS which styles its equivalent of the DOM (the scene graph). User defined components can extend CSS if they want. JavaFX nodes can all be styled with style/styleClass attributes. But the JavaFX DOM is superior to the web DOM: it has layout management nodes, every property is observable and bindable in a unified manner, and there's a more principled approach to handling collections.
- c-smile 7y ago
  Everything that you can do in JavaFX you can do in WWW platform too and with surprisingly small set of features. > every property is observable and bindable in a unified manner Yep, see: https://developer.mozilla.org/en-US/docs/Web/API/MutationObserver https://developer.mozilla.org/en-US/docs/Web/API/MutationObs... In Sciter I went even further, in CSS there you can define widget { prototype: MyWidget url(widgets/mine.tis); ... } widget[mode="editable"] { prototype: MyEditableWidget url(widgets/mine.tis); ... } and so to have dynamic subclassing of the same DOM element: depending on attribute value the same DOM subtree element may have different classes - controllers. Good luck with that in Java.
  - pjmlp 7y ago
    Easy, because in Java I have the complete graphics stack at my control, so I can extend the nodes programmatically and even ensure that hardware accelerated rendering takes indeed place without Z layer tricks and hope for the best. While with CSS, when was Houdini supposed to be available actually?
  - thu2111 7y ago
    Why would you do that rather than just bind the editable property to something though? I don't actually see CSS the language as anything to be especially proud of, although the borders/box/cascade design can be useful. Great that the DOM API got this basic thing at some point. Now how do you define observable properties on non-DOM objects? The whole thing is just a pile of special case hacks really.
ridiculous_fish 7y ago
GUI toolkits certainly allow for containers to act on events before their children. For example sendEvent: and hitTest: in Cocoa. The web's event handling is comparatively clumsy. It is cast in terms of "listeners" which are unable to directly control the event routing. Instead it exposes fixed, ad-hoc levers: stopPropagation, stopImmediatePropagation, preventDefault, etc. And because there's no good place to put these methods, they have to go on the event itself, which means that events are mutable (!).
- c-smile 7y ago
  "sendEvent: and hitTest: in Cocoa" That is cooperative event propagation. Means it works only when widget cooperates by itself - designed to be embeddable and expandable - so it notifies its container about events inside. Example: try to catch right mouse button click on NSButton instance. Good luck with this. "clumsy" I wouldn't say so. I am doing UIs professionally quite a long time and can prove that WWW's Event/Sinking event propagation + ability to subscribe to event by JS closures is the most flexible schema so far. It is a functional superset of events handling architectures of Windows and any toolkit there, MacOS/Cocoa, GTK and QT.

admax88q 7y ago

In practice CSS rarely lives up to the aeparation between state and presentation. In most projects the to are updated in tandem. DOM is not expressive enough to represent state, it moreso represents UI state, but CSS also represents UI state.

c-smile 7y ago
That is more about architecture actually. Ideally Web/UI component has two sets of styles: So called "primordial" or "base" - the one that defines layout of sub-components and parts and that is essential for component operation. And another set is about decoration - colors, fonts, sizes. For example in Sciter (https://sciter.com https://sciter.com) component is defined by so called style sets: @set nullable-input-base { :root { flow:horizontal; } :root > input { display:block; width:*; } :root > button.clear { display:block; } } // concrete nullable-input styling: // derives from nullable-input-base @set nullable-input < nullable-input-base { :root { background-color: var(inputback) } :root > button.clear { width:2em; background: url(x-cross.svg) 50% 50% no-repeat; } } And in script: class NullableInput : Reactor.Component { const styleset = ["nullable-input", url("widgets.css") ]; function render() { return <widget.nullable-input> <input|text /> <button.clear /> </widget>; } } This way you can redefine nullable-input in the way you want without putting any styles into code.

thu2111 7y ago

Some GUI toolkits have adopted these patterns. In JavaFX events bubble/capture in the same way as on the web. JavaFX has CSS which styles its equivalent of the DOM (the scene graph). User defined components can extend CSS if they want. JavaFX nodes can all be styled with style/styleClass attributes. But the JavaFX DOM is superior to the web DOM: it has layout management nodes, every property is observable and bindable in a unified manner, and there's a more principled approach to handling collections.

c-smile 7y ago
Everything that you can do in JavaFX you can do in WWW platform too and with surprisingly small set of features. > every property is observable and bindable in a unified manner Yep, see: https://developer.mozilla.org/en-US/docs/Web/API/MutationObserver https://developer.mozilla.org/en-US/docs/Web/API/MutationObs... In Sciter I went even further, in CSS there you can define widget { prototype: MyWidget url(widgets/mine.tis); ... } widget[mode="editable"] { prototype: MyEditableWidget url(widgets/mine.tis); ... } and so to have dynamic subclassing of the same DOM element: depending on attribute value the same DOM subtree element may have different classes - controllers. Good luck with that in Java.
- pjmlp 7y ago
  Easy, because in Java I have the complete graphics stack at my control, so I can extend the nodes programmatically and even ensure that hardware accelerated rendering takes indeed place without Z layer tricks and hope for the best. While with CSS, when was Houdini supposed to be available actually?
- thu2111 7y ago
  Why would you do that rather than just bind the editable property to something though? I don't actually see CSS the language as anything to be especially proud of, although the borders/box/cascade design can be useful. Great that the DOM API got this basic thing at some point. Now how do you define observable properties on non-DOM objects? The whole thing is just a pile of special case hacks really.

ridiculous_fish 7y ago

GUI toolkits certainly allow for containers to act on events before their children. For example sendEvent: and hitTest: in Cocoa. The web's event handling is comparatively clumsy. It is cast in terms of "listeners" which are unable to directly control the event routing. Instead it exposes fixed, ad-hoc levers: stopPropagation, stopImmediatePropagation, preventDefault, etc. And because there's no good place to put these methods, they have to go on the event itself, which means that events are mutable (!).

c-smile 7y ago
"sendEvent: and hitTest: in Cocoa" That is cooperative event propagation. Means it works only when widget cooperates by itself - designed to be embeddable and expandable - so it notifies its container about events inside. Example: try to catch right mouse button click on NSButton instance. Good luck with this. "clumsy" I wouldn't say so. I am doing UIs professionally quite a long time and can prove that WWW's Event/Sinking event propagation + ability to subscribe to event by JS closures is the most flexible schema so far. It is a functional superset of events handling architectures of Windows and any toolkit there, MacOS/Cocoa, GTK and QT.