HTML Group Layout

[ShaMan123]

Currently Group layout is too complicated.
I just saw something that made me think - what if we borrow the concept behind hiddenTextarea and let the browser do all the hard work?
What if we use the DOM to layout the objects in a group using a div for each group containing divs for each object.
Then the dev can use css properties to layout the objects and we measure the output and apply it back to the group.
This has 2 great advantages:

1. The DOM does all the heavy work and fabric becomes leaner, less bugs to fix or features to add
2. CSS layout is a standard
3. This concept can be used for canvas layout as well and make positioning more intuitive

[iocoker]

Yeah, makes a lot of sense, we did build a calendar object extending Group and it's quite heavy. I could imagine if the layout was handled with native html Grid or Flexbox

[ShaMan123]

OMG 🤯🤯🤯🤯🤯🤯🤯🤯🤯🤯🤯🤯🤯🤯🤯🤯🤯🤯🤯🤯🤯🤯🤯🤯🤯🤯🤯🤯🤯🤯🤯🤯🤯🤯🤯🤯

This is amazing!
WOWWWWWWW!

Well done!
I can only say I am sorry that I didn't design the layout mechanism good enough. I understand how painful it was building this.
Please see this comment as well, I would like to hear your thoughts.

I believe we 2 (and another whom I know @ebigtm) are the only devs who handled such elaborate groups in fabric.

[ShaMan123]

I now think that both topics are related and solvable with this approach

[ebigtm]

@ShaMan123 sounds perfect, but how will it work? each object will be represented by a proxy div with the same size? wont it be heavy?

[ShaMan123]

Yes, that is the concept
I don't know if it will be heavy, don't think so.
But less than what we have currently, for sure

[ebigtm]

I truly don’t see any reason why not to do it, very a simple solution that solves it all
we can even populate a property holding the html and css for that.

great Idea!!!

There are two things to consider, at list for my use case:

1. We should lose the free form positioning (absolute?.
2. There are some advanced concepts like flex order and grid areas that will be a bit more difficult to get done.

[jiayihu]

Why not using the CSS layout engine built in https://github.com/niklasvh/html2canvas then? I think the latency from a JS-made CSS engine is smaller compared to updating the DOM, then reading the values. In the full HTML case you need for the wait all the CSS rendering phases and you also trigger them: https://cabulous.medium.com/how-does-browser-work-in-2019-part-iii-rendering-phase-i-850c8935958f. Like continuously triggering the CSS layouting can be expensive, that's why for instance CSS animations use properties like transform that don't cause recalculating the layout.

[ShaMan123]

Like continuously triggering the CSS layouting can be expensive, that's why for instance CSS animations use properties like transform that don't cause recalculating the layout.

That is also correct is current fabric.
Canvas is suited for transform. Changing width of object is expensive.
So it is up to the dev IMO.

[ShaMan123]

If you put everything in an iframe with display none will that solve your concerns? Will that output what is needed?
IMO it is safer to relay on web standards and not on another repo that replicates web standards.

[jiayihu]

If you put everything in an iframe with display none will that solve your concerns? Will that output what is needed?

Will it work though? For instance, IIRC display: none HTML elements cannot have width, height animatable. Will layouting work? You can make a POC and see if it can update the layout on the canvas at 60fps, e.g. to simulate resizing the above calendar and recomputing the layout on the fly.

[ebigtm]

If I recall correctly, html2canvas just outputs andimage to the canvas, it’s pretty expensive and static, each iteration needs to be rendered to a massive image, this is similar to the way we do it with our solution for now but far from being ultimate

[jiayihu]

html2canvas just outputs andimage to the canvas

I mean just using the CSS layout engine implementation in it, not the whole library