Add a script to run all images through svgo #462
Comments
|
A caveat: by default I did a test run preserving the |
|
Running through the entire site gives just shy of 20% savings. One file is problematic. |
|
I took the liberty of checking the... SVG FilesDisclosure: the Validation performed with: $ vnu --skip-non-svg DIRECTORY_PATH285 | Files 167 | Pass 59% Element "stop" is missing required attribute "offset"114 files: Possible resolutionWhen a single stop offset is specified, then all stop offsets must be specified. Add an appropriate stop offset. Attribute "className" not allowed on element "svg" at this point.1 file: Possible resolutionUse the attribute "class" not "className" as a hook since className is not the same in HTML and SVG. See Expected '"' or "'" (found "“")1 file: Possible resolutionReplace Unicode quotation marks with ASCII equivalents. See Attribute "mask-type" not allowed on element "mask" at this point.1 file: This appears to be a SVG 2 feature which although well supported by browsers is still not an official specification (it is at candidate recommendation stage). Ignore? Attribute "aria-label" not allowed on element "g" at this point.1 file: I have no clarity on this. It appears that between SVG 1.1 and 2, the validator has tightened certain restrictions. Possible resolutionUse a |
|
I am happy to make any changes you'd like. :) As the SVG files appear somewhat compressed, perhaps this work would have to be redone unless the changes are made upstream. I don't yet know where in the large Exercism ecosystem they live, so please point if you'd like me to do anything. :) |
|
Thank you :) Maybe you and Erik could agree a good workflow for svgo (either as part of deploy, or as part of the PR process) that compresses things. And then we can have a separate PR that tidies up the existing ones. From a "what matters" perspective, size feels important/valuable, and then anything that actually changes how they look in the browser. e.g. for the offset one above, if it doesn't matter from a rendering perspective then I don't massively care whether it's added or not, but if it means they pass the validator and we can use that in a github-action moving forward, that's great. What I don't want to have to do is do manual work on each PR to check things or keep them up to date. As an FYI, Erik is quite busy atm (we have team away week next week then onboarding new front-end dev the week after) so we're both probably slower than usual in replying etc. |
|
The linting stuff could easily go into a workflow I feel. It's just a matter of finding the time to do so.
Are you saying you want us to automatically correct SVGs that are added/changed in a PR? Would a script to run through the files in bulk help? We could theoretically also use a git hook 🤷 |
That would be nice, yes! |
https://github.com/svg/svgo
We can choose our options at https://jakearchibald.github.io/svgomg/
The text was updated successfully, but these errors were encountered: