Currently, when html5.Widget.hide() or html5.Widget.show() is used, the display-state is changed as inline-CSS.
This is not wanted in a pure ignire/flare setup, where only a CSS-class "is-hidden" should be added, but may be wanted in a setup without using ignite as CSS. The html5 library on its own should be usable out-of-the-box without having to use pre-defined CSS-classes.
Because html5.Widget is the ultimate base class of ALL HTML-Widgets, we cannot directly subclass it in flare, so we have 3 options:
a) Hard-code the "is-hidden" class into html5.Widget.hide(), html5.Widget.show(), html5.Widget.isHidden()
b) Monkey patch html5.Widget.hide(), html5.Widget.show(), html5.Widget.isHidden() inside flare
c) Make the behavior configurable via flare.conf. This one would have much unnecessary runtime overhead to check for and add or remove various classes, or fallback to the inline style.
After a short discussion, we firstly ended up to resolve it by option b), monkey patching. This issue, anyway, shall stay open for maybe a later discussion or change on it.
Currently, when
html5.Widget.hide()
orhtml5.Widget.show()
is used, the display-state is changed as inline-CSS. This is not wanted in a pure ignire/flare setup, where only a CSS-class "is-hidden" should be added, but may be wanted in a setup without using ignite as CSS. The html5 library on its own should be usable out-of-the-box without having to use pre-defined CSS-classes.Because html5.Widget is the ultimate base class of ALL HTML-Widgets, we cannot directly subclass it in flare, so we have 3 options:
a) Hard-code the "is-hidden" class into
html5.Widget.hide()
,html5.Widget.show()
,html5.Widget.isHidden()
b) Monkey patchhtml5.Widget.hide()
,html5.Widget.show()
,html5.Widget.isHidden()
inside flare c) Make the behavior configurable viaflare.conf
. This one would have much unnecessary runtime overhead to check for and add or remove various classes, or fallback to the inline style.