You want to draw two disjoint circles and a line connecting their centers.
Now the geometric relation is a simple graph. But in HTML/CSS you likely have to use an invisible parent that these objects relate to and maybe a few other tricks. You’re not expressing this directly anymore, but kind of have to traverse around tree nodes so to say.
It can even be worse if those objects are laid atop of others, and things are switching on the Z axis. You’re now breaking the structure or rather changing it constantly. The parent-child relationship often feels forced.
Designers seem to think of UIs more of an open canvas, typically as a layered grid (a fine grid of single digit pixels) where the objects have arbitrary relations to eachother and the grid. The canvas itself is sometimes the only “parent”.
Or even simpler: you have two objects in different containers, but with the same margin to appear aligned. What you’re trying to express is their alignment and not their relation to their “parent” which might be very well invisible.
> You want to draw two disjoint circles and a line connecting their centers.
I wouldn't say two circles connected by a line is very useful in UI to be honest.
Such relationships are more commonly seen in animation software, modeling software, engineering software and games, 2D or 3D, where such relationships are explicitly expressed by scripting or specialized binding systems (like inverse kinematics). The general metaphor for such software is not a tree, not a graph either, but rather a set, upon which set operate a set of systems (like physics and AI etc.).
But all of those things sit, in my mind, distinctly apart from what UI is. And the distinction between UI and just "things on a computer" is that UI is entirely artificial and made for the purpose of conversing with the user, rather that representing or simulating existing phenomena, natural etc. So UI does NOT have to be arbitrary. But it HAS to be easy to comprehend. That is its purpose.
The only place I've seen this used in UI I can recall is Reason (audio software), where you can flip your rack of modules, and connect inputs and outputs with wires. It's quite gimmicky and becomes a mess (just like real cable management does), so I think this also informs us how well arbitrary graphs look on screen. They don't help and become unintelligible at scale.
While a clean hierarchy tends to stay clean, so it's useful in UI where we control our metaphors and optimize them for comprehensibility.
> It can even be worse if those objects are laid atop of others, and things are switching on the Z axis. You’re now breaking the structure or rather changing it constantly. The parent-child relationship often feels forced.
I'm sorry that's a bit abstract, can you provide an example again? You see, a list has a clear enumeration order, you can make the first or last item be "on top". A tree also has a clear traversal.
A graph has no clear traversal order at all, so how would a graph help you at all figuring out z-index for your UI?
If anything, having your UI as a graph would take away the common-sense approach to rendering order which allows you to NOT assign a z-index to literally every element. I've had to deal with such problems, and trust me, you don't want to have that problem. The tree is a friend.
> Or even simpler: you have two objects in different containers, but with the same margin to appear aligned. What you’re trying to express is their alignment and not their relation to their “parent” which might be very well invisible.
A visual example would help. The "parent" exists to provide a transform reference as much as anything else. So it's unclear why you wouldn't use a parent for the purpose it exists, only to eventually do the exact same thing.
> I wouldn't say two circles connected by a line is very useful in UI to be honest.
It is when you think that you can't reliably animate or reposition anything in HTML if it causes a reflow.
Most (any?) other UI toolkits give you distinct "canvas" that can be in more-or-less arbitrary relationships to each other. And if that is not enough, they let you drop down to `onPaint` and paint your own stuff.
HTML+CSS force you into a rigid tree laid out on a rigid 2D-plane. Because at their core they have always been just a tool to (somewhat badly) render text and some images. All the other things we force into/onto them play very badly with this concept.
> 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.
> 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.
> 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... 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).
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?
Yup. Not native to the web, and IIRC jundreds of kilobytes of JS
> 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.
Yup. "If I close my eyes, the problem will go away". Also, "if I ignore the actual content of the complaint, it will go away".
Because demos are just that: demos.
> Look, JS is fully exposed to the DOM
Ah yes. Suddenly it's no longer HTML and CSS, now we're bringing JS into the fold.
Do you know what it takes to actually properly animate what I requested?
> Implemented by your next point:
Ah, yes.
How it started: HTML is so powerful!
How it's going: Oh, look, all you have to do is spend thousands of man hours and write megabytes of Javascript to achieve what's available in other not-so-powerful UI kits.
Don't forget, what you implement will require orders of magnitudes more resources to run on what's essentially a supercomputer than almost literally anything else.
> 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.
I can also implement a web server in Brainfuck. Does it mean that Brainfuck is powerful and any complaints about it are invalid?
> That it's too much effort to use this great expense of time and manpower by downloading it with your package manager?
That things that are available out of the box almost literally everywhere else are actually incaccessibly to those who can't spend the effort on reimplementing them, from scratch, every single time.
There's a reason why Sencha costs $1295 per developer and even smaller projects like handsontable easily charge hundreds of dollars for their use. I mean, for things that are either available out of the box everywhere else, or are rather trivial to implement, once again, everywhere else.
You started complaining that all you want it is the ability to have custom layout & drawing logic and HTML doesn't let you escape the tree.
And currently you've given up this entire premise, and you're on a loop whining about how FOSS and professional UI libraries that have custom layout & drawing logic, which WORKS JUST FINE IN EVERY BROWSER take hundreds of kb (which is nothing) and some of them cost money (which is absolutely irrelevant).
You wanted to express "arbitrary relationships". This requires libraries implementing "arbitrary logic" with access to the presentation layer. You got it. Now you're whining about the fact these libraries exist.
Ok. Let's be very coherent. Let's talk about one single thing.
Not so long ago Twitter redesigned their website. Mind you, Twitter is far from being a complex app UI-wise. It's basically text plus images. All they did was re-implement infinite scrolling using a well-known paradigm called a virtual list (or a virtual table).
Note: I implemented a similar functionality in C++ Builder circa 2004 and in Qt circa 2005. This entire functionality is either available right out of the box, or will take a first-year CS student a day or two to implement by following a simple tutorial (because virtual lists are a thing available in all UI kits since probable early 80s).
It took Twitter close to a year to fix this functionality.
Now, tell me: why is it that such a powerful platform:
a) doesn't have this functionality out of the box
b) requires a company the size of Twitter almost a year to implement somewhat satisfactorily
c) why didn't Twitter just "go ahead and download a package" that implements this trivial primitive functionality that is so readily available, once again, everywhere else.
From here on we can discuss all the other trivial and primitive things that require you to depend on someone to spend untold man-powers to implement them in the "so powerful a platform".
And from there on we can move on to discussing why these trivial and primitive things require orders of magnitudes more resources to run to do a fraction of a fraction of the things available, you know, everywhere else.
How's that for coherency?
Edit: In a comment elsewhere I actually linked to a nice example. The Web is such a powerful platform that you can't even animate shadows without thinking hard and long about causing page repaints: https://tobiasahlin.com/blog/how-to-animate-box-shadow/ MacOS did shadows almost 20 years ago on hardware that's probably 100 times less powerful than now.
So an app had a bug and almost a year later they fixed it.
You're right. This scenario never happened outside the web. /s
Partial rendering of lists/tables is trivial when the items are not dependent on one another (flow) or you have fixed or easy to compute height (assuming vertical scroll). When that height is determined by thousands of variables, bugs can happen, and what platform you use doesn't matter. But I suspect Twitter's issue is elsewhere entirely and both you and I are forced to speculate POINTLESSLY I MIGHT ADD, on a fixed bug we can't debug the cause of.
And saying Twitter is "just text and images" is both terrible oversimplification (it has text in multiple styles, also videos, polls, retweet panels, info cards etc. etc. etc.), and just sounds ignorant. "Just text"? Do you have a clue how varied and complicated multilingual Unicode is at all, not to mention mixed RTL and LTR and so on. You get to say "just text" if you're rendering the visible range of ASCII in a monospace font only.
You did it more easily in your toy scenario most likely because your toy scenario had LESS complexity, not because HTML has less capability. You see, there's a reason why people often embed HTML in their apps to show so-called "rich text" in it. It's something that's not trivial to achieve at all in your typical UI kit (beyond basics like color, font-family and size).
And unfortunately your coherency remains low, as you're still arguing about things that have nothing to do with your initial thesis that HTML doesn't allow you to do what you want.
If HTML has a problem, is that it does too much, not too little. If you take Qt "circa 2005" and try to replicate the exact visual presentation of Twitter.com you'd quickly realize how much HTML gives you that Qt wouldn't. In fact, Qt's own rich text support is a tiny, tiny subset of HTML.
Oh, by the way, you don't get to use Qt. You only get to use whatever comes with your OS, because BY YOUR OWN STANDARDS you're very filesize conscious, and "hundreds of kilobytes" was too much for a UI library to use in your web app. Well Qt is several megabytes.
You forgot you were whining about kilobytes, right. Low coherence.
> So an app had a bug... terrible oversimplification... your toy scenario...
Life is so easy when you bury your head in the sand and pretend problems don't exist.
> trivial when the items are not dependent on one another (flow) or you have fixed or easy to compute height
Funny how "so powerful a platform" makes this "trivial and easy" only if you babysit it and give it rigid fixed dimensions.
> because BY YOUR OWN STANDARDS you're very filesize conscious, and "hundreds of kilobytes" was too much for a UI library
A modern browser is about 10 million lines of code, give or take. That's ~20% of the entirety of Windows 10. That's the size of Windows NT, and only slightly smaller than the size of Android.
And this "powerful system" still can't display more than very primitive UI elements, and needs additional megabytes of code to do the most trivial of UI things.
Oh, and it requires magnitudes more resources to display all that, and needs ridiculous things like "oh you must have fixed height" to do the most trivial of things.
But sure, to you it's "so powerful". That betrays your ignorance, and I'm tired of this conversation.
> Funny how "so powerful a platform" makes this "trivial and easy" only if you babysit it and give it rigid fixed dimensions.
That's how math works, dude. You can't render something at an offset defined by the previous items, without knowing their dimensions. HTML didn't do that. Reality did that.
> But sure, to you it's "so powerful". That betrays your ignorance, and I'm tired of this conversation.
We'll always have relationships on top of (and independent of) the tree. I think we shouldn't underestimate what the tree gives us. I.e. in small fraction of cases the tree is maybe a hindrance. But if that hindrance doesn't go away but multiplies without the tree, our hindrance is likely coming from the complexity of our problem, rather than from the tree.
By the way notice the tree keeps reoccurring in other case of interfaces:
- All computer languages are code, which expresses a set of nested statements and expressions (which form a syntax tree).
- While XML was replaced with JSON for data exchange, that's also a tree, not a graph (some implementations exist to describe a graph, but I'd argue that doesn't help serialization etc. concerns).
There's something about a tree that makes it very suitable both for computer and human comprehension.
OF COURSE, all those trees end up describing graphs. Say our "syntax tree" at runtime is an object graph and so on. But it's notable that we describe that object graph by encoding it into a tree of rules.
Now the geometric relation is a simple graph. But in HTML/CSS you likely have to use an invisible parent that these objects relate to and maybe a few other tricks. You’re not expressing this directly anymore, but kind of have to traverse around tree nodes so to say.
It can even be worse if those objects are laid atop of others, and things are switching on the Z axis. You’re now breaking the structure or rather changing it constantly. The parent-child relationship often feels forced.
Designers seem to think of UIs more of an open canvas, typically as a layered grid (a fine grid of single digit pixels) where the objects have arbitrary relations to eachother and the grid. The canvas itself is sometimes the only “parent”.
Or even simpler: you have two objects in different containers, but with the same margin to appear aligned. What you’re trying to express is their alignment and not their relation to their “parent” which might be very well invisible.