As web shows, html is a decent way to build UI. In some ways it's better
than traditional way of building UIs (winforms and similar) and in some
ways worse.

Mozilla's XUL, Microsoft's XAML, DirectUI (https://github.com/kjk/directui)
combine those ideas.

Mui could do as well. There are similarities between DrawInstr and
Control and html's layout proces and mui's layouts.

The big idea is to make html element (i.e. currently DrawInstr) to be
first-class citizen in mui and vice-versa.

Ultimately this should allow e.g. implementing the equivalent of the
toolbar, settings and other dialogs, notifications etc. declaratively 
in html, with only small amount of code to hook up the actions (like
pressing a button) to code.

Implementation-wise, it requiers the following:

1. Having the equivalent of DrawInstr be a part of mui UI element
hierarchy. Following XAML design, we could introduce a lighter-weight
base class UIElement which would have position/size, css style and
whatever it needs to participate in layouts. Control would derive
from that and add the interactive capability.

2. Ability to instantiate arbitrary mui controls from html parser and
bind code to elements. E.g. our 'update available' dialog  could be:

<p>You have version <b>5964</b></p>
<p>New version <b>5972</b> is available. Download new version?</p>
<p><control type=checkbox name=skipcheck>&Skip this version</control></p>
<p align=right>
  <control type=button name=dl>Download</control>
  <control type=button name=nodl>&No, thanks</control>
</p>

// very sketchy syntax, just to illustrate ideas
UIFragment *frag = FragmentFromHtml(gUpdateDialogHtml);
UpdateAvailableController *controller = new UpdateAvailableController(frag);
Button *btnDl = this->frag->FindElement("button", "dl");
btnDl->Connect(controller::OnDownloadPressed);
Button *btnNoDl = frag->FindElement("button", "nodl");
btnNoDl->Connect(controller::OnNoDownloadPressed);

Controller::OnNoDownloadPressed() {
  Checkbox *skipCheck = frag->FindElement("checkbox", "skipcheck");
  if (skipCheck->IsOn()) {
  } else {
    // is off
  }
  // close the dialog
}
RunDialog(frag);
...

2.1. <control type=foo ...></control> serves as an extension point
where html parser calls mui to interpret a given control syntax.
Mui parses until </control> element and when it returns html
parser continues parsing.

This can be further extended to allow non-core elements as well e.g.
if sumatra defines SumatraButton control, it could do:
mui::RegisterParsingForControl("SumatraButton", MuiControlParserFunc *parserFunc);

2.2 Ability to add name and/or id to UIElement and ability to find
elements of a given type/(name/id), like in html's DOM.

2.3 Ability to hook actions to controls in a more loosly way, using
sigslot.h.

----------------------
Even more ratical idea of how to structure mui is to use DrawInstr-like
mechanizm instead of inheritance. Classes/objects are just a  way to
give identity to objects that allows referring to them (for the purpose
of manipulation) at runtime. Html doesn't work that way and instead
uses names/ids/DOM traversal to refer to ui elements and uses
a fixed number of events that apply to each element.
There are practical issues in that e.g. implementing a rounded border
(and other sophisticated painting) for a Button is easier via custom
paint function than by adding such capability in generic way.
-----------------------

 