Space between SVG stroke and fill

Question

Filling and stroking a circle with the same color and a stroke-width exceeding a certain size, produces a strange transparent region “between” the two paint regions. What is going on?

This is happening in both Chrome and Firefox, so it may be to spec, but I couldn’t find any language in the spec about this behavior.

Fiddle

<svg viewBox="0 0 300 300">
  <circle cx="100" cy="100" r="8" 
    stroke="#000" stroke-width="40" 
    fill="#000"/>
</svg>

Produces this rendering:

Answer 1

I found that adding stroke-linecap="round" style="stroke-dasharray: 1000" fixes the issue by introducing virtual dashes

<svg viewBox="0 0 300 300">
  <circle cx="100" cy="100" r="8" 
    stroke="#000" stroke-width="40" 
    fill="#0F0" stroke-linecap="round" style="stroke-dasharray: 1000" />
</svg>

Answer 2

As Robert Longson noted, the issue shows up when a stroke overlaps itself in such a way that it creates a donut-hole when you convert the stroke outline to a separate path (depending on the winding-order / fill-rule calculations).

The gap between the fill and stroke in your particular example is caused by the "inside" edge of the stroke extending across the entire fill region and out the other side.

It gets really weird when you have dashed strokes, as shown in the examples from Tavmjong Bah's discussion article.

This is, unfortunately, neither according to the SVG spec nor against the spec. Instead, the spec at this point of time has left the matter undefined.

SVG working group discussion is here.

At this point, WebKit, Blink, and Firefox on Mac/Android draw strokes with cut-outs, using the Skia graphics library or Apple's CoreGraphics.

IE/Edge and Firefox on Windows/Linux just draw the total stroke, without cut-outs, as do Inkscape and Illustrator and most PDF-rendering software (the PDF spec itself is non-committal).

Everyone I've discussed this with agrees that the cut-outs are a sub-optimal result. But with so many browsers using rendering engines that do it this way, the SVG working group wasn't willing to make the more-intuitive stroke behavior a strict requirement. So instead, the SVG 2 spec has a warning-to-authors with a sample figure:

At this point, the best prospect for making a change would be to file issues (or contribute code) on the Skia library. If it was changed, that puts pressure on Apple to update to match, and the SVG spec would be able to make it official.