1133682 - (svg-devtools) [meta] DevTools for SVG

Status: NEW

(DevTools :: Inspector, enhancement, P3)

Description

[Tim Nguyen :ntim]

It'd be nice to get improvements in DevTools for SVG (New Highlighters, editors, ...).

Comment 1

[Patrick Brosset <:pbro>]

Inspector bug triage (filter on CLIMBING SHOES).

Comment 2

[Jen Simmons [:jensimmons]]

I get questions about the Firefox Shape Path Editor, and whether or not it'll work for SVG. People who use SVG (and teach it, explore it's limits) frequently ask if it could support SVG as well as clip-path and shape-outside.

When I asked about it in #devtools Slack this week, Patrick said:

I’d love to hear opinions about this, and what problems people are trying to solve that DevTools could help with, that an external SVG editor wouldn’t

It’s good question — how often in the workflow of using SVG would it be very helpful to have an editor in DevTools? What are the usecases that would be make an in-browser tool more compelling that using Illustrator or Sketch, etc? Would it still be helpful if the Shape Path Editor only worked on inline SVG (and not SVG files)? How often are people wanting to edit right there on the webpage? How often are such edits affected by / interacting with / dependent on other web content?

That’s the amazing feature for shape-outside & clip-path — to be able to adjust the Shape and see how it interacts with the text that flows around, or the background image underneath. Is there a similar usecase for SVG? Is there a situation where an SVG needs to be edited in context because it interacts with the rest of the web page?

Or do we get this request simply because folks who love SVG see the Shape Path Editor and naturally wonder if it works for SVG, too (since it looks so much like a vector graphics program).

Comment 3

[Amelia Bellamy-Royds]

The biggest problem with saying "just use external tools" is that external tools only work with stand-alone SVG files, and they usually have limited CSS support. You have to draw the shapes, and then export the code & copy-paste to integrate it in the rest of the web-page or CSS & then test to confirm it all works correctly. I hardly ever use external tools, since I'm rarely doing the types of "artistic" SVG that make it worth all that hassle.

I would very, very much like in-browser path editors. Yes, it would be more complicated than the existing shapes editor (which I think is still only restricted to polygons). But once you handle all the cases for SVG inline, I doubt you'll find that it's much more complicated to support SVG in stand-alone documents.

In general, the biggest use case for SVG Dev Tools are these cases of integrating SVG design & testing with the rest of the web dev tools we love!

Comment 4

[Lea Verou]

To add to Amelia's excellent post above, external tools also do not keep up with the state of web technologies. Use CSS variables, or any non RGB, non-opaque color and most external tools choke (and that's just an example). Browsers have to keep up.
Also, external tools are primarily made for visual designers who don't touch the SVG source. They are not very well suited to a primarily hand coding workflow. I tend to hand-code my SVGs for various reasons (e.g. parameterizing them eventually), but I need a visual editor for paths. I tend to make the path in Illustrator, then export, copy the d attribute and paste it in my code. If I need to make adjustments, the process repeats. It's extremely tedious, to the point that I made my own rudimentary path editor a while ago as a Mavo demo 1, which is a duct tape solution but still works better for my needs than the Illustrator roundtrips.
I've wished for something like a devtools path editor for as long as I knew SVG. So many times I said I'd code an editor extension for this and never got around to it. I would definitely have use for it!

Comment 5

[Lee Griffin]

I have the following situations that I'd appreciate being able to edit SVG paths in the browser using some kind of Dev Tool. First is simply position and design of SVGs. Sometimes I'm provided SVGs where they simply don't quite fit the layout as expected. The process for me to amend these would be to go and open it in illustrator, re-save it as an SVG, re-upload that SVG to my CMS and then refresh my browser to see if the changes line up. I can get in to situations where I'll have to repeat this multiple times. If I were able to easily manipulate the paths in-situ I could see immediately how the shape would have to be set so that I can copy out this and make a single change. A very recent example I have is of a simple animation using some dash-offset changes, but the SVG for the line not visually matching the illustrator version. Cue a ton of having to re-edit a file that looks fine in an external editor to try and stop an inconsistency that only appears once in the browser, something that could possibly have been tinkered with and fixed in the environment it's going to be set in much quicker.

The next is animations, with more clients starting to use SVGs in some form of animation the ability to better. Being able to edit the SVG to the various cue points of the animation and make fine changes within the context of where the graphic will reside in this way would also help in a similar manner of not needing to keep editing and re-uploading files. This would be something I might typically find useful if combining with Greensock or similar libraries, and while I'm unsure of whether it would ever be the case, if Chrome's ability to change simple paths using CSS were to become more adopted the ability to then alter the different states more precisely in-situ would become even more useful.

Personally I don't need any help with SVGs that are not inline, and I'd be interested if it were different for anyone else, but SVGs inserted in <img> tags or similar are treated as static images in my experience and so external editing for these is fine. Though my expectation would be that if the file was opened in the browser then the editor would work on it anyway.

I can definitely carry on without any tool aiding editing of SVGs in the browser, but I can see across multiple developments I've been involved in where it would have likely significantly increased my productivity to have such a tool available.

Comment 6

[corey]

I very much agree with Lea's points and would like to add a few of my own. First of all, most "external editors" are not free software, as a primarilly Developer I don't own sketch or photoshop.
Secondly, my common use case for wanting to edit paths is for doing stuff with animating stroke dash array for the "drawing" effect, or other css+svg animation tricks and basically it's impossible to see changes in a live editor for that technique in any software that i'm aware of

Comment 7

[valentinium]

Similar experiences to those above; I would absolutely benefit from more in-devtools SVG manipulation.

I often receive crufty, ‘converted-to-shape’, all-pathdata SVG which were produced by wysiwyg editors. I edit these files by hand, attempting to translate them into coherent code using least-power SVG primitives and presentation attributes. The primary objectives are to ensure consistency (e.g. same viewport units, proportions, stroke widths, optical center across various icons), keep them small, and most of all, to make the SVGs into first-class parts of the codebase that people can maintain, learn from, and style. I believe that the practice of treating them like binary trash assets is both bad for users (file size) and for devs who could otherwise learn new skills (many people don’t even realize SVG is a human readable and writable format at all). This process also can sometimes turn unanimatable SVGs into logically animatable SVGs, and sometimes involves introducing styling hooks using custom css properties.

However actually doing this work can be pretty involving. There are no editors I know of which are for developers working with SVG — and if I put it into a WYSIWYG editor, I’d just get the same problems back. Some SVGs really do require significant pathdata, though it usually can still be simplified dramatically (especially if the artist converted stroked lines to filled shapes) without loss of fidelity. I currently handle a lot of this by ‘tracing’ from code. I’ll paste the original into an about:blank and then overlay a new SVG which I write right in the browser. But the pathdata takes way more time and effort than anything else. Builtin tools for manipulating pathdata would be a godsend.

Comment 8

[Patrick Brosset <:pbro>]

Thank you all for sharing your experiences here. This has been very informative. There seems to be a clear need for editing paths of inline SVGs in the browser for doing things that external editors aren't well equipped to do.

I can't make any promises that the DevTools team at Mozilla will for sure start working on this, editing SVGs is a pretty huge project in and of itself.
I can, however, help push the conversation further by creating a document that contains the use cases you all have shared, and start drafting a solution proposal for it, and make it open for everybody to contribute if they want to.
Hopefully we all can come to a design idea that could then be picked up by the DevTools team, or the community!

Here is the document: https://docs.google.com/document/d/1ADdRHkYRW0iyqrpMB-bALnQj4XQCPfpeleoOpaGSjko/edit?usp=sharing

It is open to all for comments and suggestions. It would be great if people could continue adding to the list of problems and use cases in there, correct anything I might have gotten wrong, and even propose ideas at the bottom if they have any!
I took a first shot at a path editor panel. But would gladly hear feedback about it.