Warning: SVG property className is deprecated

In #5714, we changed SVG attribute logic to pass all SVG attributes unchanged.

This means, for example, that instead of <svg strokeWidth> you’d write <svg stroke-width>. The reason for this change was that we don’t want to maintain a whitelist of attributes.

Since we released 15 RC, I saw a report on Twitter saying that <svg className> now also prints a warning:

Warning: SVG property className is deprecated. Use the original attribute name class for SVG tags instead.

In a way, this makes sense, as it is consistent with us not maintaining a whitelist, and with how we treat custom components.

On the other hand, SVG elements do not seem that special, and asking people to use class on them instead invites the old discussion about doing that for DOM elements as well.

I would like to double-check that this className => class is indeed a change we want to make for SVG elements. Alternatively, we can leave className as is by introducing a special case for it alone.

[zpao]

Any chance this might be reverted before official v15.0.0?

We’re exploring a couple options. I think at the very least we’ll make sure className continues to work. The extreme option might be to backout all of this SVG work and get us back to 0.14 support. That’s obviously not ideal but is available to us. I think I’m personally leaning towards backpedaling on the “pass everything through” approach and expand the list of supported attributes in the whitelist. This would mean we’d no longer support hyphenated attributes and would go back to the camelCase mapping. I don’t see this as a huge problem as it maintains current (0.14) behavior, matches what we do for HTML attrs, and is something we have to continue doing for a handful of attributes anyway for the namespaced attrs (xlink:href).

Renaming className → class for HTML elements seems fine to do in the long run … but that sounds like a much bigger breaking change

Maybe we could do it but it definitely is a very big change. We might be too far down this path and honestly by the time we feel ready for it, we might all be using abstractions on top of the DOM (something like react-native-web for example), so it might not matter as much. I agree with what I think you’re getting at though - we should probably do it all at once and not live in this hybrid world where SVG uses one pattern and HTML uses another.

[Swatinem]

I use a CSS-in-JS solution with a helper function that splats in {className, style} to mix and match pre-defined styles with true inline styles. I use it for both html (obviously) and svg (to override fill, height, etc).

It is kind of annoying to have this warning now. So whatever you decide to do, at least make it consistent across html and svg. I personally would prefer to remove as much whitelisting / special casing as possible.