Don't do this until we've successfully used it in this project.

I don't know if this should be V1 or not…

Once we have multiple options, it seems likely that you'll want to compare the difference one setting makes.

Being able to copy a configuration from the left to the right (and vice versa) seems like an easy way to achieve this.

https://github.com/GoogleChromeLabs/squoosh/tree/components-merge I've started trying to merge components in here.

• src/components/app/style.scss - definitions generated
• src/components/output/custom-els/PinchZoom/styles.css - definitions generated
• src/components/output/style.scss - no definitions generated

I can't figure out why definitions are missing for that last resource. Any ideas?

http://www.advancemame.it/download

https://github.com/ajafff/tslint-consistent-codestyle/blob/master/docs/naming-convention.md

1. WASM PNG Quant #8
2. Integrate PNG Quant

After that, PNG has a slightly different flow to the other encoders, as it has 'crushers', and sometimes there's a benefit of passing the image through multiple crushers.

1. WASM two crushers #7 #9
2. Integrate 'crush' as a checkbox to PNG encoders, which passes the output through PNG crushers.

The main codec may be "Browser PNG" or "PNG Quant" (#8), but then zero or more crushers (#7 #9) can be applied afterwards.

We need to investigate whether the crushers can be run in parallel, or whether there's a benefit to running them in series. I have a feeling that Zopfli PNG is best run at the end, after other crushers. I guess this depends on which crushers work on PNG data, and which work on raw image data.

1. Stretch goal: Allow each crusher to be enabled/disabled.
2. Stretch goal: Integrate options for each crusher.
3. Stretch goal: Show savings provided by each crusher.

Visualising this in the UI is interesting. It'd be nice to show the savings from the main codec, followed by the savings from each crusher. The crushers themselves have options, which dictate how much time they'll spend crushing the PNG.

Introduced with #28

Our current binding to MozJPEG call free() on the result (see codecs/mozjpeg_emc/mozjpeg_enc.c), as MozJPEG doesn’t seem to provide a custom free call.

We should double-check that this is actually the right thing to do. At some point. Nobody cares about memory leaks, right?

Right now, if we drop multiple images on to the page the app will find the first image in the FileList object and it will open that.

I think the user's expectations would that it the app should handle multiple files 'somehow'.

Here are a couple of potential solutions:

• Keep it as it is.
• Show a selector with a list of all valid image files, letting the user select only one.
• For each image, open up a new instance of squoosh (I think it's classed as a user gesture) and push the image into that new instance.

There are a number of improvements that we can make to the file-drop element that are not directly related to the needs of the app. (see #56 for more context)

• Add enter and leave events
• Add .files support to ondrop (filter...)
• Add valid/in-valid events that map to the css class changes.

https://github.com/subzey/zopfli-png

At the start we agreed to semistandard, but it seems like nobody particularly likes it, especially the rule that requires a space between a function name and ().

Is anyone using a set of linting rules for this project right now? Might make a good starting point. @developit it looks like you're using one, care to share?

On the initial screen we'll give the option to load an example image. I'm thinking:

• A photo.
• A photo with alpha.
• A graphic with gradients and alpha.
• A graphic that's mostly solid colour with alpha.

…since that covers a few typical cases. However, we shouldn't worry too much about the particular images yet, but the interface to select and load one of these images would be great.

It's right that we prevent other mouse events here, but it feels like the wheel should continue to zoom.

I'm quite proud of it, we should abstract it as a deliverable for the project so a lot of developers can use it.

It'll need:

• A drop-down select, to select the codec.
• Toggles.
• Range sliders (eg "quality").

This will be a good point for us to review and test the material design implementation, and decide if the off-the-shelf solution is good enough.

No need hooking the form up to anything until #25 is complete, then we can look at how to define configs for each codec.

For the compression settings.

We need to expose additional MozJPEG options:

1. Via WASm.
2. Via UI.

I feels like we're disabling useful features (like showing address and port number of dev server) because the progress bar doesn't handle it correctly.

If this isn't fixable, we should just get rid of the progress bar.

Make the canvas pinch-zoomable.

Some browsers will need it.

I'm guessing it's automake and docker for mozjpeg?

If this proves super-painful, we can just check them in.

This feature will be available on all screens of the app, not just the intro screen.

There should be some kind of drop indicator, but we shouldn't worry too much about the specific design yet.

Parts of the design are coming together, we should start integrating it so we can iterate on it.

Don't do this until we've figured out if it's useful.

https://github.com/kohler/gifsicle

https://twitter.com/svensauleau/status/1008319046717198337

https://github.com/wasm-tool/emscripten

Something we can display errors in, such as image encode/decode errors.

A material snackbar would do https://material.io/design/components/snackbars.html#anatomy.

continuing on from #12

Later in the project, we need to add a service worker to make the whole offline thing happen.

#77 needs to be considered along with this, as it'll involve a code-update flow that may be out of step with updating the main app.

This is breaking web components.

See https://github.com/GoogleChromeLabs/squoosh/tree/components-merge where I've tried to merge components in.

As we land more codecs we should think about user expectations around large downloads.

Maybe load the codecs on-demand when they're first selected? This would involve two steps: 1. The user selects the codec in the dropdown. 2. Instead of options, they get a bit of text explaining the download size, and a button to download. 3. Once downloaded, they get the options.

We'd probably want a "download all" button on the initial page too.

It's too early to do this now, but we should have it in the back of our minds for when it comes to making this work offline.

We need to expose as many WebP options as we can.

This may be swallowed by #37.

If I npm i in the root, it only installs stuff needed by the main project. That means npm run build:codecs will fail, as codecs/mozjpeg_enc/node_modules/… hasn't been created yet.

Current mobile designs show the two-up working vertically, so this needs to be a feature of the two-up.

https://github.com/kornelski/pngquant

1. npm install
2. npm run build
3. errors in finding './style.scss'
4. npm run build again
5. -> no more error (why ???)

Error message

ERROR in /Users/kosamari/Code/squoosh/src/components/app/index.tsx
[tsl] ERROR in /Users/kosamari/Code/squoosh/src/components/app/index.tsx(3,24)
      TS2307: Cannot find module './style.scss'.

When the user changes settings for a codec, these should be saved somewhere. When they select that codec later, those settings should be restored.

Because of this, we probably want a "reset" button.

Settings should be remembered for each side of the screen. So side * codec.

The codec selected on each side should be remembered between page loads too.

For each compressed image, we need a button that downloads the compressed image.

Right now the project loads an image and displays it in a canvas. It'd be a good first step to output a second canvas that's the same image but put through one of our compressors.

They released v1.0.0 of libwebp end of April. We should update.

This is a little more involved than MozJPEG, as some browsers will need the decoder too.

• WASM the decoder.
• Integrate the decoder & enable the encoder for all browsers.

When integrating the decoder, it should be done in a reusable way, so we can do a similar thing for FLIF & AV1.

For each image, some human readable information on the size vs the original size.

Brought up via. #56 (comment)

Currently we reset everything when you drag on a new image, but we should keep the options around.