enforce title tag to be the first child inside svg (if it's not there already)

revelt commented 2 years ago

🚀 Feature Proposal

For backwards compatibility with SVG 1.1 (https://developer.mozilla.org/en-US/docs/Web/SVG/Element/title), we must put <title> as the first child, no matter the order it originally comes in.

Motivation

It would be nice if svgr automatically corrected the position of <title> element, pushing it forward, to be the first child element.

Example

svgr currently doesn't care about the <title> tag position. Quick adapted placeholder snippet from the GUI web page app:

<?xml version="1.0" encoding="UTF-8"?>
<svg width="48px" height="1px" viewBox="0 0 48 1" version="1.1" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink">
    <!-- Generator: Sketch 46.2 (44496) - http://www.bohemiancoding.com/sketch -->
    <desc>Created with Sketch.</desc>
    <defs></defs>
    <g id="Page-1" stroke="none" stroke-width="1" fill="none" fill-rule="evenodd">
        <g id="19-Separator" transform="translate(-129.000000, -156.000000)" fill="#063855">
            <g id="Controls/Settings" transform="translate(80.000000, 0.000000)">
                <g id="Content" transform="translate(0.000000, 64.000000)">
                    <g id="Group" transform="translate(24.000000, 56.000000)">
                        <g id="Group-2">
                            <rect id="Rectangle-5" x="25" y="36" width="48" height="1"></rect>
                        </g>
                    </g>
                </g>
            </g>
        </g>
    </g>
    <title>Rectangle 5</title>
</svg>

Above, the <title> comes in at a wrong position and svgr should be able to automatically fix it.

Pitch

Why does this feature belong in the SVGR ecosystem? It's quick, no-brainer improvement to prevent some edge cases. Who's keen to debug different SVG specs anyway?

gregberge commented 2 years ago

Hello @revelt, same as the other issue, I am OK with it!

stale[bot] commented 2 years ago

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

stale[bot] commented 1 year ago

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

SethFalco commented 1 year ago

It's quick, no-brainer improvement to prevent some edge cases. Who's keen to debug different SVG specs anyway?

I may pick this up as a part of SVGO, but just want to note an edge case that doesn't make this that simple. An SVG may have a <style> tag in it, which may include selectors that depend on the order of elements.

Consider the following:

<svg viewBox="0 0 256 172" xmlns="http://www.w3.org/2000/svg" preserveAspectRatio="xMidYMid">
  <style>
    svg path:nth-child(2) {
      color: red;
    }
  </style>
  <path d="M112.973416,9.2496789 C105.800602,-3.0832263 87.8689954,-3.0832263 80.6961815,9.2496789 L2.52446046,143.659628 C-4.64826776,155.992961 4.3176211,171.408985 18.6631204,171.408985 L79.688321,171.408985 C73.5584906,166.051862 71.2883417,156.784087 75.9271555,148.832569 L135.130926,47.3479175 L112.973416,9.2496789 Z" fill="currentcolor"/>
  <title>Title</title>
</svg>

If <title> were to be moved to the top without modifying the selector, the styles would break. This would definitely always be safe when no JavaScript or script tag is present, though.

gregberge / svgr