Allow adding classes to input widgets (and others)

[b3m2a1]

Problem

I have a Text widget that I want to style using Bootstrap classes (I load these separately) like

widget.add_class("form-control").add_class("me-2")

but at the actual HTML level I end up with something like

<div class="widget-text form-control me-2">
  <label class="widget-label" title="" for="4fe4efd8-ab50-4705-8cef-97c263003825" style="display: none;"></label>
  <input type="text" id="4fe4efd8-ab50-4705-8cef-97c263003825" placeholder="Search">
</div>

which leaves the borders and other bits of styling on the input field.

I could do some global overrides to the CSS or play all sorts of tricks to fix this, but by far the most robust solution would be to simply allow me to mess with the underlying input field.

Proposed Solution

It would be straight-forward to allow users to add their own display classes directly to the input field using a secondary set of classes from those applied to the enclosing div, e.g.

widget.add_inner_class(...)

Additional context

This would also help with styling the base HTML display widget, too, since that also has an inner widget-html-content div that would be nice to be able to restyle to make nicer interfaces

[jasongrout]

In general, if you want to make widgets that look or behave very differently than the core controls, we encourage you to make a custom ipywidget from the cookiecutter and style or change it however you want. For example, there are custom widgets out there that use Vue or Material UI to style a set of controls, and a bootstrap-styled set of components would be welcome as a custom ipywidget package as well.

We do have limited styling changes we support with the core widgets, but we also want to keep the core widgets both simple and consistent in styling.

simply allow me to mess with the underlying input field.

We explicitly moved away from exposing the underlying DOM structure as part of the API in ipywidgets 7, considering the DOM structure an implementation detail that can change.

[b3m2a1]

Custom widgets are clunky, overkill, and force me to write a bunch of buggy boilerplate when I just want to be able to prototype. I'd rather not use Jupyter and just not provide features to my collaborators than write a bunch of hacked together custom widgets that may or may not compile and load for them and may not even work right.

If having access to the DOM is an "implementation detail" then maybe just provide a general purpose ContainerWidget that allows users to specify the entirety of their desired layout, but still be able to nicely embed child widgets. This would have all the benefits of a Box but now instead of the DOM being a detail you need to manage you've passed that off to your users, which the ones who want to actually do real stuff will appreciate.

[jasongrout]

If having access to the DOM is an "implementation detail" then maybe just provide a general purpose ContainerWidget that allows users to specify the entirety of their desired layout, but still be able to nicely embed child widgets. This would have all the benefits of a Box but now instead of the DOM being a detail you need to manage you've passed that off to your users, which the ones who want to actually do real stuff will appreciate.

That's a really intriguing idea. I see you opened another issue exploring some other ideas - is #3433 elaborating on your idea here, or a slightly different take?

Custom widgets are clunky, overkill, and force me to write a bunch of buggy boilerplate when I just want to be able to prototype. I'd rather not use Jupyter and just not provide features to my collaborators than write a bunch of hacked together custom widgets that may or may not compile and load for them and may not even work right.

In the long run, I think a custom widget is the best bet for a robust solution providing bootstrap-styled components (the cookie cutter takes care of the vast majority of the boilerplate). However, for prototyping and iterating quickly, I agree it can feel heavyweight.

[b3m2a1]

@jasongrout I ended up pursuing that idea and making a custom widget. It was frankly a terrible experience and it was like pulling teeth to try to figure out how to do what I wanted and I'm not convinced it won't break once Jupyter widgets 8.x is out, but for now it does everything I want.

Is there a way to now include this widget in another package as a subpackage or do I need any potential users to install that custom widget in Jupyter lab?