Fix legacy support for icons-as-css-background

[telamonian]

References

#7887 (comment)
jupyterlab/extension-examples#70 (comment)

All interfaces that had an .iconClass field now also have an .icon field. If icon is undefined and iconClass is a non-empty string, the interface in question will fall back to the old icon behavior: instead of rendering an svg inside of a container, it will simply set class=iconClass on the container.

However, as spotted by @jtpio, the legacy icons-as-css-background weren't showing up. It turns out that although the DOM was being set up correctly, the icon styling is no longer set up to correctly display background images (eg background-size was unset).

Code changes

Added/fixed up some icon-related CSS classes, and made some small tweaks to the icon stylesheets. All legacy icons should now show up correctly.

User-facing changes

Icons-as-css-background should now all be visible. The PR also includes a fix for the coloring of Blueprint icons (currently only used in a "search" icon in the search bars of the extension manager and the json document widget)

Backwards-incompatible changes

NA

[jupyterlab-dev-mode]

Thanks for making a pull request to JupyterLab!

To try out this branch on binder, follow this link:

[jasongrout]

Is this needed in 2.0?

[telamonian]

In theory there shouldn't be any user visible problems. Instead, some extension devs will be curious/irked as to why their old-style filetype/toolbar/launcher card icons suddenly aren't visible when they try to migrate to 2.0. The solution for them will be to migrate to LabIcon. Which is kind of the desired outcome anyway?

Actually, it might be even less of a problem than that. I think it's been pretty common for people to have set up their own style classes to go along with their icon classes. Here's an example from the geojson-extension:

/**
 * The CSS class for a GeoJSON icon.
 */
const CSS_ICON_CLASS = 'jp-MaterialIcon jp-GeoJSONIcon';

[telamonian]

So I guess I'd say it should go in, but only if it doesn't significantly delay us cutting the final release

[jasongrout]

@blink1073 - your call, then, since you are planning to cut the release tomorrow.

[jtpio]

In theory there shouldn't be any user visible problems. Instead, some extension devs will be curious/irked as to why their old-style filetype/toolbar/launcher card icons suddenly aren't visible when they try to migrate to 2.0. The solution for them will be to migrate to LabIcon. Which is kind of the desired outcome anyway?

Maybe this could be listed as part of the migration guide indeed. That sounds like a reasonable option for now, although it would be nice to have this fix in 2.0.x or 2.x.

[telamonian]

I've fixed/tested legacy icon support for:

• filetype icons
  • main area tabs
  • tab manager tabs
  • sidebar tabs
  • filebrowser listing
• command icons
  • launcher section header
  • launcher card
  • menu items
• settings editor item icons
• toolbar button icons

I think that covers all of the places where an icon passed into core by an extension can get used

[telamonian]

@saulshanabrook I believe this was included as part of the 2.0.0 release, not a 2.1.x release

[saulshanabrook]

Ah thanks for the catch max!