Styling, layout tweaks and how to help out

[rafaqz]

Now that this is released and I have Flatten.jl I don't need AutoInteract.jl anymore... I'll be directly using this packages for making UIs, so I was wondering how my efforts to polish project layouts could be contributed back where possible.

There are lots of small details like labels overlapping sliders when widgets are smaller that I need to tweak for two projects over the next week. It would be good to do those fixes in a generally useful way, if you have any pointers on that!

I also have some nice formatting helpers from AutoInteract such as column layouts for large groups of widgets, and those could be good to include in the Interact ecosystem somehow.

[piever]

Layout /stylingis a bit of a delicate issue right now. My current plan is to have one default backend (Bulma) and use Bulma's default functions for layout (see the columns and layout sections here). You can use all of that via WebIO (e.g. Node(:div, className = "columns"))

What happens is that now all widgets with a "side" label use flex_row which is a CSS "flexbox" row that takes 20% space on the left for the label, 60% for the main widget and 20% on the left empty. This started as a hack and then stayed like this... If you can come up with some flexbox based layout that works for everything consistently, that'd be really good (for example the 20% part could have a min width or max width attributes in css or things like that). Also keep in mind that the new slider (rangeslider) has tooltips rather than the value on the right (and is meant to be a replacement for slider in the future).

Concerning the layout tools, if they are pure CSS I think they can go in CSSUtil, whereas if they are based on Bulma layout system, they could probably go in InteractBase (or InteractBulma, but I'm starting to think I should fuse the two packages anyway).

[rafaqz]

Thanks. I've been looking into fixing layout issues for getting 60+ sliders on one page.

These functions are kind of a problem, as they hard codes the css spacing you mentioned into the element style so you always have to use !important to override it. (which is kind of frowned upon as far as I am aware? its a few years since I've done web dev)

function flex_row(a,b,c=dom"div"())
    dom"div.[style=display:flex; justify-content:center; align-items:center;]"(
        dom"div[style=text-align:right;width:18%]"(a),
        dom"div[style=flex-grow:1; margin: 0 2%]"(b),
        dom"div[style=width:18%]"(c)
    )
end

flex_row(a) =
dom"div.[style=display:flex; justify-content:center; align-items:center;]"(a)

Could this be done with css classes instead? whats the general philosophy concerning css vs element styles?

Edit: And further they don't have many classes, so you need to do a lot of digging into the dom to actually apply important! overrides.

[rafaqz]

To solve this I could just move all of those styles over into style.css and replace them with clases?

[piever]

Sure! Though the correct file is custom.css in InteractBulma (I should probably rename/reorganize those files). A few more things:

• if you call the slider with label=nothing, readout=false you get just the slider object, so you can do the layout in full freedom
• ~see also if some Bulma classes can help (like level)~ probably not worth it, it looks like something one can do easily with flexbox, I think we should add our own
• focus on the layout where the readout is on the tooltip (rangeslider) as that will be the default in the future

[rafaqz]

I just realised that when everything came out unstyled!

In terms of class names: widget-row, widget-left, widget-center, widget-right?

[rafaqz]

It would also be nice to have the widget type as a css class, so that classes on flex row would be widget-row and also slider? or further up on the same node as field, or both?

[rafaqz]

Also is there a helper function for including your own custom css?

[piever]

I've done a small reorganization so that you can include your new styles in style.css in InteractBase (and I'll delete custom.css as soon as it's not needed any more).

To use your own css, you should do:

import InteractBase: AbstractWidgetTheme, libraries
struct MyTheme <: AbstractWidgethTheme; end
libraries(::MyTheme) = vcat(libraries(Bulma()), [...])

where [...] are your own libraries, then settheme!(MyTheme()) will use the new libraries.

[piever]

I could probably make the Bulma type a bit richer so that for example Bulma(extra = "mystyle.css") would be a theme that loads bulma libraries + "mystyle.css".

Concerning the separate class for each widget, I think the names should be specific to interact to avoid conflicts (for example interact-slider, etc...). For now I think it'd be nicer to have something that works for everything (in terms of flex_row) and maybe come up with a better name for it.

[rafaqz]

Having additional css in a keyword would simplify that process. I also agree on the interact- prefix.

I'm torn between getting the general case working and just getting this interface going this week for the widgets I'm using, but definitely will aim towards generalise strategies.

[piever]

Should be easy enough to add a customcss argument that adds some custom library to a theme: I'll get to it as soon as I have more time.

Would love it if you'd find a good general solution, it may be tricky though, esp. as the slider also has a vertical mode, say rangeslider(1:100, orientation = "vertical")

[piever]

Copying my reply in #111 here as this seems the appropriate place to discuss things, I think this is a reasonable to do list in terms of layout fixes:

• [ ] Figure out the noUIslider case to avoid the hardcoded style hack
• [ ] Fix the custom width to the slider: if I specify the width of the slider, the flexbox still grows and one gets unwanted space, for example:

• [ ] Port the fix in #89 to the class + css style file approach