Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Missing SVG tags and attributes #1657

Closed
sophiebits opened this issue Jun 8, 2014 · 107 comments
Closed

Missing SVG tags and attributes #1657

sophiebits opened this issue Jun 8, 2014 · 107 comments
Labels

Comments

@sophiebits
Copy link
Contributor

Note from maintainers: Starting with React 15, we should have a complete support of the subset of SVG specifications that is actually implemented by browsers.

If you find a missing attribute, or if a tag does not work correctly, please write a comment below. Note that React.DOM.* factory functions might not provide all tags, but you should be able to use React.createFactory or React.createElement() directly for the missing ones. Or you can just use JSX which translates to React.createElement() and supports all tags inherently.

@nullobject
Copy link

Anybody working on this? I'd be keen to implement the filter tag.

@jonase
Copy link
Contributor

jonase commented Jun 15, 2014

preserveAspectRatio also seems to be missing: http://jsfiddle.net/jonase/kb3gN/3025/

Should I create a PR for this or do you prefer to collect all the missing attributes/tags first and later create a single patch?

[edit] preserveAspectRatio was added in commit 0f0328f

@Delapouite
Copy link
Contributor

Hi.

marker* attributes have been added thanks to @cassus in #1738 as stated above.

What about adding the related <marker> SVG element?
https://developer.mozilla.org/en-US/docs/Web/SVG/Element/marker

@jefffriesen
Copy link

I just realized I need this too. Here's a good overview of it: http://tutorials.jenkov.com/svg/marker-element.html

@zpao
Copy link
Member

zpao commented Jul 1, 2014

This "add a random element and attribute here and there as 1 person needs it" approach has gotten out of hand. So we either need to support everything or nothing (or alternatively add a reasonable set of things now and then freeze there).

I scraped http://www.w3.org/TR/2003/REC-SVG11-20030114/attindex.html for almost everything (not counting namespaced attributes) and came up with this: https://github.com/zpao/react/compare/fuck-svg.

However that adds ~2kb to our minified build (though it would crush well with closure compiler) and I don't want to take that size increase right now. We've talked about doing a separate SVG build. Or shipping that separately as an addon.

@Delapouite
Copy link
Contributor

@zpao you're right. Full SVG support could be an addon. To do so a depreciation warning will need to be set to inform for example than React.DOM.circle will become React.SVG.circle

@cassus
Copy link
Contributor

cassus commented Jul 2, 2014

+1 for React.SVG.circle

@jefffriesen
Copy link

@zpao
A full SVG add-on sounds like a good approach. Many projects don't need any SVG, so we shouldn't weigh down the code for them. Other projects need and it doesn't make sense to only go halfway on support.

@totty90
Copy link

totty90 commented Jul 20, 2014

+1

@sophiebits
Copy link
Contributor Author

#2069 requests support for image.

@michaelcarter-wf
Copy link

+1 for image support

@bobeagan
Copy link
Contributor

+1 for image support as well

@chengyin
Copy link

+1 for <use> support. We are using that for our svg icon set. We are trying to dangerouslySetHTML to make it work, however, the event bubbling doesn't work with it.

@jacobrask
Copy link

Missing strokeDashoffset. I want to use it for a progress bar, like this: http://codepen.io/JMChristensen/pen/Ablch

@SanderSpies
Copy link
Contributor

+1 for strokeDashoffset

also want to use it for a progress bar .

@ThomasDeutsch
Copy link

I am missing alignment-baseline when working with <text>

@qinyang912
Copy link

+1 for animateTransform

@okorz001
Copy link

+1 for dominate-baseline (#3199.)

@sophiebits
Copy link
Contributor Author

Like @zpao said, we're going to fix this for good soon so any attributes can be used.

Locking this issue until then.

@gaearon
Copy link
Collaborator

gaearon commented Dec 25, 2015

This was fixed in #5714.

@gaearon
Copy link
Collaborator

gaearon commented Mar 15, 2016

#5714 was reverted in #6243, and thus we still require an attribute whitelist. The good news, however, is that #6243 contains attributes scraped for MDN so we expect it to cover 95% of the use cases. I read through this whole issue and linked issues and PRs and manually added two missing properties (focusable and vector-effect) in #6267. I expect these changes to land in v15.

Interestingly, I’m not sure whether the tag whitelist is relevant anymore. So far I have been able to use <marker>, <textPath>, <feGaussianBlur> and other tags requested in this issue and in linked PRs without trouble on master. I see that fbjs still maintains an SVG tag whitelist and I don’t know the codebase well enough to say why tags missing from it worked for me today, so hopefully @zpao or @spicyj can clarify this, and whether we need to also add the missing tags there, to complement #6243.

I am unlocking this issue because the attribute whitelist is still relevant, but hopefully we will see a lot less requests now that most of the attributes that are both in the spec and are implemented by the browsers, are supported. If something still isn’t supported in the final v15, please let us know here.

This note does not apply to v15 RC1 which passes all SVG attributes through. We reverted this behavior in #6243 so please use the upcoming RC2, the master, or the final v15 to tell whether the attributes you are interested in are currently supported.

@facebook facebook unlocked this conversation Mar 15, 2016
@gaearon
Copy link
Collaborator

gaearon commented Mar 15, 2016

I noticed that there seems to be quite a lot of confusion about the xlink:href attribute. It is currently supported but you would need to write it in a different way:

<use xlinkHref="#shape" x="50" y="50" />

React will correctly turn that into xlink:href, even in 0.14.x. See this fiddle for an example.

gaearon added a commit that referenced this issue Mar 16, 2016
@Arnavion
Copy link

For my use case I needed React to recognize some filter elements like feFuncR, specifically their attributes (slope, intercept, etc). It appears to be fine in 15.0-rc2, but for 0.14.x I worked around it by adding these attributes to the dictionary exported by react/lib/SVGDOMPropertyConfig before first importing react / react-dom itself. Eg:

// Needed to set correct xmlns on <svg> and to preserve attributes on feFunc*.
// Required for 0.14.x. May become unnecessary with 15.x

var SVGDOMPropertyConfig = require("react/lib/SVGDOMPropertyConfig");

var DOMProperty = require("react/lib/DOMProperty");
var MUST_USE_ATTRIBUTE = DOMProperty.injection.MUST_USE_ATTRIBUTE;

SVGDOMPropertyConfig.Properties.in = MUST_USE_ATTRIBUTE;
SVGDOMPropertyConfig.Properties.intercept = MUST_USE_ATTRIBUTE;
SVGDOMPropertyConfig.Properties.slope = MUST_USE_ATTRIBUTE;
SVGDOMPropertyConfig.Properties.xmlns = MUST_USE_ATTRIBUTE;

var React = require("react");
var render = require("react-dom").render;

This is obviously a hack but I find it preferable to dangerouslySetInnerHTML

@gaearon
Copy link
Collaborator

gaearon commented Mar 21, 2016

While this works it’s not an officially exposed API and may break in any minor or patch release. You can use it but on your own risk. If something is still missing please work with us so we add it. I’m glad to hear you don’t have issues with 15 RC2.

@Arnavion
Copy link

Yep, absolutely. I'm only using that until 15 comes out of RC status.

@elrumordelaluz
Copy link

Pretty happy for the (almost) full SVG support in v15.0 but I'm realising that some namespaced attributes like xmlns and xmlnsXlink couldn't apply when render, and this is ok when showing the svg in the browser.

In case you want to create an .svg image those attributes are necessary.

ReactDOMServer.renderToStaticMarkup(<MyCustomSVG />)

So doing the code above, wont'n work.

Probably is related on the fact that:

...thanks to using document.createElement, we no longer need to maintain a list of SVG tags, so any SVG tags that were previously unsupported should work just fine in React 15

and not document.createElementNS.

@gaearon
Copy link
Collaborator

gaearon commented Apr 12, 2016

and not document.createElementNS.

The blog post is a little too simplified, but createElementNS is used when we’re under an <svg> tag. If this doesn’t happen can you please file a separate issue describing the problem, with a JSFiddle that reproduces it? Thanks!

@elrumordelaluz
Copy link

Thank you @gaearon. I think it does happen when render the svg in browser through ReactDOM. Probably the issue is related with ReactDOMServer.

Here is a pen that shows the rendered SVG and the code generated through renderToStaticMarkup() where is missing at least xmlNSand xmlnsXlink attrs.

If is the case I could file this issue separately.

@zpao
Copy link
Member

zpao commented Apr 12, 2016

Yea, xmlns and xmlns:Xlink are missing. #6471 has some in progress work to add it.

@shilpan
Copy link

shilpan commented Apr 16, 2016

I still do not see <animate> and <animateTransform> in the list of supported tags. Is there a reason you chose not to support it?

@gaearon
Copy link
Collaborator

gaearon commented Apr 16, 2016

@shilpan

All tags are supported now. The list only tells which tags are supported as React.DOM.* factory functions:

The following SVG elements are supported in React.DOM.*:

(emphasis mine)

If you use JSX, you don’t need to worry about this at all—writing <animate> and <animateTransform> will just work because JSX does not rely on React.DOM.* factories.

Even if you don’t use JSX, you can use React.createElement('animate', ...) which will work just fine, or create your own factory function: var animate = React.createFactory('animate").

@617dev
Copy link

617dev commented May 3, 2016

+1 for adding support for xmlns.... In the mean time if anyone is interested in a workaround (which I needed to be able to support IE9-11) this is what I came up with:

// explicitly build the SVG to be rendered here so we don't lose the NS
const stringifiedSvg = `<svg xmlns="http://www.w3.org/2000/svg" class="svgClass">
                               <use xlink:href="#linkToSymbolId"></use>
                        <svg/>`

return <div dangerouslySetInnerHTML={{__html: stringifiedSvg}}/>

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests