Graphics.Element vs elm-html

[Vagmi Mudumbai]

Hi,

I really like the idea of Graphic.Element's and Graphic.Collage's approach towards laying out elements programmatically than declaratively specifying layouts with CSS. But elm-html and the recent developments are oriented more towards the HTML/CSS way of laying out things but they do bring the awesomeness of virtual DOM. 

I understand that there is fromElement and toElement in elm-html. But it feels that Graphics.Element lives in a higher level of abstraction than elm-html. It should be theoretically be possible to build Graphics.Element on top of elm-html with divs and style attributes. Is a rewrite of Graphics.Element on top of elm-html a part of the roadmap? Or is there something else that is planned to give the same sort of layout capabilities with elm-html without having to deal with CSS and flex box? 

Regards,

Vagmi

[John Mayer]

Yes, but the project needs volunteers.

--
You received this message because you are subscribed to the Google Groups "Elm Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elm-discuss...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Rehno Lindeque]

I am also working on something half-way with https://github.com/circuithub/elm-html-shorthand which helps abstract away some of the details when working with input fields etc. Sadly I haven't published a new version yet - it has changed quite a lot. I think that over time we should be able to build up the same level of abstraction in the present Graphics.Element from lower-level Html constructs.

[Laszlo Pandy]

While it would be technically interesting, I don't know if there are too many end-user advantages to rewriting Elements using elm-html. Elements has it's own kind of virtual dom internally. It was invented before React and Mercury's virtual dom, and maybe there are things to learn from that. But fundamentally it already uses the same technique internally.

--