That's cool. I'd be interested to see your code if you ever run across it again.
Part of the purpose of Emerj is to actually avoid overwriting the current .value of inputs -- the idea is to preserve current element state that isn't represented explicitly in the DOM, so you don't delete something the user has just typed in (or <select>ed or whatever).
I haven't run into issues with classes or types or tables, though. I could imagine the implicit tbody potentially causing problems if you generate a DOM structure yourself without one, but in my case this doesn't matter because I use the browser to parse my HTML into a DOM, and it'll add a tbody.
Nanomorph has code to update live input values from the `value=` attribute, but that's actually something I've deliberately avoided for the above reason.
gchpaco, could you give an example of a situation where you'd use a real dependency engine, which could not be solved (at least not easily) by using fabricate.py? I know such cases exist in theory, but have never run across a need, so I'm interested.
Part of the purpose of Emerj is to actually avoid overwriting the current .value of inputs -- the idea is to preserve current element state that isn't represented explicitly in the DOM, so you don't delete something the user has just typed in (or <select>ed or whatever).
I haven't run into issues with classes or types or tables, though. I could imagine the implicit tbody potentially causing problems if you generate a DOM structure yourself without one, but in my case this doesn't matter because I use the browser to parse my HTML into a DOM, and it'll add a tbody.
Nanomorph has code to update live input values from the `value=` attribute, but that's actually something I've deliberately avoided for the above reason.