How to make squeaky clean SVGs for use in applications


  1. Open the SVG in Adobe Illustrator.
  2. Where possible, unite shapes with the same fill into compound paths.
  3. Where possible, outline strokes. This will make cleanup easier when we dig into the code.
  4. Remove any additional paths, bounding boxes, etc, that are not a visible part of the SVG.
  5. Scale the SVG to intended rendering size (e.g. if it’s a 24px icon, scale the SVG to be 24px).
    If you want the SVG to be in a 24px "bounding box", then make sure the canvas size is 24px, and your svg is your desired size within the canvas. The canvas functions as your "bounding box".
  6. Clean up sub-pixel alignments where feasible.
  7. Save SVG.

  8. Open the SVG that was just saved by Adobe Illustrator in SVGX.
  9. Select “Optimized” tab.
  10. Hit [Copy].

  11. Open SVG that was just saved by Adobe Illustrator in Visual Studio Code (VScode).
    At this point, it’s possible that no image displays in SVGX’s preview, even if there’s code. That’s fine. Copy the code from the “Optimized” tab in SVGX.
  12. Paste the SVG code from SVGX below Adobe’s original SVG code.
    We’ll be using the code from SVGX, with a few tweaks based on the Adobe original.
  13. (Optional) Turn on word wrap.

    VScode - SVGX-pasted code
  14. Ensure the svg opening tag contains only xmlns and viewBox attributes.
  15. Add title tag and string directly below (outside of) the opening svg tag.
    Do describe what the image is. Don't describe what the image can be used to represent.
    <title>Speedometer</title> - Do
    <title>Dashboard</title> - Don’t
    What the image represents will be handled separately with aria-label or alt-text, depending on the implementation.

    Single-colour SVGs meant to be used as icons
  16. Do NOT declare the colour of any path(s) using the fill attribute.
    E.g. DON’T <path fill="#000" d="M22 11.8h-3.6V13h3l5.5 8.3h1.4z"/>
    This makes the svgs harder to dynamically colour.

  17. Single-colour SVGs meant to be used as images
    Declare the colour of any path(s) using the fill attribute.
    E.g. <path fill="#000" d="M22 11.8h-3.6V13h3l5.5 8.3h1.4z"/>
    This is for SVGs used as images, where there’s no intent to dynamically change the colour

    Multi-colour SVGs
  18. Declare the correct corresponding colour of each path using the fill attribute.
    SVGX-pasted code will often strip the first colour class, and fail to apply it to the first path associated with it. We’ll need to eyeball the path coordinates, and guess match up the colour in the class to the correct path.
    E.g. <path fill="#41B59D" d="M22 11.8h-3.6V13h3l5.5 8.3h1.4z"/>
  19. Remove style tags, and anything in them.
  20. Remove classes, and their values.
    We are replacing style and class with fill and the colour in the corresponding class.
  21. Delete the original code from Adobe Illustrator.
    We only want the code we pasted from SVGX, and then cleaned up.
  22. Save the SVG in VScode.
  23. Open the VScode edited SVG in SVGX.
  24. If the SVG looks as desired / expected - congrats! It’s clean! We can now add it to Iconset.


When I open my VScode edited SVG in SVGX, some paths don’t have the right colours.
It can be tricky to assign the right fills to paths, especially if there are a few of them. Try outlining strokes, and/or combining shapes with the same colours into compound paths in Adobe Illustrator before working with SVGX and VScode.

SVGX is showing a blank preview when I open my VScode edited SVG.
Test the paths by declaring a fill, like so.
<path fill="#41B59D" d="M22 11.8h-3.6V13h3l5.5 8.3h1.4z"/>
If you’re making an SVG that needs to be dynamically recoloured, remember to remove the fills after the preview looks good.

SVGX looks fine, but when I import into Iconset, it just shows a black square/circle/shape.
There may be an additional invisible bounding box / path from the original SVG, which is now being filled, and resulting in a black square/circle/shape. Either locate the invisible path in the SVG code and delete it (this can be hard), or delete the invisible path in Adobe Illustrator, and try again.

Strawberry goop shortbread cookie-tart aka tapioca flour is magical!

We've been thickening savoury sauces with tapioca starch for a while now. We like it better than cornstarch, because it doesn't muddy the flavour of things the way cornstarch does.

At some point, we decided to thicken a pie filling with tapioca starch. <.< There's no going back. Tapioca starch is magical in fruit filling type goops. It makes everything so wonderfully blobby and clear and pretty, without being sticky and tacky. And it even re-bakes nicely, if you want to stuff it in a puff pastry and bake it.

Strawberry yuzu goop

Makes about 500g of goop. Don't worry about measuring exactly. :P I don't really measure stuff, and this is all conjecture anyway haha. If you use too much tapioca starch, you'll just end up with a more solid and bouncy goop.


  • 500g strawberries, chopped
  • 30g~ of honey citron tea - brand doesn't matter, they're all nice (yuzu is wonderful with strawberries)
  • 30g~ tapioca starch
  • 30ml water
  • white sugar to taste (depends on how sweet your berries are)
  • ground cardamom to taste

Steps to reproduce

  1. Chop the strawberries into fingernail-sized bits. It's okay if your fingernails are giant or midget. All fingernail sizes are welcome.
  2. Dump chopped strawberries, sugar, honey citron tea, and ground cardamom in a small pot of your choice (needs to be big enough to hold all your strawberries, obviously).
  3. In a separate bowl, add water to the tapioca starch and swirl it around till it forms a slurry. Don't skip this step! If you just dump the tapioca flour into the pot with the rest, you'll end up with tapioca lumps.
  4. Add tapioca flour slurry to the rest of the stuff in the pot.
  5. Cook at low to medium heat for about 10 minutes, stirring pretty much all the time. Yeah, it sucks. :( I hate stirring.
    The tapioca slurry will look white at first, but once it's done, it'll turn clear.
  6. When the strawberries are squishy enough for your taste, and everything is goopy and clear, it's done.

The goop is great both hot and cold, and it reheats and bakes well. So once you have the goop, go on and GOOP ALL THE THINGS!

Free COVID-19 customer logbook for small businesses

I made a very very very basic Airtable template for a COVID-19 customer logbook for small businesses.

Like many Victorians, I watch our Victorian Premier's (Dan Andrews) press conference near every day.

At one of the press conferences a couple of days ago, one of the reporters kept talking about "QR codes" for small businesses, as if QR codes are magical things that will somehow record everything when a customer scans em.

After that press conference, I was complaining to my partner, Does the reporter even know what a QR code does? If it doesn't redirect to a database, with form, etc, what's the point? How will a small shop set this up?

Then I realised, Hey, I happen to know this no-code tool... (Airtable)......and this kinda happened.

The bulk of the work was writing the instructions in a way that normal people can understand and follow.

That old chestnut again: Should designers code? No... and yes. ;)

Some ponderings as I learn the wonders of CSS-grid, fluid typography, and all the shiny new toys kids these days have.

Gosh, CSS has gotten so much nicer since the days when we had to haul water to the top of the hill both ways barefoot in the snow.

No, designers shouldn't code
I don't think designers need to be able to write production quality code. It stands to reason that I have a vested interest in this "no", as I haven't committed production code in over a decade. Plus, production quality code, especially at an enterprise-level, is a completely different beast from building a small static website. When it comes to enterprise code, scalability, maintainability, extensibility are all very important - and I prefer to leave them to the experts (my developers).

Yes, designers should code
Ideally, designers should have some familiarity with, and understanding of the basic "materials" used to build the digital products they design. Additionally, the "materials" will vary, even across digital products. Just because I can write js and css certainly does not mean I know the "materials" for native Windows, Mac, Android, or Linux.

With that as the caveat - being able to code just enough to know my materials is a very big plus. I did a basic Vue course fairly recently. Nothing fancy, just a single page app. However, what I learnt from that course gave me a much better idea of how Vue (and React, and Angular) work at a very high level, and how that can translate into implementation. It also made it collaborating with front-end web developers easier, as we had some degree of shared knowledge.

I've also been experimenting with the "new" (not so new, I know) CSS toys all the kids have these days. What's really cool about this is that unlike the Vue course, what I'm learning about CSS is changing the way I think and design - and think about design. These learnings change the bounds of what I know are possible.

For example, I have been reading about fluid typography on the web for a couple of years now - and before I started poking around the code, it's been a very abstract sort of interest. E.g. "Nice and interesting abstract concept, I should try to design for that when I have the opportunity". Now that I've poked around the code, and gotten a basic understanding of how things work, this has changed to a much more real and practical, "ZOMG now that I actually know how that bit of code holds together, I can actually set a typographic scale that way, and see it work. And I can see how I could make it work in so many places. Waoohh!"

Here's my supernoob code-pen, which I'm modifying on the fly as I learn more about css-grid and fluid typography.
All the noob inline comments, every noob inline comments!

See the Pen Flying Red Horse - CSS-Grid Experiments by JC (@nuggettyone) on CodePen.