Allow DOM event and style modifiers on SVG content

[Vithanco]

SVG content composes but cannot respond to anything. Group, ForEach, Optional, _ConditionalContent and the tuples all carry extension …: SVGView where …, so you can build any SVG tree — and then nothing in it takes a handler or a style:

SVG.rect(.x(1), .y(2), .width(10), .height(11))
    .onClick { _ in }   // ✗ no such member
    .opacity(0.5)       // ✗ no such member

One constraint causes it. DOMEffectView is declared Wrapped: View, but its body uses only Wrapped.Tag and the _Mountable requirements. View means HTML & _Mountable, so asking for mountability also charges for HTML-ness.

The fix is what _KeyedView already does in KeyedView.swift — generic over MarkupContent & _Mountable, conditional conformance, modifier declared once per namespace:

extension DOMEffectView: HTML, View          where Wrapped: View {}
extension DOMEffectView: SVGContent, SVGView where Wrapped: SVGView {}

DOMEffectView was the one wrapper of its kind not yet converted. The mirrored declarations are the same duplication key(_:) pays: some View<Tag> and some SVGView<Tag> are distinct opaque types.

[sliemeobn]

@Vithanco thanks for the PR!

I had it on the list to eventually fix this - so thank you for starting the work.

the only thing I am not sold on yet is weather the "full duplication" is really a good thing. I think there may be a cleaner option of using public return types (instead of some ...) for the event / lifecycle modifiers somehow (ideally without exposing all internals) and conditionally conform them to View / SVGView respectively.

then there may be a way to implement these extensions on MarkdownContent somehow only once.

wdyt?

[Vithanco]

Spiked it — works.

Snag: DOM is @_spi(Benchmarking), so a public DOMElementModifier forces mount(_ node: DOM.Node, …) public and leaks the SPI type. Marking that one requirement. @_spi(Benchmarking) fixes it — all conformers are in-module. DOMEffectView then becomes nameable and the conditional conformances already here do the rest; SVGView+DOMEvents.swift disappears entirely.

One exception to "only once": onInput, focused and bindValue/bindChecked stay on extension View — they shouldn't reach SVG.

[sliemeobn]

I think this is the right direction, but the "public" blast radius is too big for my taste.

I was hoping we can get some clever ModifiedContent thing going, and maybe return a ModifiedContent<some Modifier, Self> without exposing too much - and hopefully still have a way to statically use the concrete types' implementation...

I am not 100% sure if this can be done with current Swift, but I have not found the time to explore a shape for this. Do you know where I am trying to go?

[Vithanco]

ModifiedContent<some Modifier, Self> is exactly it, and DOMEffectView already was that type. Only the return types changed:

-> DOMEffectView<some DOMElementModifier, Self>

Named wrapper, so the conditional conformances still pick the namespace. Opaque modifier, so no concrete modifier appears in a public signature — and an internal type needs no public witnesses, which is what keeps CSSOpacity/CSSTransform/CSSFilter, the payload structs and DOMEventHandlers internal.

What do you think now?

[Vithanco]

Also underscored what stays public: _DOMEffectView, _DOMElementModifier, _DOMElementModifiers, _AnyUnmountable.
_DOMEffectView has no public initialiser and the modifier in its return type is opaque, so outside the module you can only receive one, never name or build one. Structural, like _Mountable.

[sliemeobn]

I think this is approaching the right shape now, thanks.

can you please rebase onto latest main so we can run CI on it?

[Vithanco]

done

[sliemeobn]

@Vithanco thank you for your patience, and my apologies for being annoying - but after a bit of back an forth I think my preference is the original shape: explicit copies of the API, with "clean and simple" some View / some SVGView return types - both returning the same internal type under the hood.

it feels the bit of duplication is something very easily dealt with nowadays - in contrast to the somewhat messy exposure of underscored types + more complicated type gymnastics for these extensions. so I think the price of a tiny bit more maintenance burden is justified by the added simplicity for package consumers / documentation readers.

wdyt? do you have a preference?

also, I vaguely remember that svg elements have a different geometry behavior with transformation (eg: not "center" as anchor by default) - I have not tested it, but maybe we run into trouble by omitting the anchor for ".center" in the transforms for SVG?

[Vithanco]

To be frank, I don't mind too much. Both have advantages and disadvantages.  The impact for choosing one is little as the using code shouldn't change with either implementation. So, we can chose whatever you think is better. Chose your vice ;-)  /Klaus  -- Vithanco / Klaus Kneupner See for yourself how you can combine your brain power with structured visuals to help you think: https://vithanco.com/newsletter. The home of Structured Visual Thinking: www.vithanco.com <http://www.vithanco.com>. 27 Aug 2026, 13:15 by ***@***.***:

…

sliemeobn> left a comment > (elementary-swift/elementary-ui#119) <#119 (comment)> @Vithanco <https://github.com/Vithanco>> thank you for your patience, and my apologies for being annoying - but after a bit of back an forth I think my preference is the original shape: explicit copies of the API, with "clean and simple" > some View> / > some SVGView> return types - both returning the same internal type under the hood. it feels the bit of duplication is something very easily dealt with nowadays - in contrast to the somewhat messy exposure of underscored types + more complicated type gymnastics for these extensions. so I think the price of a tiny bit more maintenance burden is justified by the simplicity of package consumers. wdyt? do you have a preference? also, I vaguely remember that svg elements have a different geometry behavior with transformation (eg: not "center" as anchor by default) - I have not tested it, but maybe we run into trouble by omitting the anchor for ".center" in the transforms for SVG? — Reply to this email directly, > view it on GitHub <#119?email_source=notifications&email_token=ABFFOMB37ICMP7KVXNFCSDL5MAJ5DA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKNBTHAYTOOJRGEY2M4TFMFZW63VHNVSW45DJN5XKKZLWMVXHJLDGN5XXIZLSL5RWY2LDNM#issuecomment-5438179111>> , or > unsubscribe <https://github.com/notifications/unsubscribe-auth/ABFFOMFVIMZI2K2RZT3VHOD5MAJ5DAVCNFSNUABFKJSXA33TNF2G64TZHM4DMNBZGU3DKNRZHNEXG43VMU5TKMJTGE2TMMBUGY3KC5QC>> . You are receiving this because you were mentioned.> Message ID: > <elementary-swift/elementary-ui/pull/119/c5438179111> @> github> .> com>

[sliemeobn]

I think taking on a little more code duplication for a simpler API and cleaner docs is worth it, so if I could ask you to finalize the PR with this shape (and maybe double-check that SVG rotations/scaling actually works as expected) we can finally get this thing merged 🙏

[Vithanco]

Done — mirrored shape, DOMEffectView internal again with the conditional conformances
doing the work, each namespace returning some View<Tag> / some SVGView<Tag>.

You were right about the transforms: transform-origin resolves against the viewBox on
SVG, not the element, so I've removed rotationEffect/scaleEffect and they'll resurface
as a separate PR. offset stays — absolute pixels, unaffected.

Also "answered" your TODO: embedded on _onEvent while I was in there: still needed on
6.3.3. Internal fails the embedded build in _FunctionNode.swift with cannot use metatype of type 'some View<HTMLTag.button>' and a protocol type cannot contain a generic method 'unmount' — so it's the opaque return type reaching the function-node machinery rather
than the declaration. I've moved the recheck to 7.0.