Brand assets

[Errolyn]

New assets for general use in bedrock.

[craigcook]

I've finally actually looked through the icons and have gathered some thoughts, in no particular order:

• This is consolidating what is already in bedrock but I thought we were getting every icon in every color to build up a whole versatile library. Is that still the plan and the rest are forthcoming or did I leap to an assumption? (I very likely made an assumption).
• If I did assume and we don't actually have every icon in every color, we should totally do that but I don't want to block this PR, we can keep expanding the library later and this can just be a start. But we still need to think system-wide. If all we're doing is copying assets from bedrock that were made for use on specific pages then they don't belong in Protocol. This should be a universal set of icons for use on any Mozilla website.
• A few of the multiples we have here aren't currently equivalent. There's an orange breach.svg and a blue breach.svg but they're slightly different sizes. There's a pink password.svg and a violet password-manager.svg that are essentially the same but different sizes and constructions (and different names, of course). The pink sync.svg and orange sync.svg are different sizes. If we have multiple versions of an icon they should be identical in every way but color.
• The sizes are a bit all over the place and we should try to standardize. It would also be ideal if they were all perfectly square but that will entail more editing to put them all in a square viewbox.
• These files have width and height but no viewbox, and I can never remember which browser needs which so I've gotten in the habit of always including all three attributes. Maybe width and height alone work in every browser, and I think it's viewbox alone that doesn't (because some older browsers didn't support viewbox... unless I'm remembering wrong). So if viewbox isn't needed then maybe this is fine but I want to double check.
• I'm not sure about the "general" folder but I don't know what else to call it. Those icons are all the same size and style and would fit right in with the icons in the root folder but those are already a mess and due for an overhaul so I don't want to make it more messy. Maybe we can come up with a more descriptive folder name than "general" but I'm currently at a loss.
• We've talked about naming files to be more generally descriptive of the icon and not necessarily its use or metaphor, so here are a few suggestions:
  • breach -> alert
  • polaroid -> picture
  • login -> key
  • blog -> website
  • performance -> speedometer
  • memory -> microchip
  • customize -> paintbrush
  • privacy -> eye-slash
• However, there are some icons that are closely associated with specific features and also appear within Firefox, so those I think should be named for the feature to help us avoid misusing them for other things. Maybe even prefixed with "feature-"? For example, the bookmarks icon isn't just any old star, it's specifically the Firefox bookmark icon and shouldn't be used for anything else, so that could be "feature-bookmarks.svg" or even "feature-bookmarks-star.svg". Some of these file names get pretty long so maybe there are better options:
  • bookmarks -> feature-bookmarks-star
  • private-browsing -> feature-private-browsing-mask
  • tracking-protection -> feature-tracking-protection-shield
  • sync -> feature-sync-arrows
  • history -> feature-history-clock
  • send-tabs -> feature-send-tabs-mobile

Renaming files is straightforward, but the bigger matter is going to be resizing and squaring them so they're all consistent and standardized. Sorry that what seemed like a quick task has now probably turned into a bunch of extra design work. I can definitely help with editing SVGs but it's going to take time. Maybe we can get help from Cristina as well.

[stephaniehobson]

I'd like to suggest we don't put them in a standard square box since that means they can't be left aligned. We can add a square box effect with CSS but we can't take it away.

[craigcook]

Well that does raise another point: the icons are of varying shapes so even putting them all in an invisible box means we'd have to figure out where to position some of them within that box. The key is wide and short, the send-tabs device is tall and narrow. So while square would be ideal it might not work because most of them weren't designed to fit a standard square box. I just don't want a bunch of randomly sized singletons, but I don't know where the happy medium lies.

[stephaniehobson]

The existing icons they are all centered in a 24x24 pixel box. I think the icons in /icons/brand/general should be updated to match that format and they should be moved into /icons. Some will be updates to existing icons (for example shield.svg is the same as tracking-protect.svg)

The coloured ones feel different though. Maybe they should be kept cropped but enlarged so their longest side is... 64px? That's the size they were used at on /firefox/features.

[craigcook]

So after a bit of discussion with the team we agreed on some standards (yay standards!):

The "big icons" should be 64px by 64px. However, given that not every icon will fit a perfect square, we agreed that width should be the variable and height should be uniform. This means everything is 64px tall, and icons that are less than that height should be vertically centered.

The small icons should be 24 x 24 and we can put them in the main icons folder. Most of what's currently there are due to be changed or scrapped, but it seems like the appropriate home for these new ones, at least for now.

We still need to look through the set of icons being added here and determine if they all really belong in Protocol or if some might not, and I'm going to try to make time early next week to go through them with one of the designers and make a call on each one.

We also still need to think about color variants, since I still think we should have each icon in each color but we'll hold off on doing any of that extra work until we know the full set (no use making more colored versions of an icon we're going to remove).

[craigcook]

Sorry for taking so long to get back to you. 😞

After looking through the general icons again, it turns out most of them are duplicates so we don't need to add them again. The only really new ones are open-source.svg and mountain.svg, and we should put them in the /icons/ root folder (and size them to match the others).

One oddity is the mozilla.svg in the root folder, which is an outlined version of the "m" rather than the black square version. But we do have the black square one at /icons/social/mozilla/black.svg. I don't think we should change the outline version in the root because I think we'll be overhauling/reorganizing ALL of those.

As for the colored icons, the only one we should exclude for now is send-tabs.svg because Kropp wants to make a better version with a stronger arrow (the current light arrow gets lost on a light background). All the rest are good to go, but we still need to resize and rename them. And we did reach an agreement that the ones directly tied to a Firefox feature should get prefixed with feature-.

@Errolyn if you want to do the renaming part I can then work on making them all a uniform size and we can get this landed. Sorry again for the delays.

Here a checklist of name changes I'm proposing (all in one place for easy reference, instead of scattered in different comments):

• [ ] breach.svg -> alert.svg
• [ ] polaroid.svg -> picture.svg
• [ ] login.svg -> key.svg
• [ ] blog.svg -> website.svg
• [ ] performance.svg -> speedometer.svg
• [ ] memory.svg -> microchip.svg
• [ ] customize.svg -> paintbrush.svg
• [ ] privacy.svg -> eye-slash.svg
• [ ] password-manager.svg -> password.svg
• [ ] extensions.svg -> feature-extensions-puzzle.svg
• [ ] bookmarks.svg -> feature-bookmarks-star.svg
• [ ] private-browsing.svg -> feature-private-browsing-mask.svg
• [ ] tracking-protection.svg -> feature-tracking-protection-shield.svg
• [ ] sync.svg -> feature-sync-arrows.svg
• [ ] history.svg -> feature-history-clock.svg

[Errolyn]

@craigcook Thanks! I will get working on those when I finish up with the whatsnew page I'm currently working on.

[craigcook]

Latest updates:

• I've renamed most of the files.
• Re-rendered a few to make for cleaner SVGs.
• I went ahead and made all of them in every color (and we might add a fifth color variant at some point).

So I think this is ready for a final review.

[craigcook]

I found a few non-blocking issues below:

Coloring

There seem to be three ways (two ways, with a mixture of both as a third way) to color the SVGs:

* Style tag and class selectors

  * `<style> .class {…}` + `<path class="…"`

* Inline style

  * `<path fill="…">`

Is there a standard we should adhere to?

Most of these come straight out of Sketch or Illustrator and are then run through SVGO for tidying. Depending on the configuration, SVGO will use inline styling for one-offs and classes for anything repeated many times. So it's going to vary depending on the actual image and its complexity. So... I guess there's not really a preferred standard, just whatever works and produces the best optimized file.

License Header

Should the MPL 2.0 header be included? It's included on Moz Central icons.

This I don't know, and I'm not sure who we should ask. I'd rather avoid the extra bytes but if there's some reason we really must include that in every single file we can add it. But I also feel like it's covered by the general license for the entire repository.

Width/height units (nit)

The root icons use 24px in the width and height attributes, but in the brand/{color} directory, they use 64. Is there a specific format we should use?

The brand icons are bigger since they're intended more as spot illustrations. The other icons are more like UI icons. And in fact once we update/replace the icons currently in the root I think we should move them into a "ui" folder, but they can stay in the root for now.

~SVG Version~

~Should each file have the SVG version defined?~ Disregarding this issue per MDN documentation.

Also stripped by SVGO since it's basically just cruft.

[maxxcrawford]

@craigcook

Width/height units (nit)

The root icons use 24px in the width and height attributes, but in the brand/{color} directory, they use 64. Is there a specific format we should use?

I was specifically calling out the use of px in some cases and others, not. (Sizing makes sense!)

[craigcook]

I was specifically calling out the use of px in some cases and others, not. (Sizing makes sense!)

Oh I see... those attributes shouldn't have units at all, it should just be width="24" height="24" (same as in HTML).

[craigcook]

I was specifically calling out the use of px in some cases and others, not. (Sizing makes sense!)

Oh I see... those attributes shouldn't have units at all, it should just be width="24" height="24" (same as in HTML).

So after a little further reading of SVG specs I learned I was wrong: width and height attribute values should indeed have units in SVG. A unitless value is valid, but is a "user unit" which I think means it's up to the renderer to decide what that number means. And in the world of web browsers I think such user units are calculated in pixels anyway. So... we can omit the units and trust the implicit pixelness of the unitless value OR we can include the unit explicitly. I usually favor explicit, so I'd vote for adding px on any that currently lack them. That includes all the new icons we just added because I was wrong (see, I admitted it twice).

That said, we really only need width and height attributes for old browsers (IE 7/8/9) that don't grok viewBox and ordinarily wouldn't need those attributes at all, assuming viewBox is included. So we could also just not include the attributes at all but then in my experience older IEs render all SVGs at 300px by 150px (unless sized otherwise by HTML attributes or CSS). So I've gotten in the habit of including width and height but I'm really not sure it's worth it any more.