Calzini and Updates

[noahgibbs]

For Calzini and Tiranti, we're rendering fine. But there's the small matter of later updates...

Specifically, if a Webview drawable doesn't 100% know how it will be rendered as HTML (e.g. progress bar can be a div or a "progress" tag or likely other things) then it's not necessarily correct for any possible rendering to share the same HTML update code. If Calzini (or other implementations like Tiranti) decide how the widget is rendered, they should also decide how it's updated.

So for Calzini-capable drawables, we'd like to override both the element method and properties_changed. It should also be possible for the drawable to see properties_changed, so it's not that properties_changed can or should go only to Calzini.

This bug report brought to you by the Progress drawable, where the normal HTML generated uses "progress" but Boostrap wants a nested-div thing with slightly different fields, so Calzini and Tiranti will want slightly different update code.

It's also reminding me that the current default -- redrawing the whole DOM -- every time there's an update we don't explicitly handle is probably ridiculously over-conservative. It would pretty certainly make more sense to default to just redraw the one widget.

[noahgibbs]

Another way we could do this would be to auto-wrap a div around anything produced by Calzini (or non-Calzini too?) so that we could cleanly replace it.

[noahgibbs]

The wrap-a-div solution didn't work. Messes up flexbox formatting. But we currently guarantee that the outer element of any drawable matches its HTML ID using a Scarpe-Webview test.

[noahgibbs]

At this point we're only re-rendering the specific drawable that got invalidated. We may want to revisit that eventually, but for now it's great. This doesn't solve the compatibility problem between Calzini and Tiranti and figuring out how to update HTML in smaller-than-drawable chunks. But that's a pretty small problem, much smaller than "stop doing full redraws of the whole DOM tree."