The effect of visible overflow for pattern tiles was not clearly defined in SVG 1, leading to non-interoperable implementations. In SVG 1.1, a warning was added:

Note that if the ‘overflow’ property is set to visible the rendering behavior for the pattern is undefined.

I would really like to remove this "officially undefined" behavior from SVG 2.

Relevant discussion from the mailing list in 2009 (thread starts here) includes this statement from @erikdahlstrom :

The SVG WG agrees that the rendering behavior for overflow="visible" on elements in SVG 1.1 is currently unspecified. For the second edition of SVG 1.1 the WG has resolved to leave the rendering behavior for overflowing pattern tiles as undefined[1] in order to fully address the issue in the next version of SVG[2].

That second link goes to this Tracker issue, which has no updates since 2009.

This is not a theoretical issue. I get complaints & confusion from authors about why patterns that work just the way they want in one browser don't work in another. Specifically, the issue comes up when the repeating element of the pattern doesn't fit in a neat rectangular tile.

Here's a recent example screenshot. The top image is from Firefox, showing clipping to the pattern tile despite the overflow value, the bottom image is from Chrome:

My current best advice for the authors is to use <use> elements to create enough repetitions to completely fill in the rectangular tile. But that's far from ideal. Not only is it messy and repetitive code, it also opens up the possibility of edge effects in the rendering (revealing the edges of the pattern tiles).

As I understand it, the only aspect of overflowing pattern tiles that really needs to be defined is the rendering order. When overflowing content from pattern tiles overlaps, which tile is painted on top? E.g., are tiles painted in rows, left to right then top to bottom, or in columns? I don't see any theoretical reason to prefer one or the other, so this could be based on whatever is easiest for current implementations.

Next steps:

• Create a test case of overlapping overflowing patterns
• Gather data for current implementations: which ones clip vs draw the overflow, and if they draw the overflow, what rendering order do they use
• Feedback from implementers about whether there are any other intrinsic obstacles to supporting overflowing patterns.