Bug 44144

For whatever reason, the SVG document won't find the marker for any browser when it references the attachment. Here is a URL showing the issue: http://www.mikehemesath.com/svg_markers/demo3/arrow.svg

We don't support external SVG-resources right now.

Given the behavior of the other browsers, specifically relating to bug https://bugs.webkit.org/show_bug.cgi?id=44047. Applying markers to SVG inline HTML5 documents using external stylesheets will be impossible to do until this is resolved.

This bug is pretty old, given the development speed of Webkit and still the problem exists, not only on Mac OS X, but also on Windows. Both Firefox and Opera until version 12 support this. Now that Opera switched to Webkit, it is not supported any more. IE10 does not support this. I don't know about IE11. Can't you push the priority of this a little?

Created attachment 479598 [details] rendering in safari, firefox, chrome testcase with different types of marker.

Created attachment 479599 [details] testcase + server unzip then python3 serve.py then http://localhost:8000/testcase.html

A self-contained replacement testcase covering all three vertex-marker properties (the original bug only mentioned `marker-end`): - `markers.svg` — external marker-definition document. Three markers with distinct shapes and colors so a failure (no marker painted) is trivially distinguishable from a success: - `#markerStart` — green circle - `#markerMid` — blue square - `#markerEnd` — red triangle - `testcase-external.svg` — path referencing the three markers via `url(markers.svg#id)`. **This is the bug-reproducing file.** - `testcase-inline-control.svg` — identical path with inline marker definitions. **Must render correctly in every engine** — it does not exercise external resources. It exists as a baseline to confirm the visual expectation. - `testcase.html` — wrapper that loads both SVGs in `<object>` elements so the external-vs-inline difference is obvious side-by-side. - `serve.py` — minimal HTTP server that forces `Content-Type: image/svg+xml` on `.svg` (WebKit over `file://` infers the MIME from the extension, so HTTP is not strictly required, but it eliminates MIME-inference as a variable). ## Path geometry — why 5 vertices The path `M 40 70 L 80 30 L 120 80 L 160 30 L 200 70` is a zigzag with five vertices, which is the minimum that exercises all three vertex-marker properties distinctly: | Vertex | Coord | Property painted | |--------|-----------|-------------------| | 1 | (40, 70) | `marker-start` | | 2 | (80, 30) | `marker-mid` #1 | | 3 | (120, 80) | `marker-mid` #2 | | 4 | (160, 30) | `marker-mid` #3 | | 5 | (200, 70) | `marker-end` | Total: 5 painted markers. A file that shows only the grey zigzag stroke with no markers has failed. ## Spec grounding SVG 2 §13.9 "Vertex markers: the 'marker-start', 'marker-mid' and 'marker-end' properties" (https://svgwg.org/svg2-draft/painting.html#VertexMarkerProperties): > Value: `none | <marker-ref>` > Initial: `none` > Applies to: shapes > Inherited: yes > The 'marker-start' and 'marker-end' properties are used to specify the > marker that will be drawn at the first and last vertices of the given > shape, respectively. 'marker-mid' is used to specify the marker that > will be drawn at all other vertices (i.e., every vertex except the first > and last). > `<marker-ref> = <url>` The property value accepts any `<url>` — the spec does not restrict the URL to same-document fragment references. An external document reference such as `url(markers.svg#markerStart)` is therefore spec-conforming syntax, and the behavior under test is whether WebKit fetches the referenced document and resolves the `<marker>` element by id. Note: per SVG 2 §13.4.5 "Computed value", the computed value has `<url>` values *made absolute*, which means the engine is expected to resolve the relative reference — another confirmation that external references are in scope of the spec. ## Expected vs actual - **Firefox / Chromium (Blink):** render the external case identically to the inline control — 5 markers. - **WebKit (as of 2026-05-11):** renders the path stroke with no markers attached to the external-reference case. The inline control renders correctly.

There are probably missing WPT test cases for this too.

SVGURIReference::fragmentIdentifierFromIRIString (Source/WebCore/svg/SVGURIReference.cpp:73-90) silently returns emptyAtom() for any URL that doesn't resolve to the current document, and both marker-lookup paths call it. WebKit's marker resolution pipeline has no knowledge of external SVG documents. The URL is silently truncated to its fragment inside `SVGURIReference::fragmentIdentifierFromIRIString`, which returns `emptyAtom()` whenever the URL points outside the current document. The marker-lookup code then looks up an empty id in the current document's tree scope and finds nothing. There is no `CachedSVGDocumentReference`, no fetch, no external-doc tree-scope lookup, and no invalidation plumbing for markers. Filters (e.g. `filter: url(sheet.svg#blur)`) *do* support external refs via a well-defined pattern; markers do not.

<rdar://problem/181437589>