Indent instead of de-indent when soft wrapping long lines in signatures

[joelostblom]

Problem

If the function signature contains long lines, the JupyterLab help pop up / inspector will wrap and de-indent the line. It would be easier to read if the wrapped line was indented relative the original line (just as how indentation is used in python code to indicate belonging to the previous lines/indentation level). Here is an example from the altair docs; you can see how the different parameters melt together and it is hard to tell which options belongs to which parameter due to how the indendation is handled:

There are other reasons that docstring is hard to read, which we are working on in vega/altair#3290, but the way lines are wrapped is one of them.

Proposed Solution

Indent the lines that are wrapped one level more than the indentation of the parameter name. I think this would notably improve readability, e.g. this is what the screenshot above would look like:

This is also how wrapping is handled in the docstring, so it would be consistent to handle it this way in the signature as well.

[krassowski]

This could be addressed with CSS text-indent: hanging (https://developer.mozilla.org/en-US/docs/Web/CSS/text-indent) but it is only supported in Firefox and Safari with Chromium-based browsers lagging behind as of beginning of 2024 (https://caniuse.com/mdn-css_properties_text-indent_hanging). It seems it is behind a flag in Chrome since 2015 https://bugs.chromium.org/p/chromium/issues/detail?id=360958.

[joelostblom]

Thanks @krassowski, that sounds like a suitable option even if it isn't supported on all browsers yet. In which file should it be added?

[krassowski]

It is not obvious to me. A safe bet would be a rule targeting the rendered code in tooltips, placing the new rule in jupyterlab/packages/tooltip-extension/style/base.css (a new file, which needs to be imported from index), with scoping to a new CSS class indicating "this is a tooltip with inspect reply rendered as code" so that this do not affect other uses of tooltips/rendered code. But maybe it would be permissible to make it a default for all code rendered in tooltips and a new class would not be needed? In that case we could consider placing it with rendermime renderer for code, or in the tooltip package.

[joelostblom]

But maybe it would be permissible to make it a default for all code rendered in tooltips and a new class would not be needed?

I would personally vote for it being the default as it makes the text easier to read and does not have any immediate downside (I'm assuming that chrome and other incompatible browsers just fall back to the old default behavior).