Better SVG editing

Developer Tools
#1

Hi everyone,

if you ever tried to modify an SVG element (coordinates, path, fillColor, …) you know that it’s not an easy job to do with the inspector.
Basically, the only thing we can do is edit the attributes, which can be cumbersome for complex paths for example.
Since SVG is really gaining traction across the frontend developers community, It would be nice to make SVG element first grade citizen in the inspector, by having ad-hoc tools to modify specific attributes.

If you have ideas to do so or examples of other tools that deal with vector graphics, please add it here so we can think about how to integrate those in the devtools.

1 Like
#2

I saw today this nice Chrome extension that reveals all the path controls point : https://xvg.now.sh/

#3

Also relevant https://twitter.com/anatudor/status/810898302984220673

#4

Thanks for opening this discussion @nchevobbe! Really interesting topic. This tool would make a big difference for people working with SVG.

Over time, we’ve gathered some random ideas in this bug:

  • highlighting SVG shapes (right now the highlighter is always a rectangle, it would be useful if it actually wrapped the current shape),
  • when hovering over coordinates inside a d attribute for example, then highlight the corresponding point in the page,
  • an editor tool for creating/deleting/moving points in shape like Razvan’s shape editor,
  • linkifying special SVG attributes (xlink:href) in the inspector so that middle-clicking them would jump to the right element.
#5

It might be nice if the debugger display could somehow unpack SVG use elements.

I’ve generated svg that mostly contains uses (and the things used contain uses). When they are wrong the debugger is useless in seeing where the problem is

My current approach is to give the generating software the option of not using uses so that I can see what is going on, and then publish the use version when correct. This means that someone else inspecting the published use version can’t see what’s going on and has to look at the SVG definitions but can’t see how they display.

A few early examples can be found at the top of [1] when I was trying to track down a bug in Instiki.

[1] https://golem.ph.utexas.edu/wiki/instiki/revision/Sandbox/414

2 Likes
#6

Hey everyone! Great discussion. As someone who works with SVG I really dig ideas listed by @pbro.

Lately, I had a debugging/optimizing session with our graphic designer. She was frustrated by the tools she was using (AI, Sketch) because:

  • they do not play well with each other (e.g. AI doesn’t seem to understand some masks created by Sketch),
  • have some strange limitations (she had a hard time putting two shapes in the right Z-order in Sketch)
  • and produce SVG code that has to be optimized manually (SVGOMG is never enough).

I showed her, using Chrome DevTools, how I’m changing styles, attributes, removing and moving nodes around - it allowed us to do most of the debugging and cleanup. Seeing her tools and comparing them with mine, made me realize couple of things:

  • SVG renderers differ (AI, Sketch, browser), editing in the browser makes you certain that WYSIWYG,
  • “Elements” tab in Devtools is easy enough for non-developer to understand right away,
  • DevTools give much better control, and understanding, of the file you are working on, but take away visual editing.

Visual editing part was what we really missed to do all the cleanup work using devtools. Because there is no path/shape editor in the browser we had to switch couple of times between Sketch and DevTools to get the desired result.

I’ve created a mockup of how such an editor can look in devtools . What I really like about this approach is ability to focus on a single path/shape you are editing. Inline editing (like the Razvan’s shape editor does) would be far less useful IMO. Note that shapes can cover each other, be very small or have a color that makes them hard to see. What I don’t like about this mockup is the fact that the popup may be a bit too small to edit complex shapes. I also think that the final solution should have the point highlighting (as shown by Anna Tudor) to embrace the understanding of the file being edited.

2 Likes
#7

Note that shapes can cover each other, be very small or have a color that makes them hard to see.

That’s a really good point. This reminds me of a couple of tools I did in the past to edit border-radius and box-shadow properties. They would let you do it in the page directly, but the big problem was that these things are typically very small (border-radius are very often 2 or 3px, and box-shadows are usually offset by only a few pixels too).

Having a dedicated panel or tooltip to edit these things makes a lot of sense. And so, the same applies to SVG shapes I think.

I think this could be either a tooltip in the Rules tab as your mockup suggests, or maybe an entire sidebar tab that appears only when you click a specific icon in the DOM tree (next to a d attribute for instance).

1 Like
#8

FWIW, I agree with @RodMcGuire that better handling of svg-use would be very useful. To add some end user feedback, I don’t really care about being able to edit geometries (though it would be nice) but there are special/better tools for this like Inkscape/Illustrator. I get the SVGs from our Designers anyway.

But I just burnt two days fiddling around with svg-use. That is, I tried to reference another SVG id but it did not show up and I had no clue why (I thought IDs were wrong but in then end the SVG-use was right but just not positioned correctly, hence not visible).

To me it would have been useful if on mouseover the svg-use’d image would be shown in an image popup or similar (same way like other images are shown in a popup). Then I’d known that the reference at least works.