Closed Bug 1809987 Opened 3 years ago Closed 3 years ago

Replace use of inline SVGs with CSS icon fonts, automating and documenting font update process

Categories

(Webtools :: Searchfox, enhancement)

enhancement

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: asuth, Assigned: asuth)

References

Details

Attachments

(3 files)

For the addition of a settings page in bug 1703656 I knew I would need an icon for a settings page. While I've put most of the code archaeology notes in the pull request itself, the general situation seems to be:

  • Searchfox has a CSS icon font that was generated via fontello.com. This was forked from DXR, and it appears that the font used was "Font Awesome" by visual inspection. Although there were 4 icons in the font, we only used the arrow for the navigation panel, which we used CSS to rotate rather than using a 2nd icon.
  • We used inline SVG for the navigation panel copy/"docs" icon and tick icon when the copy was performed. Per the inline comments, the icons were taken from the Firefox source. I presume this was done for reasons of pragmatism because we didn't really know how to update the CSS font.

Logistically/ergonomically speaking, the inline SVGs have been feeling awkward, at least to me as I've been changing some of our HTML generation logic to liquid. Pre-this-bug, we have hunks of inline SVG that are repeatedly inlined into the HTML by rust code, as well as liquid templates that help do the same thing. On a normal searchfox source page with revision control and bug links, this means we have 7 copies of the copy icon and 7 copies of the tick icon.

So in this bug I'm:

  • Adding tooling/automation to help update the fonts using the fontello.com API. Currently we're just using the Font Awesome font version hosted on that site because this was the minimum amount of change. I have a superficial understanding of skimming Font Awesome's site, but it seems like it's a much more full service offering now, providing its own bundling and also a bunch of variations of the fonts in different weights, etc. So if we wanted more, it might be reasonable to switch directly to Font Awesome.
  • Moving us to somewhat more directly use the fontello automatically generated CSS, and accordingly moving the file type "icons" to specifically have a "mimetype-icon-" prefix instead of "icon-" to avoid collisions here.
    • I've also unified how the "search" and "query" endpoints use the CSS classes, allowing me to un-fork the background-url aspects. In particular, we no longer will just use "c" as a class for C files, which then requires a bunch of additional CSS specifiers to avoid collision with our syntax highlighting classes (which really do want to be short for file size reasons), but instead "mimetype-icon-c".
  • Replacing use of inline SVGs with CSS fonts.

That last bullet point will result in a visual change for the copy icons! Right now our copy icons have a very thick stroke on them and are 14.4 x 14.4 within their 18 x 18 button. The new icon does not have as thick a stroke and is 14 x 12 within its 18 x 18 button. This actually ends up being a much more button-feeling button thanks to the padding and that isn't so aggressively in your face.

Arguably this is a fairly notable difference, and I think the transition is likely to be a bit jarring to users. It feels a bit like the button was set to 11 and is now turned down to an 8, which may be a bit of an overshoot. But I'm going to stick with this for now for reasons of:

  • Pragmatism! My goal here is to get new usable searchfox features in. Patches will absolutely be accepted for this, although I think the "price anchoring" of an abrupt transition to a lighter weight icon may be a good place to iterate from rather than the current very heavy weight icon.
  • For the "fancy bar", the current heavy weight icon with little padding is a bit distracting because it draws the eye towards it. This has been useful so far because that's probably actually the thing people want to click on a lot of the time, but is not useful going forward.

(Going to leave this open since it's likely there will be some discussion and follow-ups.)

Everyone accepted the icon changes!

Status: ASSIGNED → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: