Inert elements inside `<svg>` will be wrapped in a `<g>` (0.8.3 breaking change)

[pheki]

Describe the bug

Starting from 0.8.3, the first level of <svg> elements get wrapped in a <g>. For example <text x="1" y="50"><tspan>Just an example</tspan></text>, if a direct child of <svg>, gets rendered as <g><text x="1" y="50"><tspan>Just an example</tspan></text></g>.

Leptos Dependencies

leptos = { version = "0.8.15", features = ["csr"] }

To Reproduce

Steps to reproduce the behavior:

1. Create an example app following the Getting Started tutorial from the book
2. Replace src/main.rs with the following:

use leptos::prelude::*;

fn main() {
    leptos::mount::mount_to_body(|| view! { <MyOwnSvg /> })
}

#[component]
fn MyOwnSvg() -> impl IntoView {
    view! {
        <svg
            width="200"
            viewBox="0 0 200 100"
            id="lamp"
            xmlns="http://www.w3.org/2000/svg"
            xmlns:xlink="http://www.w3.org/1999/xlink"
        >
            // Inert SVG elements are wrapped in a `<g>` when rendered
            <rect x="12" y="10" width="140" height="32" stroke="black" fill="transparent" />
            <text x="18" y="32"><tspan>Just an example</tspan></text>
            // This is not inert, so it's not wrapped in a `<g>`
            {
                move || view! {
                    <rect x="12" y="110" width="140" height="32" stroke="black" fill="transparent" />
                }
            }
            // This is not inert, so it's not wrapped in a `<g>`
            <rect x=12 y="210" width="140" height="32" stroke="black" fill="transparent" />
        </svg>
    }
}

4. Open http://localhost.:8080/ in your browser (tested on both Firefox and Chromium)
5. Check in the HTML inspector that both <rect> and <text> got wrapped in two different <g> elements. The same did not happen for <tspan> (nested inside) nor the other <rect>s (not inert).

Next Steps

• I will make a PR
• I would like to make a PR, but need help getting started
• I want someone else to take the time to fix this
• This is a low priority for me and is just shared for your information

Additional context

I discovered this while investigating #4555.

Bisected it to commit cf0aa0e from PR #4104.

I think this was a breaking change as it inadvertently changes the generated SVG, which may invalidate element queries and CSS selectors, but fixing it is also a breaking change and as it has been there for a while and there may be code depending on the new behavior. So it may be worth to fix it in 0.9 instead.

Edit: Update example to highlight the difference in behavior between inert and non-inert elements.

[pheki]

Reading more in the PR I just noticed it was actually introduced in a separate commit, so it looks like it was intentional but I'm not sure what is the rationale, as it seems to render fine without it.

[gbj]

@bicarlsen Do you remember why svg::InertElement wraps created SVG elements in a <g> in addition to wrapping them in <svg>?

[bicarlsen]

@bicarlsen Do you remember why svg::InertElement wraps created SVG elements in a <g> in addition to wrapping them in <svg>?

Not completely, but I believe it was so I could get the SVG namespace in there as mentioned in #4103.

[pheki]

Hmmmm interesting, maybe there's some edge case or some more complicated case where it fails without the <g>?

I tested the above example with the commit reverted in Firefox, Chromium and Safari and they all render fine even with no <g>, checking element.namespaceURI prints the SVG namespace for the <rect>s. (not literally reverted as the commit has been squashed but with its changes undone manually)