7 ms·

UI is a tree in general. Even when you render a graph, that is just a list of nodes and edges in your ui. What would be the purpose of a graph?

by slver 5y ago

blacktriangle 5y ago
To access elements outside of the tree structure. You can even watch HTML moving in this direction. Forms are a great example. It used to be that the form element would group related input controls. However that now meant that you were stuck linking layout and a form together. The for attribute on input has made HTML forms less tree and more graph-like since you can link input elements to a form outside of the tree.
- slver 5y ago
  The problem with forms is that they combine presentation with business logic. In any decent architecture, your UI has no business directly encoding API requests and directly submitting them to the server. But of course, this was necessary in the early "thin client" days of HTML, before we had a well-developed client-side platform to encode client-side concerns independently of their presentation. Case in point I rarely use <form> elements at all in my applications. I use form controls, of course. But all form data is collected, transformed in a FormData instance and sent via XHR. This is infinitely better and provides great opportunities for UI component reuse independent of what your server-side API shape happens to be. It also means no more "hidden inputs". Which is non-sense if you think about it. If the user can't edit it, or even just see it, what is it doing in the HTML form? Again, in the 90s it made sense. In 2020 it makes no sense. HTML today is UI even more than it ever was. That's good. And UI is a tree, because it's a visual hierarchy. And that's all your need. HTML is not your entire application. And the rest of your application is already a graph.
  - blacktriangle 5y ago
    But the for attribute now gives us the best of both worlds. I still use form tags, but always make them close immediately are style them to not display. This preserves functionality without JS while also separating business logic and display. EDIT: I don't know why you're being downvoted, I get what you're saying. For example encoding the form URL in the HTML is a violation of separating business logic and display since you may want the submittal link to be dynamic based on the values in the form, and using JS to update the form action attribute doesn't really solve anything, but I feel like using for is a pragmatic compromise between the reality and history of HTML and a more ideal architecture.
    - slver 5y ago
      HTML has a few kludges here and there that seem questionable on close inspection. Sure, having the "id" attribute and then referring to this id from anywhere else allows you to build an arbitrary directed graph of relationships independent of the DOM tree. And that's useful in CSS selectors and from JS and so on. Within HTML itself, the "for" attribute on a label has two behaviors... One is to read out the label for a given input for visually impaired users, and the other is to focus the input when you click the label. The focus behavior is kinda useless, most people click the input, not the label. But OK, it's harmless, and nice to have. The accessibility feature makes more sense but also highlights the fact that a control and its label are intrinsically one unit. And in many UI frameworks they are one unit. So why aren't they in HTML? Because INPUT existed in HTML far before accessibility was a concern, and people were writing out labels outside the inputs. So later versions of HTML had to deal with the status quo, and added LABEL to "patch" the problem without disrupting the existing form control behavior. So this particular case is a historical quirk. Would HTML be redesigned, the label would be in the input, and you'd probably be styling it with a pseudo-selector, like you do :placeholder etc.
dgb23 5y ago
A UI is generally not a tree. That’s just how we force ourselves to think of it. Take how data flows through a template or react components for example. The general case is that two parts display some aspects of a data source, while their structural relation to the tree is accidental or forced by layout rather than their data relation. Or from a purely UI centric perspective you might have situations where one part has a geometric dependency of another, which may or may not be expressed by the tree/document structure. What you’re actually doing is translating geometric layout requirements or rather constraints to a tree, because that’s what happens to be your compilation target.
- slver 5y ago
  This is a thread about CSS and HTML. We're talking strictly UI and presentation. Your argument is that data dependencies and other non-UI and non-presentational aspects are not a tree. They're not. But all I said is that your UI is always a tree. And I see no examples pointing otherwise.
  - dgb23 5y ago
    As a pointer for further investigation: One of the big challenges of teaching coding to designers I face is the mental shift from thinking about UI as an open canvas with arbitrary geometric constraints to thinking of them as a tree structure. When implementing bespoke interfaces I very often have to do this translation in my head. You’re right that the common case is a tree, or can easily be translated to one. But it’s not the general case.
    - slver 5y ago
      Well this is why I am asking about examples where it's not the case. And still looking forward to some.
      - dgb23 5y ago
        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.

UI is a tree in general. Even when you render a graph, that is just a list of nodes and edges in your ui. What would be the purpose of a graph?

by slver 5y ago

UI is a tree in general. Even when you render a graph, that is just a list of nodes and edges in your ui. What would be the purpose of a graph?

blacktriangle 5y ago

To access elements outside of the tree structure. You can even watch HTML moving in this direction. Forms are a great example. It used to be that the form element would group related input controls. However that now meant that you were stuck linking layout and a form together. The for attribute on input has made HTML forms less tree and more graph-like since you can link input elements to a form outside of the tree.

slver 5y ago
The problem with forms is that they combine presentation with business logic. In any decent architecture, your UI has no business directly encoding API requests and directly submitting them to the server. But of course, this was necessary in the early "thin client" days of HTML, before we had a well-developed client-side platform to encode client-side concerns independently of their presentation. Case in point I rarely use <form> elements at all in my applications. I use form controls, of course. But all form data is collected, transformed in a FormData instance and sent via XHR. This is infinitely better and provides great opportunities for UI component reuse independent of what your server-side API shape happens to be. It also means no more "hidden inputs". Which is non-sense if you think about it. If the user can't edit it, or even just see it, what is it doing in the HTML form? Again, in the 90s it made sense. In 2020 it makes no sense. HTML today is UI even more than it ever was. That's good. And UI is a tree, because it's a visual hierarchy. And that's all your need. HTML is not your entire application. And the rest of your application is already a graph.
- blacktriangle 5y ago
  But the for attribute now gives us the best of both worlds. I still use form tags, but always make them close immediately are style them to not display. This preserves functionality without JS while also separating business logic and display. EDIT: I don't know why you're being downvoted, I get what you're saying. For example encoding the form URL in the HTML is a violation of separating business logic and display since you may want the submittal link to be dynamic based on the values in the form, and using JS to update the form action attribute doesn't really solve anything, but I feel like using for is a pragmatic compromise between the reality and history of HTML and a more ideal architecture.
  - slver 5y ago
    HTML has a few kludges here and there that seem questionable on close inspection. Sure, having the "id" attribute and then referring to this id from anywhere else allows you to build an arbitrary directed graph of relationships independent of the DOM tree. And that's useful in CSS selectors and from JS and so on. Within HTML itself, the "for" attribute on a label has two behaviors... One is to read out the label for a given input for visually impaired users, and the other is to focus the input when you click the label. The focus behavior is kinda useless, most people click the input, not the label. But OK, it's harmless, and nice to have. The accessibility feature makes more sense but also highlights the fact that a control and its label are intrinsically one unit. And in many UI frameworks they are one unit. So why aren't they in HTML? Because INPUT existed in HTML far before accessibility was a concern, and people were writing out labels outside the inputs. So later versions of HTML had to deal with the status quo, and added LABEL to "patch" the problem without disrupting the existing form control behavior. So this particular case is a historical quirk. Would HTML be redesigned, the label would be in the input, and you'd probably be styling it with a pseudo-selector, like you do :placeholder etc.

dgb23 5y ago

A UI is generally not a tree. That’s just how we force ourselves to think of it. Take how data flows through a template or react components for example. The general case is that two parts display some aspects of a data source, while their structural relation to the tree is accidental or forced by layout rather than their data relation. Or from a purely UI centric perspective you might have situations where one part has a geometric dependency of another, which may or may not be expressed by the tree/document structure. What you’re actually doing is translating geometric layout requirements or rather constraints to a tree, because that’s what happens to be your compilation target.

slver 5y ago
This is a thread about CSS and HTML. We're talking strictly UI and presentation. Your argument is that data dependencies and other non-UI and non-presentational aspects are not a tree. They're not. But all I said is that your UI is always a tree. And I see no examples pointing otherwise.
- dgb23 5y ago
  As a pointer for further investigation: One of the big challenges of teaching coding to designers I face is the mental shift from thinking about UI as an open canvas with arbitrary geometric constraints to thinking of them as a tree structure. When implementing bespoke interfaces I very often have to do this translation in my head. You’re right that the common case is a tree, or can easily be translated to one. But it’s not the general case.
  - slver 5y ago
    Well this is why I am asking about examples where it's not the case. And still looking forward to some.
    - dgb23 5y ago
      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.