3 ms·

> Most (any?) other UI toolkits give you distinct "canvas" that can be in more-or-less arbitrary relationships to each other. In HTML we call this "position: a

by slver 5y ago

> Most (any?) other UI toolkits give you distinct "canvas" that can be in more-or-less arbitrary relationships to each other. In HTML we call this "position: absolute" and "z-index". > And if that is not enough, they let you drop down to `onPaint` and paint your own stuff. In HTML we call this <canvas>

dmitriid 5y ago
> In HTML we call this "position: absolute" and "z-index". Nope. These don't make "more-or-less arbitrary relationships to each other" easier or more obvious. And they are still fully constrained to the hierarchical 2D-plane of HTML. > In HTML we call this <canvas> Only it's ... not HTML anymore. It's canvas. And yes, the irony is that to make anything custom properly you have to fully exit anything HTML- or CSS-related and use something entirely outside like Canvas or WebGL. In any other world you don't: you stay inside whatever framework you started in.
- slver 5y ago
  > Nope. These don't make "more-or-less arbitrary relationships to each other" easier or more obvious. And they are still fully constrained to the hierarchical 2D-plane of HTML. Your requirement that a system should reflect "arbitrary relationships" is non-sense, sorry to be blunt. Nothing anyone could bring forward as an example from any UI system in the world would satisfy the description of "it makes arbitrary relationships obvious". You should probably use more precise language and examples. Also you're simply wrong about being constrained. Declare your elements fixed (or absolute at root), and you can do whatever you want with them. The document becomes just a retained mode set of disjoint elements. There's no "flow" anymore. > Only it's ... not HTML anymore. It's canvas. And yes, the irony is that to make anything custom properly you have to fully exit anything HTML- or CSS-related and use something entirely outside like Canvas or WebGL. The canvas is literally an HTML element. It can be shown inline, or not, you can pepper your regular content with hundreds of tiny canvasses throughout, or you can make a giant one to take over your entire document. Your choice. It's literally a transparent buffer to draw whatever the f you want in it, and that sits in your document. How much more integrated with HTML do you want it to be? You claim you want to exit the regular HTML flow, and rendering semantics, and when you do, you complain that you've exited the regular HTML flow, and rendering semantics. That's just circular reasoning, you're putting your own requirements in opposition, and blaming HTML for it, which makes no sense. The modern browser stack allows you to opt out or in of most of what it does. It has never been as powerful, to the point that other UI engines are starting to use web technologies as a basis for their own UI stacks (i.e. Scion for ex.). There are many little annoyances, as with anything, but all your complaints are honestly invalid. Or if I'm wrong, at least be specific and don't argue with yourself by painting in broad strokes about what it means to "exit HTML" or "not exit it". State your specific issues, and I'll state a specific solution. So far your specific issue appears to be you're not very familiar with the technologies you're bashing.
  - dmitriid 5y ago
    > Your requirement that a system should reflect "arbitrary relationships" is non-sense, sorry to be blunt. I said "more-or-less arbitrary relationships", and that was a deliberate choice of words. In HTML it's still impossible, or nearly impossible to express an element's size or position in terms of its siblings, or a parent's size and position in terms of its children. > Also you're simply wrong about being constrained. Declare your elements fixed (or absolute at root), and you can do whatever you want with them. Indeed. Only when you literally take the object out of the flow (or emulate that by having absolute at root), can you do some limited things to the object. > You claim you want to exit the regular HTML flow, and rendering semantics, and when you do, you complain that you've exited the regular HTML flow, and rendering semantics. That's just circular reasoning It's not. HTML and CSS are extremely high-level. Canvas is extremely low-level. And there's literally nothing in between. What if I want to take over the rendering of a single table cell? Or, better still, over just items in a select? > It has never been as powerful Powerful? At which point is it at all powerful? > State your specific issues, and I'll state a specific solution. How about: - constraint-based layouts - 60fps animations on actual HTML elements. And by animations I don't mean "only use animations that don't trigger reflows, or you're screwed". Things like "animate a list item being removed from a list" (and you're not allowed to say things like "we know the height of the item beforehand") - customisation of built-in components like selects - almost literally anything from Sencha's/ExtJS' kitchen sink: https://examples.sencha.com/extjs/7.4.0/examples/kitchensink/?modern#all https://examples.sencha.com/extjs/7.4.0/examples/kitchensink... Modular, componentised, customisable. There's a reason every single "css or ui framework" on the web reimplements the same few components over and over (tabs, alerts, maybe selects) and rarely has the manpower to do anything more complex (virtual lists and tables, complex grids, treeviews, etc. Hell, even a calendar is often too big of an undertaking.) Oh yes, some of them can be made at great expense of time and manpower. And some of them have become easier to do (some layouts like grids). But powerful? That's a nice joke.
    - slver 5y ago
      > - constraint-based layouts https://gss.github.io/ https://gss.github.io/ > 60fps animations on actual HTML elements. There are plenty of demos reaching 120fps animations either with CSS, or JS in DOM, or in canvas (with or without WebGL), so this issue doesn't sit. Obviously a cross-platform solution is not as efficient as a platform-specific solution. But it's quite good these days. > Things like "animate a list item being removed from a list" (and you're not allowed to say things like "we know the height of the item beforehand") Look, JS is fully exposed to the DOM, so you don't get to tell me "you're not allowed" about features that the browser allows. We're not arguing whether the imaginary HTML in your head is capable of what you want, we're arguing about whether the real one is. > customisation of built-in components like selects Implemented by your next point: > almost literally anything from Sencha's/ExtJS' kitchen sink Those are libraries that run in a browser. So they count as something the browser can do. Your initial complaint was that we're so constrained that it's "nearly impossible" to do what you want. If Sencha and ExtJS does it, and you can just use it, your argument is invalid. > Oh yes, some of them can be made at great expense of time and manpower. And some of them have become easier to do (some layouts like grids). Uh-huh. So what is your complaint again? That it's too much effort to use this great expense of time and manpower by downloading it with your package manager?

by slver 5y ago

dmitriid 5y ago

> In HTML we call this "position: absolute" and "z-index". Nope. These don't make "more-or-less arbitrary relationships to each other" easier or more obvious. And they are still fully constrained to the hierarchical 2D-plane of HTML. > In HTML we call this <canvas> Only it's ... not HTML anymore. It's canvas. And yes, the irony is that to make anything custom properly you have to fully exit anything HTML- or CSS-related and use something entirely outside like Canvas or WebGL. In any other world you don't: you stay inside whatever framework you started in.

slver 5y ago
> Nope. These don't make "more-or-less arbitrary relationships to each other" easier or more obvious. And they are still fully constrained to the hierarchical 2D-plane of HTML. Your requirement that a system should reflect "arbitrary relationships" is non-sense, sorry to be blunt. Nothing anyone could bring forward as an example from any UI system in the world would satisfy the description of "it makes arbitrary relationships obvious". You should probably use more precise language and examples. Also you're simply wrong about being constrained. Declare your elements fixed (or absolute at root), and you can do whatever you want with them. The document becomes just a retained mode set of disjoint elements. There's no "flow" anymore. > Only it's ... not HTML anymore. It's canvas. And yes, the irony is that to make anything custom properly you have to fully exit anything HTML- or CSS-related and use something entirely outside like Canvas or WebGL. The canvas is literally an HTML element. It can be shown inline, or not, you can pepper your regular content with hundreds of tiny canvasses throughout, or you can make a giant one to take over your entire document. Your choice. It's literally a transparent buffer to draw whatever the f you want in it, and that sits in your document. How much more integrated with HTML do you want it to be? You claim you want to exit the regular HTML flow, and rendering semantics, and when you do, you complain that you've exited the regular HTML flow, and rendering semantics. That's just circular reasoning, you're putting your own requirements in opposition, and blaming HTML for it, which makes no sense. The modern browser stack allows you to opt out or in of most of what it does. It has never been as powerful, to the point that other UI engines are starting to use web technologies as a basis for their own UI stacks (i.e. Scion for ex.). There are many little annoyances, as with anything, but all your complaints are honestly invalid. Or if I'm wrong, at least be specific and don't argue with yourself by painting in broad strokes about what it means to "exit HTML" or "not exit it". State your specific issues, and I'll state a specific solution. So far your specific issue appears to be you're not very familiar with the technologies you're bashing.
- dmitriid 5y ago
  > Your requirement that a system should reflect "arbitrary relationships" is non-sense, sorry to be blunt. I said "more-or-less arbitrary relationships", and that was a deliberate choice of words. In HTML it's still impossible, or nearly impossible to express an element's size or position in terms of its siblings, or a parent's size and position in terms of its children. > Also you're simply wrong about being constrained. Declare your elements fixed (or absolute at root), and you can do whatever you want with them. Indeed. Only when you literally take the object out of the flow (or emulate that by having absolute at root), can you do some limited things to the object. > You claim you want to exit the regular HTML flow, and rendering semantics, and when you do, you complain that you've exited the regular HTML flow, and rendering semantics. That's just circular reasoning It's not. HTML and CSS are extremely high-level. Canvas is extremely low-level. And there's literally nothing in between. What if I want to take over the rendering of a single table cell? Or, better still, over just items in a select? > It has never been as powerful Powerful? At which point is it at all powerful? > State your specific issues, and I'll state a specific solution. How about: - constraint-based layouts - 60fps animations on actual HTML elements. And by animations I don't mean "only use animations that don't trigger reflows, or you're screwed". Things like "animate a list item being removed from a list" (and you're not allowed to say things like "we know the height of the item beforehand") - customisation of built-in components like selects - almost literally anything from Sencha's/ExtJS' kitchen sink: https://examples.sencha.com/extjs/7.4.0/examples/kitchensink/?modern#all https://examples.sencha.com/extjs/7.4.0/examples/kitchensink... Modular, componentised, customisable. There's a reason every single "css or ui framework" on the web reimplements the same few components over and over (tabs, alerts, maybe selects) and rarely has the manpower to do anything more complex (virtual lists and tables, complex grids, treeviews, etc. Hell, even a calendar is often too big of an undertaking.) Oh yes, some of them can be made at great expense of time and manpower. And some of them have become easier to do (some layouts like grids). But powerful? That's a nice joke.
  - slver 5y ago
    > - constraint-based layouts https://gss.github.io/ https://gss.github.io/ > 60fps animations on actual HTML elements. There are plenty of demos reaching 120fps animations either with CSS, or JS in DOM, or in canvas (with or without WebGL), so this issue doesn't sit. Obviously a cross-platform solution is not as efficient as a platform-specific solution. But it's quite good these days. > Things like "animate a list item being removed from a list" (and you're not allowed to say things like "we know the height of the item beforehand") Look, JS is fully exposed to the DOM, so you don't get to tell me "you're not allowed" about features that the browser allows. We're not arguing whether the imaginary HTML in your head is capable of what you want, we're arguing about whether the real one is. > customisation of built-in components like selects Implemented by your next point: > almost literally anything from Sencha's/ExtJS' kitchen sink Those are libraries that run in a browser. So they count as something the browser can do. Your initial complaint was that we're so constrained that it's "nearly impossible" to do what you want. If Sencha and ExtJS does it, and you can just use it, your argument is invalid. > Oh yes, some of them can be made at great expense of time and manpower. And some of them have become easier to do (some layouts like grids). Uh-huh. So what is your complaint again? That it's too much effort to use this great expense of time and manpower by downloading it with your package manager?