4 ms·

Rendering meaning turning the html elements into dom nodes first before painting. But that's a red herring. The point in that the sequence, render-modify cann

by aatd86 4y ago

Rendering meaning turning the html elements into dom nodes first before painting. But that's a red herring. The point in that the sequence, render-modify cannot be turned into modify-render. This is not commutative. Now, render(a, b, c) where a, b, c are html nodes is a slightly different story because we consider only one function. Here, your claim is that since it is basically equivalent to render(a) + render(b) + render(c) then it's commutable. Well, it depends at which granularity one looks at it (subtrees...). And as the original comment mentions, in the general case, it's only true if there is no side-effects.

valenterry 4y ago
Well, now we are really down to semantics. I don't think there is any guarantees about rendering whatsoever, are there? In other words, if you, currently, put some html elements (whatever that means, maybe using innerHTML or so) is there any guarantee how exactly they are rendered, meaning, how they are turned into dom nodes? Because of not, then render(a, b, c) is in fact equivalent to render(a) + render(b) + render(c). If this process can be controlled, then obviously "inserting" an html element (structure) must be able to describe that process to make it declarative.
- aatd86 4y ago
  The thing is, this is simplistic example. It's not just about pure semantics nitpicking. That render decomposition works for sibling elements. However, when there is a parent child relationship between html elements, the child can only be inserted on an existing parent. Basically, render(a(b)) is not render(ab) where a(b) denotes that the html element a depends on the html element b for its definition.
  - valenterry 4y ago
    > Basically, render(a(b)) is not render(ab) where a(b) denotes that the html element a depends on the html element b for its definition. This is a new example. How does that contradict any of the previous points that I (and the OP) made? I fail to see that, can you explain?

by aatd86 4y ago

valenterry 4y ago

Well, now we are really down to semantics. I don't think there is any guarantees about rendering whatsoever, are there? In other words, if you, currently, put some html elements (whatever that means, maybe using innerHTML or so) is there any guarantee how exactly they are rendered, meaning, how they are turned into dom nodes? Because of not, then render(a, b, c) is in fact equivalent to render(a) + render(b) + render(c). If this process can be controlled, then obviously "inserting" an html element (structure) must be able to describe that process to make it declarative.

aatd86 4y ago
The thing is, this is simplistic example. It's not just about pure semantics nitpicking. That render decomposition works for sibling elements. However, when there is a parent child relationship between html elements, the child can only be inserted on an existing parent. Basically, render(a(b)) is not render(ab) where a(b) denotes that the html element a depends on the html element b for its definition.
- valenterry 4y ago
  > Basically, render(a(b)) is not render(ab) where a(b) denotes that the html element a depends on the html element b for its definition. This is a new example. How does that contradict any of the previous points that I (and the OP) made? I fail to see that, can you explain?